GitHub repository: numba/numba

Issues:
issue_9471: state: open
title: CUDA crashes when passed complex record array
body: Passing sufficiently complex data to a CUDA kernel, passing the data to a device function and getting a piece of it causes the kernel to crash.



<details>
<summary>Code to reproduce</summary>

```py
from collections import namedtuple
from collections.abc import Sequence
from typing import Any, NamedTuple, Self, cast

import numpy as np
from numba import cuda  # type: ignore[input]
from numba.cuda.random import (  # type: ignore[import]
    create_xoroshiro128p_states,
)
from numpy import typing as npt

Sit = namedtuple("Sit", ["a", "b", "c"])

TrainContextHostNT = namedtuple(
    "TrainContextHostNT", ["config", "graph", "overlay"]
)
TrainOverlayNT = namedtuple("TrainOverlayNT", ["infer", "assess", "adapt"])

LevelAdaptNT = namedtuple(
    "LevelAdaptNT", ["cluster", "cluster_sit", "cluster_params"]
)
TrainConfigNT = namedtuple(
    "TrainConfigNT",
    [
        "n_samples",
        "n_features",
        "batch_size",
        "max_threads",
        "shared_bytes",
        "params",
        "dvs",
    ],
)
TrainGraphDataNT = namedtuple(
    "TrainGraphDataNT", ["model", "data", "state", "prev_state"]
)
NodeStateNT = namedtuple(
    "NodeStateNT",
    [
        "occurrence",
        "value",
        "relevance",
        "significance",
        "feature_value",
        "sample_relevance",
        "final_mem_avg",
        "final_mem_relevance",
    ],
)
CGDataNT = namedtuple(
    "CGDataNT",
    ["occurrence", "relevance", "significance", "value", "dv_params"],
)
_1 = np.float32(1)
DVParamsNT = namedtuple(
    "DVParamsNT", ["dv_definitions", "first_dv_feature", "level_err_range"]
)
DVDefinitionNT = namedtuple(
    "DVDefinitionNT",
    ["dv_idx", "threshold", "sharpness", "sig_scale", "sig_offset", "level"],
)
EMMClusterOverlayNT = namedtuple(
    "EMMClusterOverlayNT",
    ["cluster", "optimize", "util", "constraint"],
)
ClusterOverlayNT = namedtuple(
    "ClusterOverlayNT",
    [
        "min_sum_matrix",
        "max_sum_matrix",
        "rel_in",
        "rel_out",
        "dist_matrix",
        "stack",
        "i_matrix",
        "closest_out_dist",
        "max_i_array",
        "in_edges_out",
        "new_edge_count",
        "new_edge_start",
        "new_edge_source_ranked",
        "new_edge_source",
        "new_edge_target",
        "new_edge_weight",
        "new_edge_weight_min",
        "new_edge_weight_max",
    ],
)
OptimizeOverlayNT = namedtuple(
    "OptimizeOverlayNT",
    [
        "param_node_values",
        "param_edge_values",
        "set_edge_weight",
        "set_a_relevance",
        "set_value",
        "set_relevance",
        "set_significance",
        "set_mem_value",
        "set_mem_relevance",
        "set_mem_exp_avg",
        "edge_sum",
        "neg_edge_sum",
        "entropies",
        "i_min_param_set",
        "hist_lc_states",
        "hist_lc_buffer",
        "hist_diff_est",
        "back_significance",
        "back_cat_significance",
        "significance",
        "cat_significance",
        "relevance",
        "hist_node_sum",
        "hist_node_weight",
        "hist_mem_avg",
        "hist_sample_bins",
        "hist_combination",
    ],
)
UtilOverlayNT = namedtuple(
    "UtilOverlayNT",
    ["stack", "rng_states"],
)

ConstraintOverlayNT = namedtuple(
    "ConstraintOverlayNT",
    [
        "f_preserve",
        "param_node_old",
        "param_edge_old",
        "sum_nearest",
        "in_assigned",
        "sum_edge_delta",
    ],
)

ClusterSituationNT = namedtuple(
    "ClusterSituationNT",
    [
        "i_in",
        "in_level",
        "in_type",
        "i_out",
        "out_level",
        "out_type",
        "last_trained",
        "mb_samples",
        "a_weight",
        "is_objective",
        "n_iv_features",
        "n_dv_features",
    ],
)
PairNT = namedtuple("PairNT", ["a", "b"])

ClusterParamsNT = namedtuple(
    "ClusterParamsNT",
    [
        "min_relevance",
        "min_significance",
        "n_cluster_passes",
        "dist_passes",
        "dist_max_inputs",
        "dist_max_outputs",
        "dist_threshold",
        "n_spare_dist_threshold",
        "n_opt_passes",
        "n_opt_param_sets",
        "n_opt_best",
        "dim_relevance",
        "mem_ema_decay",
        "mem_relevance",
        "history_filter_bytes",
        "history_bf_thresholds",
        "seed",
    ],
)
ModelNT = namedtuple(
    "ModelNT",
    [
        "n_levels",
        "n_iv_features",
        "n_dv_objectives",
        "i_level_start",
        "i_level_edge_start",
        "i_level_edge_end",
        "i_edge_start",
        "i_edge_count",
        "threshold",
        "sharpness",
        "decay",
        "mem_threshold",
        "mem_sharpness",
        "mem_decay",
        "mem_out_weight",
        "mem_in_weight",
        "i_objective_node",
        "objective_cat",
        "param_node_min",
        "edge_target",
        "edge_source",
        "edge_weight",
        "param_node_max",
        "param_edge_min",
        "param_edge_max",
    ],
)
ClusterParamsNT = namedtuple(
    "ClusterParamsNT",
    [
        "min_relevance",
        "min_significance",
        "n_cluster_passes",
        "dist_passes",
        "dist_max_inputs",
        "dist_max_outputs",
        "dist_threshold",
        "n_spare_dist_threshold",
        "n_opt_passes",
        "n_opt_param_sets",
        "n_opt_best",
        "dim_relevance",
        "mem_ema_decay",
        "mem_relevance",
        "history_filter_bytes",
        "history_bf_thresholds",
        "seed",
    ],
)
AdaptParamsNT = namedtuple("AdaptParamsNT", ["f_preserve", "f_discard"])
TrainParamsNT = namedtuple(
    "TrainParamsNT",
    ["gpu", "model", "data", "dv", "cluster", "adapt", "a_weight", "seed"],
)
GPUParamsNT = namedtuple(
    "GPUParamsNT", ["mini_batch_size", "leave_free_frac", "leave_free_bytes"]
)
ModelParamsNT = namedtuple(
    "ModelParamsNT",
    [
        "level_nodes",
        "level_edges",
        "subj_cuts",
        "obj_cuts",
        "min_halflife",
        "max_halflife",
    ],
)
FeatureRangesNT = namedtuple(
    "FeatureRangesNT",
    [
        "n_dv_features",
        "n_iv_features",
        "feature_min",
        "feature_max",
        "feature_median",
    ],
)


class LCState(NamedTuple):
    n_threshold: np.float32
    p_threshold: np.float32
    lc_threshold: np.float32
    diff_est: np.float32

    @staticmethod
    def dtype() -> np.dtype[Any]:
        """
        Returns data type for LCState.
        """
        return np.dtype(
            dict(
                names=(
                    "n_threshold",
                    "p_threshold",
                    "lc_threshold",
                    "diff_est",
                ),
                formats=(
                    np.float32,
                    np.float32,
                    np.float32,
                    np.float32,
                ),
                aligned=True,
            ),
        )

    @classmethod
    def create_array(cls, *dims: int) -> Any:  # noqa: ANN401
        """
        Create LCState array.
        """
        return np.zeros(dims, dtype=cls.dtype())  # type: ignore[no-any-return]


U4_MAX = np.uint32(0xFFFFFFFF)


class LCBuffer(NamedTuple):
    p_threshold_bin: npt.NDArray[np.uint32]
    lc_threshold_bin: npt.NDArray[np.float32]

    @staticmethod
    def dtype(n_bin_buffer: int) -> np.dtype[Any]:
        n_bin_words = (n_bin_buffer + 31) // 32
        return np.dtype(
            dict(
                names=(
                    "p_threshold_bin",
                    "lc_threshold_bin",
                ),
                formats=(
                    np.dtype((np.uint32, n_bin_words)),
                    np.dtype((np.float32, n_bin_buffer)),
                ),
                aligned=True,
            ),
        )

    @classmethod
    def create(cls, buffer_bins: int) -> Self:
        n_buffer_words = (buffer_bins + 31) // 32
        return cls(
            p_threshold_bin=np.full(n_buffer_words, U4_MAX, dtype=np.uint32),
            lc_threshold_bin=np.zeros(buffer_bins, dtype=np.float32),
        )


def test_mem() -> None:
    """
    Test setup cluster situation.
    """
    out_nodes = in_nodes = dist_max_inputs = block_edges = level_edges = 1
    buffer_bins = thresholds = seed = threads = 1
    stream = 0
    param_sets = 4
    model_params = ModelParamsNT(
        level_nodes=((1, 2), (3, 4)),
        level_edges=((5, 6), (7, 8)),
        subj_cuts=2,
        obj_cuts=2,
        min_halflife=np.float32(0.5),
        max_halflife=np.float32(1.5),
    )
    data_params = FeatureRangesNT(
        n_dv_features=1,
        n_iv_features=1,
        feature_min=np.zeros(1, dtype=np.float32),
        feature_max=np.zeros(1, dtype=np.float32),
        feature_median=np.zeros(1, dtype=np.float32),
    )
    adapt_params_1 = AdaptParamsNT(
        f_preserve=np.float32(0.2),
        f_discard=np.float32(0.2),
    )

    dv_definitions = (
        DVDefinitionNT(
            dv_idx=0,
            threshold=_1,
            sharpness=_1,
            sig_scale=_1,
            sig_offset=_1,
            level=-1,
        ),
    )
    dv_params = DVParamsNT(
        dv_definitions=dv_definitions,
        first_dv_feature=0,
        level_err_range=PairNT(0, 1),
    )
    c_params = ClusterParamsNT(
        min_relevance=np.float32(1.0),
        min_significance=np.float32(1.0),
        n_cluster_passes=1,
        dist_passes=1,
        dist_max_inputs=2,
        dist_max_outputs=2,
        dist_threshold=np.float32(0.5),
        n_spare_dist_threshold=1,
        n_opt_passes=1,
        n_opt_param_sets=5,
        n_opt_best=2,
        dim_relevance=np.float32(0.9),
        mem_ema_decay=np.float32(0.8),
        mem_relevance=np.float32(0.9),
        history_filter_bytes=100,
        history_bf_thresholds=np.array([0.5, 0.9], dtype=np.float32),
        seed=35,
    )
    train_params_1 = TrainParamsNT(
        gpu=GPUParamsNT(10, 0.3, 0.3),
        model=model_params,
        data=data_params,
        dv=dv_params,
        cluster=c_params,
        adapt=adapt_params_1,
        a_weight=1.0,
        seed=32,
    )
    data = CGDataNT(
        occurrence=np.zeros(1, dtype=np.float64),
        relevance=np.zeros(1, dtype=np.float32),
        significance=np.zeros(1, dtype=np.float32),
        value=np.zeros((1, 1), dtype=np.float32),
        dv_params=dv_params,
        # last_occurrence=np.float64(0.0),
    )
    model = create_empty(1, 1, ((3, 2), (3, 2)), ((5, 2), (5, 2)))

    params = train_params_1
    config = TrainConfigNT(
        n_samples=1,
        n_features=1,
        batch_size=1,
        max_threads=1,
        shared_bytes=1,
        params=params,
        dvs=params.dv,
    )

    rng_states = create_xoroshiro128p_states(
        threads,
        seed,
        stream=stream,
    )
    util = UtilOverlayNT(
        stack=np.zeros((out_nodes, 1), dtype=np.int32),
        rng_states=rng_states.copy_to_host(),
    )
    mb_samples = 11
    state = NodeStateNT(
        occurrence=np.zeros(1, dtype=np.float64),
        value=np.zeros((1, 1), dtype=np.float32),
        relevance=np.zeros((1, 1), dtype=np.float32),
        significance=np.zeros((1, 1), dtype=np.float32),
        feature_value=np.zeros((1, 1), dtype=np.float32),
        sample_relevance=np.zeros(1, dtype=np.float32),
        final_mem_avg=1,
        final_mem_relevance=1,
    )
    graph = TrainGraphDataNT(
        model=model,
        data=data,
        state=state,
        prev_state=state,
    )
    cluster = (
        EMMClusterOverlayNT(
            cluster=ClusterOverlayNT(
                max_sum_matrix=np.zeros(
                    (in_nodes, out_nodes), dtype=np.float32
                ),
                min_sum_matrix=np.zeros(
                    (in_nodes, out_nodes), dtype=np.float32
                ),
                rel_in=np.zeros((in_nodes,), dtype=np.float32),
                rel_out=np.zeros((out_nodes,), dtype=np.float32),
                dist_matrix=np.zeros((out_nodes, in_nodes), dtype=np.float32),
                stack=np.zeros((out_nodes, in_nodes), dtype=np.int32),
                i_matrix=np.zeros((out_nodes, in_nodes), dtype=np.int32),
                closest_out_dist=np.zeros((in_nodes,), dtype=np.float32),
                max_i_array=np.zeros((out_nodes,), dtype=np.int32),
                in_edges_out=np.zeros((in_nodes,), dtype=np.int32),
                new_edge_count=np.zeros((out_nodes,), dtype=np.int32),
                new_edge_start=np.zeros((out_nodes,), dtype=np.int32),
                new_edge_source_ranked=np.zeros(
                    (out_nodes, dist_max_inputs),
                    dtype=np.int32,
                ),
                new_edge_source=np.zeros((block_edges,), dtype=np.int32),
                new_edge_target=np.zeros((block_edges,), dtype=np.int32),
                new_edge_weight=np.zeros((block_edges, 2), dtype=np.float32),
                new_edge_weight_min=np.zeros(
                    (block_edges, 2), dtype=np.float32
                ),
                new_edge_weight_max=np.zeros(
                    (block_edges, 2), dtype=np.float32
                ),
            ),
            optimize=OptimizeOverlayNT(
                param_node_values=np.zeros(
                    (param_sets, out_nodes, 1),
                    dtype=np.float32,
                ),
                param_edge_values=np.zeros(
                    (max(param_sets, 4), level_edges, 1),
                    dtype=np.float32,
                ),
                set_edge_weight=np.zeros(
                    (param_sets, out_nodes, mb_samples),
                    dtype=np.float32,
                ),
                set_a_relevance=np.zeros(
                    (param_sets, out_nodes, mb_samples),
                    dtype=np.float32,
                ),
                set_value=np.zeros(
                    (param_sets, out_nodes, mb_samples),
                    dtype=np.float32,
                ),
                set_relevance=np.zeros(
                    (param_sets, out_nodes, mb_samples),
                    dtype=np.float32,
                ),
                set_significance=np.zeros(
                    (param_sets, out_nodes, mb_samples),
                    dtype=np.float32,
                ),
                set_mem_value=np.zeros(
                    (param_sets, out_nodes, mb_samples),
                    dtype=np.float32,
                ),
                set_mem_relevance=np.zeros(
                    (param_sets, out_nodes, mb_samples),
                    dtype=np.float32,
                ),
                set_mem_exp_avg=np.zeros(
                    (param_sets, out_nodes), dtype=np.float32
                ),
                edge_sum=np.zeros((param_sets, out_nodes, 2), dtype=np.float32),
                neg_edge_sum=np.zeros(
                    (param_sets, out_nodes, 2), dtype=np.float32
                ),
                entropies=np.zeros((out_nodes, param_sets), dtype=np.float32),
                i_min_param_set=np.zeros(
                    (out_nodes, param_sets), dtype=np.int32
                ),
                hist_lc_states=(
                    LCState.create_array(param_sets, out_nodes, thresholds)
                ),
                hist_lc_buffer=(LCBuffer.create(buffer_bins)),
                hist_diff_est=np.zeros(
                    (param_sets, out_nodes, thresholds),
                    dtype=np.float32,
                ),
                hist_mem_avg=np.zeros(
                    (param_sets, out_nodes), dtype=np.float32
                ),
                hist_sample_bins=np.zeros(mb_samples, dtype=np.uint32),
                hist_combination=np.zeros(out_nodes, dtype=np.int32),
                back_significance=np.zeros(
                    (param_sets, out_nodes),
                    dtype=np.float32,
                ),
                back_cat_significance=np.zeros(
                    (param_sets, out_nodes),
                    dtype=np.float32,
                ),
                significance=np.zeros(
                    (param_sets, out_nodes), dtype=np.float32
                ),
                cat_significance=np.zeros(
                    (param_sets, out_nodes),
                    dtype=np.float32,
                ),
                relevance=np.zeros((param_sets, out_nodes), dtype=np.float32),
                hist_node_sum=np.zeros(
                    (param_sets, out_nodes), dtype=np.float32
                ),
                hist_node_weight=np.zeros(
                    (param_sets, out_nodes),
                    dtype=np.float32,
                ),
            ),
            util=util,
            constraint=ConstraintOverlayNT(
                f_preserve=np.zeros(out_nodes, dtype=np.float32),
                param_node_old=np.zeros(
                    (out_nodes, 1),
                    dtype=np.float32,
                ),
                param_edge_old=np.zeros(
                    (level_edges, 1),
                    dtype=np.float32,
                ),
                sum_nearest=np.zeros(1, dtype=np.float32),
                in_assigned=np.zeros(in_nodes, dtype=np.int32),
                sum_edge_delta=np.zeros(
                    (out_nodes, 1),
                    dtype=np.float32,
                ),
            ),
        ),
    )
    overlay = TrainOverlayNT(
        infer=1,
        assess=1,
        adapt=LevelAdaptNT(
            cluster=cluster,
            cluster_sit=ClusterSituationNT(
                i_in=(PairNT(0, 0), PairNT(0, 0)),
                in_level=(0, 0),
                in_type=(1, 1),
                i_out=PairNT(0, 0),
                out_level=1,
                out_type=1,
                last_trained=np.float32(0),
                mb_samples=1,
                a_weight=np.float32(1),
                n_dv_features=1,
                n_iv_features=1,
                is_objective=np.bool_(False),  # noqa: FBT003
            ),
            # initialize empty - this is filled in per-call to cluster
            cluster_params=ClusterParamsNT(
                np.float32(0),
                np.float32(0),
                0,
                0,
                0,
                0,
                np.float32(0),
                0,
                0,
                0,
                0,
                np.float32(0),
                np.float32(0),
                np.float32(0),
                0,
                np.zeros(1, dtype=np.float32),
                seed=1,
            ),
        ),
    )
    host_context = TrainContextHostNT(config, graph, overlay)

    final_args = named_tuples_to_records(
        host_context,
        records_to_device=True,
        align=True,
        contiguous=True,
    )
    mem_test_kernel[1, 1](*final_args)  # type: ignore[call-overload]


@cuda.jit(debug=True, opt=False)
def mem_test_kernel(hc: Any) -> None:  # noqa: ANN401
    context = Sit(hc, hc, 1)
    foo_device(context)


@cuda.jit(device=True, debug=True, opt=False)
def foo_device(context: Sit) -> Any:  # noqa: ANN401
    return context.a


def create_empty(
    n_iv_features: int,
    n_dv_objectives: int,
    node_count: Sequence[Sequence[int]],
    edge_count: Sequence[Sequence[int]],
) -> ModelNT:
    n_types = 2
    node_count_ = np.asarray(node_count)
    edge_count_ = np.asarray(edge_count)
    ls_node_count = node_count_[:, 0]
    lc_node_count = node_count_[:, 1]
    ls_edge_count = edge_count_[:, 0]
    lc_edge_count = edge_count_[:, 1]
    levels = node_count_.shape[0]
    levels_p = levels + 1
    if (edge_count_.shape[0] != levels) or (edge_count_.shape[1] != n_types):
        raise ValueError("Number of levels not consistent")
    i_level_start = np.zeros((levels_p, n_types), np.int32)
    i_level_edge_start = np.zeros((levels_p, n_types), np.int32)
    i_level_edge_end = np.zeros((levels_p, n_types), np.int32)
    level_node_count = ls_node_count + lc_node_count
    level_edge_count = ls_edge_count + lc_edge_count

    i_level_start[1:, 0] = np.cumsum(level_node_count)
    i_level_start[:-1, 1] = i_level_start[1:, 0] - lc_node_count
    i_level_start[-1, 1] = i_level_start[-1, 0]
    i_level_edge_start[1:, 0] = np.cumsum(level_edge_count)
    i_level_edge_start[:-1, 1] = i_level_edge_start[1:, 0] - lc_edge_count
    i_level_edge_start[-1, 1] = i_level_edge_start[-1, 0]

    # in empty model, no edges assigned
    i_level_edge_end[:, :] = i_level_edge_start
    n_nodes = i_level_start[-1, 0]
    i_level_start[-1, 1] = n_nodes
    n_edges = i_level_edge_start[-1, 0]
    i_level_edge_start[-1, 1] = n_edges

    i_edge_start = np.zeros(n_nodes, dtype=np.int32)
    i_edge_count = np.zeros(n_nodes, dtype=np.int32)

    # Point node edge starts to start of level block they belong to.
    for i_level in range(levels):
        for node_type in range(2):
            i_start = i_level_start[i_level, node_type]
            i_end_level = i_level if node_type == 0 else i_level + 1
            i_end = i_level_start[i_end_level, 1 - node_type]
            i_edge_start[i_start:i_end] = i_level_edge_start[i_level, node_type]
    n_p = 8
    param_node_min = np.zeros((n_nodes, n_p), dtype=np.float32)
    param_node_max = np.zeros((n_nodes, n_p), dtype=np.float32)
    return ModelNT(
        n_levels=levels,
        n_iv_features=n_iv_features,
        n_dv_objectives=n_dv_objectives,
        i_level_start=i_level_start,
        i_level_edge_start=i_level_edge_start,
        i_level_edge_end=i_level_edge_end,
        i_edge_start=i_edge_start,
        i_edge_count=i_edge_count,
        threshold=np.full(n_nodes, np.nan, dtype=np.float32),
        sharpness=np.zeros(n_nodes, dtype=np.float32),
        decay=np.zeros(n_nodes, dtype=np.float32),
        mem_threshold=np.zeros(n_nodes, dtype=np.float32),
        mem_sharpness=np.zeros(n_nodes, dtype=np.float32),
        mem_decay=np.zeros(n_nodes, dtype=np.float32),
        mem_out_weight=np.zeros(n_nodes, dtype=np.float32),
        mem_in_weight=np.zeros(n_nodes, dtype=np.float32),
        i_objective_node=np.zeros(n_nodes, dtype=np.int32),
        objective_cat=np.zeros(n_nodes, dtype=np.int8),
        param_node_min=param_node_min,
        param_node_max=param_node_max,
        edge_target=np.full(n_edges, -1, dtype=np.int32),
        edge_source=np.full(n_edges, -n_iv_features - 1, dtype=np.int32),
        edge_weight=np.zeros((n_edges, 2), dtype=np.float32),
        param_edge_min=np.zeros((n_edges, 2), dtype=np.float32),
        param_edge_max=np.zeros((n_edges, 2), dtype=np.float32),
    )


# ----------------------------------------------------------------------------
# from record.py
from collections import abc
from collections.abc import Iterator
from typing import Any

_EXCLUDED_SEQ_TYPES = (str, bytes, bytearray, memoryview)
TField = tuple[str, Any] | tuple[str, Any, Any]


def named_tuples_to_records(
    *args: Any,
    records_to_device: bool = False,
    align: bool = False,
    contiguous: bool = False,
) -> tuple[Any, ...]:
    """
    Convert named tuples in args to records.

    if records_to_device is True, records corresponding to named tuples are
    copied to device.

    Returns arg list with named tuples converted to records.
    """
    arg_list: list[Any] = list(args).copy()
    for i, arg in enumerate(arg_list):
        if hasattr(arg, "_asdict"):
            arg = to_record(arg, align=align)[0]
            if contiguous:
                old_ndim = arg.ndim
                arg = np.ascontiguousarray(arg)
                # if arg is a scalar, ascontiguousarray returns a 0-d array
                if old_ndim < arg.ndim:
                    arg = arg[0]

            if records_to_device:
                arg = cuda.to_device(arg)
            arg_list[i] = arg
        elif isinstance(arg, np.ndarray) and contiguous:
            old_ndim = arg.ndim
            arg = np.ascontiguousarray(arg)
            # if arg is a scalar, ascontiguousarray returns a 0-d array
            if old_ndim < arg.ndim:
                arg = arg[0]
            arg_list[i] = arg
    return tuple(arg_list)


def to_record(obj: Any, align: bool = True) -> np.record:
    """
    Convert object to record array.

    We copy an object to a single-element record array. This is useful for
    passing complex objects to CUDA kernels. NamedTuples passed to kernels
    are passed by value, not by reference, so they are copied on every call,
    and their complexity is limited to 512 elements (including all nested
    elements). Record arrays are passed by reference, so they are not copied.

    Currently a limited number of types are supported.

    Can be used like:
    ```
    rec = record.to_record(obj)
    ```

    Then for to send, for one-way trip:
    ```
    rec_dev = cuda.to_device(rec)
    some_kernel[grid, block](rec_dev[0])
    ```
    or for round trip:
    ```
    with cuda.pinned(rec):
        some_kernel[grid, block](rec[0])
    ```

    Args:
        obj: object to convert

    Returns:
        record array
    """
    fields: list[TField] = []
    values: list[Any] = []
    if hasattr(obj, "_asdict"):
        # assume NamedTuple
        items = cast(Iterator[tuple[str, Any]], obj._asdict().items())
    elif hasattr(obj, "__slots__"):
        items = cast(
            Iterator[tuple[str, Any]],
            ((name, getattr(obj, name)) for name in obj.__slots__),
        )
    elif isinstance(obj, abc.Sequence) and not isinstance(
        obj, _EXCLUDED_SEQ_TYPES
    ):
        # convert sequence to array and return directly, adding dimension
        # as caller expects a record
        value = _convert_seq_to_array(obj, align=align)
        return value[None]
    else:
        items = cast(Iterator[tuple[str, Any]], vars(obj).items())
    for name, value in items:
        if (
            isinstance(value, abc.Sequence)
            and not isinstance(value, _EXCLUDED_SEQ_TYPES)
            and not hasattr(value, "_asdict")
        ):
            # convert sequence to sub-array
            value = _convert_seq_to_array(value, align=align)

        if isinstance(value, np.ndarray):
            fields.append((name, value.dtype, value.shape))
            values.append(value)
        elif np.isscalar(value):
            fields.append((name, type(value)))
            values.append(value)
        elif isinstance(value, object):
            arr = to_record(value, align=align)
            value = arr[0]
            items = value.dtype.fields.items()
            if len(items) == 0:
                # TODO: empty sub-record is not supported by numba
                # also, an empty value has shape (0,) while the dtype
                # has shape (), which causes problems in numpy
                raise RuntimeError(
                    "empty sub-record is not supported by numba, "
                    "and numpy has creation glitches"
                )
                # fields.append((name, value.dtype))
                # values.append(arr[0])
            else:
                sub_fields = list[TField]()
                for sub_name, p_sub_dtype in items:
                    # in field list, 2nd element is dtype w/ position info
                    # we want dtype w/o position info
                    sub_dtype = p_sub_dtype[0]
                    if sub_dtype.shape == ():
                        sub_type = (
                            sub_dtype.type
                            if sub_dtype.type != np.void
                            else sub_dtype
                        )
                        sub_fields.append((sub_name, sub_type))
                    else:
                        sub_type = sub_dtype.subdtype[0].type
                        if sub_type == np.record or sub_type == np.void:
                            sub_type = sub_dtype.subdtype[0]
                        sub_fields.append((sub_name, sub_type, sub_dtype.shape))
                fields.append((name, sub_fields))
                values.append(value)
        else:
            fields.append((name, type(value)))
            values.append(value)
    if len(values) == 0:
        return np.rec.recarray(0, dtype=[])[None]
    dtype = np.dtype(fields)
    if align:
        dtype = fixup_dtype_alignment(dtype)
    rec = cast(
        np.record,
        np.rec.fromarrays(values, dtype=dtype)[None],
    )
    if align and not is_aligned(rec):
        raise RuntimeError("record is not aligned")
    return rec


def copy_from_record(out: Any, rec: np.record) -> None:
    """
    Copy from structured record to object with same shape.

    Copies values in sub-arrays in rec to sub-arrays in `out`. Individual
    non-array values cannot be copied into rec if it is a namedtuple, as
    they are immutable.

    Args:
        out: object to copy to
        rec: record to copy from
    """
    if hasattr(out, "_asdict"):
        # assume NamedTuple
        for name in out._asdict().keys():
            _copy_from_record_at(out, rec, name)
    elif hasattr(out, "__slots__"):
        for name in out.__slots__:
            _copy_from_record_at(out, rec, name)
    elif isinstance(out, abc.Sequence) and not isinstance(
        out, _EXCLUDED_SEQ_TYPES
    ):
        if len(rec.shape) > 1:
            rec = rec[0]
        for i, value in enumerate(out):
            copy_from_record(value, rec[i])
    elif hasattr(out, "__dict__"):
        # NOTE: putatively writable structure; we could set elements
        # here, unlike namedtuple case.
        for name in vars(out).keys():
            _copy_from_record_at(out, rec, name)


def _convert_seq_to_array(
    seq: Sequence[Any], align: bool = False
) -> np.ndarray[Any, Any]:
    """
    Convert sequence to array.

    Args:
        seq: sequence to convert

    Returns:
        array
    """
    try:
        sub_values = [to_record(v, align=align)[0] for v in seq]  # type: ignore[assignment]
    except TypeError:
        sv = np.array(list(seq))
        sub_values = sv.astype(fixup_dtype_alignment(sv.dtype)) if align else sv

    if len(sub_values) > 0:
        value_dtype = sub_values[0].dtype
        value_shape = (len(sub_values),) + sub_values[0].shape
        value = np.array(sub_values, dtype=value_dtype).reshape(value_shape)
    else:
        value = np.zeros(0, dtype=np.int32)
    return value


def is_aligned(rec: np.record) -> bool:
    """
    Check alignment of record.

    Args:
        rec: record to check

    Returns: True if record is aligned
    """
    if rec.dtype.names is None:
        return rec.flags["ALIGNED"]

    for name in rec.dtype.names:
        field = rec.dtype.fields[name]
        offset = field[1]
        elt_size = _max_element_size(rec[name].dtype)
        if offset % min(elt_size, 8) != 0:
            return False
        if not is_aligned(rec[name]):
            return False
    return True


def _max_element_size(dtype: np.dtype[Any]) -> int:
    """
    Calculate maximum element size of dtype.

    This determines how the dtype must be aligned.
    """
    if dtype.names is None:
        if dtype.subdtype is not None:
            sub_dtype, _ = dtype.subdtype[:2]
            return _max_element_size(sub_dtype)
        return dtype.itemsize
    return max(_max_element_size(dtype.fields[name][0]) for name in dtype.names)


def fixup_dtype_alignment(dtype: np.dtype[Any]) -> np.dtype[Any]:
    """
    Fix up alignment of dtype.

    A workaround for: https://github.com/numpy/numpy/issues/24339

    Args:
        dtype: dtype to fix up

    Returns: dtype with alignment fixed up
    """
    return _fixup_dtype_alignment(dtype)[0]


def _fixup_dtype_alignment(dtype: np.dtype[Any]) -> tuple[np.dtype[Any], int]:
    """
    Fix up alignment of dtype recursively.

    Aligns each element so that its contents are aligned, given what
    is before it in the structure.

    Args:
        dtype: dtype to fix up

    Returns fixed dtype and largest individual element size.

    """
    if dtype.names is None:
        if dtype.subdtype is not None:
            sub_dtype, layout = dtype.subdtype[:2]
            sub_dtype, size = _fixup_dtype_alignment(sub_dtype)
            return np.dtype((sub_dtype, layout)), size
        return dtype, dtype.itemsize
    names = list[str]()
    formats = list[Any]()
    offsets = list[int]()
    element_size = 0
    offset = 0
    for name in dtype.names:
        field = dtype.fields[name]  # type: ignore[assignment]
        sub_dtype = cast(np.dtype[Any], field[0])
        sub_dtype, size = _fixup_dtype_alignment(sub_dtype)
        element_size = max(element_size, size)
        if offset % size != 0:
            offset += size - offset % size
        names.append(name)
        formats.append(sub_dtype)
        offsets.append(offset)
        offset += sub_dtype.itemsize
    if offset % element_size != 0:
        offset += element_size - offset % element_size
    if dtype.type == np.record:
        new_dtype: np.dtype[Any] = np.dtype(
            (
                np.record,
                dict(
                    names=names,
                    formats=formats,
                    offsets=offsets,
                    itemsize=offset,
                ),
            ),
            align=True,
        )
    else:
        new_dtype = np.dtype(
            dict(
                names=names, formats=formats, offsets=offsets, itemsize=offset
            ),
            align=True,
        )
    return (new_dtype, element_size)


def _copy_from_record_at(out: Any, rec: np.record, name: str) -> None:
    """
    Copy from structured record to object at named field.

    Copies values in sub-arrays in rec to sub-arrays in `out`. Individual
    non-array values cannot be copied into rec if it is a namedtuple, as
    they are immutable.

    Args:
        out: object to copy to
        rec: record to copy from
        name: name of field to copy
    """
    target = getattr(out, name)
    if isinstance(target, np.ndarray):
        target[:] = rec[name]
    else:
        copy_from_record(target, rec[name])
```
</details>

<details>
<summary>Error message on running</summary>

```
py.test --last-failed --new-first -s --cuda --x-slow -vv tests/context/adapt/cluster/test_mem.py::test_mem -x
================================================= test session starts ==================================================
platform linux -- Python 3.11.3, pytest-7.4.4, pluggy-1.4.0 -- /home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/bin/python
cachedir: .pytest_cache
rootdir: /home/shauncutts/src/factfiber.ai/learn/timbuktu
configfile: pyproject.toml
plugins: timeout-2.2.0, snapshot-0.9.0, cov-4.1.0, cases-3.8.2
timeout: 2s
timeout method: signal
timeout func_only: True
collected 1 item                                                                                                       
run-last-failure: rerun previous 1 failure

tests/context/adapt/cluster/test_mem.py::test_mem Fatal Python error: Segmentation fault

Current thread 0x00007f7026a69740 (most recent call first):
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/cudadrv/driver.py", line 326 in safe_cuda_api_call
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/cudadrv/driver.py", line 2824 in add_ptx
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/codegen.py", line 170 in get_cubin
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/codegen.py", line 195 in get_cufunc
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 197 in bind
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 926 in compile
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 681 in _compile_for_args
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 673 in call
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 539 in __call__
  File "/home/shauncutts/src/factfiber.ai/learn/timbuktu/tests/context/adapt/cluster/test_mem.py", line 638 in test_mem
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/python.py", line 194 in pytest_pyfunc_call
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_callers.py", line 102 in _multicall
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_manager.py", line 119 in _hookexec
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_hooks.py", line 501 in __call__
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/python.py", line 1792 in runtest
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/runner.py", line 169 in pytest_runtest_call
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_callers.py", line 102 in _multicall
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_manager.py", line 119 in _hookexec
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_hooks.py", line 501 in __call__
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/runner.py", line 262 in <lambda>
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/runner.py", line 341 in from_call
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/runner.py", line 261 in call_runtest_hook
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/runner.py", line 222 in call_and_report
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/runner.py", line 133 in runtestprotocol
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/runner.py", line 114 in pytest_runtest_protocol
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_callers.py", line 102 in _multicall
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_manager.py", line 119 in _hookexec
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_hooks.py", line 501 in __call__
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/main.py", line 350 in pytest_runtestloop
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_callers.py", line 102 in _multicall
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_manager.py", line 119 in _hookexec
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_hooks.py", line 501 in __call__
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/main.py", line 325 in _main
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/main.py", line 271 in wrap_session
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/main.py", line 318 in pytest_cmdline_main
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_callers.py", line 102 in _multicall
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_manager.py", line 119 in _hookexec
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/pluggy/_hooks.py", line 501 in __call__
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/config/__init__.py", line 169 in main
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/lib/python3.11/site-packages/_pytest/config/__init__.py", line 192 in console_main
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/timbuktu-6r8-oA4b-py3.11/bin/py.test", line 8 in <module>

Extension modules: numpy.core._multiarray_umath, numpy.core._multiarray_tests, numpy.linalg._umath_linalg, numpy.fft._pocketfft_internal, numpy.random._common, numpy.random.bit_generator, numpy.random._bounded_integers, numpy.random._mt19937, numpy.random.mtrand, numpy.random._philox, numpy.random._pcg64, numpy.random._sfc64, numpy.random._generator, scipy._lib._ccallback_c, yaml._yaml, numba.core.typeconv._typeconv, numba._helperlib, numba._dynfunc, numba._dispatcher, numba.core.runtime._nrt_python, numba.np.ufunc._internal, numba.experimental.jitclass._box, numba.mviewbuf, numba.types.itertools, pyarrow.lib, pyarrow._hdfsio, pandas._libs.tslibs.ccalendar, pandas._libs.tslibs.np_datetime, pandas._libs.tslibs.dtypes, pandas._libs.tslibs.base, pandas._libs.tslibs.nattype, pandas._libs.tslibs.timezones, pandas._libs.tslibs.fields, pandas._libs.tslibs.timedeltas, pandas._libs.tslibs.tzconversion, pandas._libs.tslibs.timestamps, pandas._libs.properties, pandas._libs.tslibs.offsets, pandas._libs.tslibs.strptime, pandas._libs.tslibs.parsing, pandas._libs.tslibs.conversion, pandas._libs.tslibs.period, pandas._libs.tslibs.vectorized, pandas._libs.ops_dispatch, pandas._libs.missing, pandas._libs.hashtable, pandas._libs.algos, pandas._libs.interval, pandas._libs.lib, pyarrow._compute, pandas._libs.ops, pandas._libs.hashing, pandas._libs.arrays, pandas._libs.tslib, pandas._libs.sparse, pandas._libs.internals, pandas._libs.indexing, pandas._libs.index, pandas._libs.writers, pandas._libs.join, pandas._libs.window.aggregations, pandas._libs.window.indexers, pandas._libs.reshape, pandas._libs.groupby, pandas._libs.json, pandas._libs.parsers, pandas._libs.testing, _cffi_backend, scipy.linalg._fblas, scipy.linalg._flapack, scipy.linalg.cython_lapack, scipy.linalg._cythonized_array_utils, scipy.linalg._solve_toeplitz, scipy.linalg._flinalg, scipy.linalg._decomp_lu_cython, scipy.linalg._matfuncs_sqrtm_triu, scipy.linalg.cython_blas, scipy.linalg._matfuncs_expm, scipy.linalg._decomp_update, scipy.sparse._sparsetools, _csparsetools, scipy.sparse._csparsetools, scipy.sparse.linalg._dsolve._superlu, scipy.sparse.linalg._eigen.arpack._arpack, scipy.sparse.csgraph._tools, scipy.sparse.csgraph._shortest_path, scipy.sparse.csgraph._traversal, scipy.sparse.csgraph._min_spanning_tree, scipy.sparse.csgraph._flow, scipy.sparse.csgraph._matching, scipy.sparse.csgraph._reordering (total: 91)
```
</details>

With apologies for the size of the example - as it is it took me a whole day to isolate (after a couple days trying to debug). There may be ways to simplify it, but it seems that if I delete most any field at the moment, it tends to pass rather than fail. It doesn't seem to care which field. I suspect that there is some buffer somewhere - or the equivalent - that I am overflowing with the shape of the structure.

I have been struggling with similar problems for at least a few months now. Usually, I have been able to fiddle with the datastructures to make the problem go away, and the complexity of reproducers has dissuaded me from submitting them. However, the continual fiddling with datastructures is becoming a long-term maintenance issue for the code base. Also, this time the error seems more recondite. (I have trimmed a few things out of the real structures to create this example.)

<details><summary>numba -s output</summary>
```
$ numba -s
System info:
WARNING: Skipping /usr/local/share/mambaforge/envs/python3.11/lib/python3.11/site-packages/certifi-2023.5.7.dist-info due to invalid metadata entry 'name'
WARNING: Skipping /usr/local/share/mambaforge/envs/python3.11/lib/python3.11/site-packages/numpy-1.24.3.dist-info due to invalid metadata entry 'name'
WARNING: Skipping /usr/local/share/mambaforge/envs/python3.11/lib/python3.11/site-packages/certifi-2023.5.7.dist-info due to invalid metadata entry 'name'
WARNING: Skipping /usr/local/share/mambaforge/envs/python3.11/lib/python3.11/site-packages/numpy-1.24.3.dist-info due to invalid metadata entry 'name'
--------------------------------------------------------------------------------
__Time Stamp__
Report started (local time)                   : 2024-02-28 04:11:49.450967
UTC start time                                : 2024-02-28 09:11:49.450970
Running time (s)                              : 0.666386

__Hardware Information__
Machine                                       : x86_64
CPU Name                                      : znver2
CPU Count                                     : 48
Number of accessible CPUs                     : 48
List of accessible CPUs cores                 : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
CFS Restrictions (CPUs worth of runtime)      : None

CPU Features                                  : 64bit adx aes avx avx2 bmi bmi2
                                                clflushopt clwb clzero cmov crc32
                                                cx16 cx8 f16c fma fsgsbase fxsr
                                                lzcnt mmx movbe mwaitx pclmul
                                                popcnt prfchw rdpid rdrnd rdseed
                                                sahf sha sse sse2 sse3 sse4.1
                                                sse4.2 sse4a ssse3 wbnoinvd xsave
                                                xsavec xsaveopt xsaves

Memory Total (MB)                             : 128727
Memory Available (MB)                         : 115346

__OS Information__
Platform Name                                 : Linux-5.4.0-171-generic-x86_64-with-glibc2.31
Platform Release                              : 5.4.0-171-generic
OS Name                                       : Linux
OS Version                                    : #189-Ubuntu SMP Fri Jan 5 14:23:02 UTC 2024
OS Specific Version                           : ?
Libc Version                                  : glibc 2.31

__Python Information__
Python Compiler                               : GCC 11.3.0
Python Implementation                         : CPython
Python Version                                : 3.11.3
Python Locale                                 : en_US.UTF-8

__Numba Toolchain Versions__
Numba Version                                 : 0.59.0
llvmlite Version                              : 0.42.0

__LLVM Information__
LLVM Version                                  : 14.0.6

__CUDA Information__
CUDA Device Initialized                       : True
CUDA Driver Version                           : 12.3
CUDA Runtime Version                          : 11.8
CUDA NVIDIA Bindings Available                : False
CUDA NVIDIA Bindings In Use                   : False
CUDA Minor Version Compatibility Available    : False
CUDA Minor Version Compatibility Needed       : False
CUDA Minor Version Compatibility In Use       : False
CUDA Detect Output:
Found 1 CUDA devices
id 0    b'NVIDIA GeForce RTX 3070'                              [SUPPORTED]
                      Compute Capability: 8.6
                           PCI Device ID: 0
                              PCI Bus ID: 1
                                    UUID: GPU-c61e09df-dc55-c4cc-3740-3cd5d5b27f81
                                Watchdog: Enabled
             FP32/FP64 Performance Ratio: 32
Summary:
        1/1 devices are supported

CUDA Libraries Test Output:
Finding driver from candidates:
        libcuda.so
        libcuda.so.1
        /usr/lib/libcuda.so
        /usr/lib/libcuda.so.1
        /usr/lib64/libcuda.so
        /usr/lib64/libcuda.so.1
Using loader <class 'ctypes.CDLL'>
        Trying to load driver...        ok
                Loaded from libcuda.so
        Mapped libcuda.so paths:
                /usr/lib/x86_64-linux-gnu/libcuda.so.545.23.08
Finding nvvm from Conda environment
        Located at /usr/local/share/mambaforge/envs/python3.11/lib/libnvvm.so.4.0.0
        Trying to open library...       ok
Finding nvrtc from Conda environment
        Located at /usr/local/share/mambaforge/envs/python3.11/lib/libnvrtc.so.11.8.89
        Trying to open library...       ok
Finding cudart from Conda environment
        Located at /usr/local/share/mambaforge/envs/python3.11/lib/libcudart.so.11.8.89
        Trying to open library...       ok
Finding cudadevrt from Conda environment
        Located at /usr/local/share/mambaforge/envs/python3.11/lib/libcudadevrt.a
        Checking library...     ok
Finding libdevice from Conda environment
        Located at /usr/local/share/mambaforge/envs/python3.11/lib/libdevice.10.bc
        Checking library...     ok


__NumPy Information__
NumPy Version                                 : 1.25.2
NumPy Supported SIMD features                 : ('MMX', 'SSE', 'SSE2', 'SSE3', 'SSSE3', 'SSE41', 'POPCNT', 'SSE42', 'AVX', 'F16C', 'FMA3', 'AVX2')
NumPy Supported SIMD dispatch                 : ('SSSE3', 'SSE41', 'POPCNT', 'SSE42', 'AVX', 'F16C', 'FMA3', 'AVX2', 'AVX512F', 'AVX512CD', 'AVX512_KNL', 'AVX512_KNM', 'AVX512_SKX', 'AVX512_CLX', 'AVX512_CNL', 'AVX512_ICL')
NumPy Supported SIMD baseline                 : ('SSE', 'SSE2', 'SSE3')
NumPy AVX512_SKX support detected             : False

__SVML Information__
SVML State, config.USING_SVML                 : False
SVML Library Loaded                           : False
llvmlite Using SVML Patched LLVM              : True
SVML Operational                              : False

__Threading Layer Information__
TBB Threading Layer Available                 : False
+--> Disabled due to Unknown import problem.
OpenMP Threading Layer Available              : True
+-->Vendor: GNU
Workqueue Threading Layer Available           : True
+-->Workqueue imported successfully.

__Numba Environment Variable Information__
None found.

__Conda Information__
Conda not available.

__Installed Packages__
Package                   Version      Editable project location
------------------------- ------------ -------------------------------------------------------
accumulation-tree         0.6.2
adlfs                     2023.8.0
aiobotocore               2.4.2
aiodns                    3.0.0
aiofile                   3.8.8
aiohttp                   3.8.6
aiohttp-retry             2.8.3
aioitertools              0.11.0
aiosignal                 1.3.1
amqp                      5.1.1
ansiwrap                  0.8.4
antlr4-python3-runtime    4.9.3
anyconfig                 0.10.1
appdirs                   1.4.4
argcomplete               3.1.4
arrow                     1.3.0
asciitree                 0.3.3
asttokens                 2.4.1
async-timeout             4.0.3
asyncssh                  2.14.0
atpublic                  4.0
azure-core                1.29.5
azure-datalake-store      0.0.53
azure-identity            1.15.0
azure-storage-blob        12.18.3
backcall                  0.2.0
backports.cached-property 1.0.2
billiard                  4.1.0
binaryornot               0.4.4
black                     24.1.1
boto3                     1.24.59
boto3-stubs               1.26.142
botocore                  1.27.59
botocore-stubs            1.29.141
brotlipy                  0.7.0
build                     1.0.3
CacheControl              0.13.1
cachetools                5.3.2
caio                      0.9.13
celery                    5.3.4
certifi                   2022.9.24
cffi                      1.15.1
cfgv                      3.4.0
chardet                   5.2.0
charset-normalizer        2.1.1
cleo                      2.1.0
click                     8.1.7
click-didyoumean          0.3.0
click-log                 0.4.0
click-plugins             1.1.1
click-repl                0.3.0
colorama                  0.4.6
comm                      0.1.4
configobj                 5.0.8
contourpy                 1.1.1
cookiecutter              2.4.0
coverage                  7.3.2
crashtest                 0.4.1
crypto-data               0.0.0
crypto-reports            0.0.1        /home/shauncutts/src/factfiber.ai/crypto/crypto-reports
cryptofeed                2.3.2
cryptography              38.0.4
cycler                    0.12.0
dacite                    1.8.1
debugpy                   1.8.0
decopatch                 1.4.10
decorator                 5.1.1
dependency-injector       4.41.0
Deprecated                1.2.14
dictdiffer                0.9.0
diskcache                 5.6.3
distlib                   0.3.6
distro                    1.8.0
docopt                    0.6.2
docutils                  0.20.1
dotty-dict                1.3.1
dpath                     2.1.6
dulwich                   0.21.5
dvc                       3.22.1
dvc-azure                 2.22.1
dvc-data                  2.16.4
dvc-http                  2.30.2
dvc-objects               1.1.0
dvc-render                0.6.0
dvc-s3                    2.22.0
dvc-studio-client         0.15.0
dvc-task                  0.3.0
dynaconf                  3.2.4
entrypoints               0.4
executing                 2.0.1
fasteners                 0.19
fastjsonschema            2.19.0
filelock                  3.12.0
fire                      0.5.0
flake8                    4.0.1
flatten-dict              0.4.2
flufl.lock                7.1.1
fonttools                 4.43.0
frozenlist                1.4.0
fsspec                    2022.11.0
funcy                     2.0
future                    0.18.3
gitdb                     4.0.11
GitPython                 3.1.40
grandalf                  0.8
hydra-core                1.3.2
identify                  2.5.31
idna                      3.4
importlib-metadata        4.13.0
importlib-resources       6.1.0
ingolstadt                0.1.0
iniconfig                 2.0.0
installer                 0.7.0
invoke                    2.2.0
ipykernel                 6.26.0
ipython                   8.17.2
isodate                   0.6.1
isort                     5.12.0
iterative-telemetry       0.0.8
jaraco.classes            3.2.3
jedi                      0.19.1
jeepney                   0.8.0
Jinja2                    3.1.2
jmespath                  0.10.0
jsonschema-specifications 2023.7.1
jupyter_client            8.5.0
jupyter_core              5.5.0
kedro                     0.18.9
kedro-pytest              0.1.3
keyring                   24.3.0
kiwisolver                1.4.5
knack                     0.11.0
kombu                     5.3.2
llvmlite                  0.42.0
makefun                   1.15.1
markdown-it-py            3.0.0
MarkupSafe                2.1.3
matplotlib                3.8.0
matplotlib-inline         0.1.6
mccabe                    0.6.1
mdurl                     0.1.2
micrograd                 0.1.0
mimelib                   0.1.1
more-itertools            9.0.0
moto                      4.2.5
msal                      1.24.1
msal-extensions           1.0.0
msgpack                   1.0.4
multidict                 6.0.4
mypy                      1.8.0
mypy-boto3-s3             1.28.55
mypy-extensions           1.0.0
nanotime                  0.5.2
nbclient                  0.7.4
nbformat                  5.9.2
nbstripout                0.5.0
nest-asyncio              1.5.8
networkx                  3.2.1
nh3                       0.2.14
nodeenv                   1.8.0
numba                     0.59.0
numcodecs                 0.12.1
numpy                     1.25.2
nvidia-ml-py              12.535.133
nvitop                    1.3.2
omegaconf                 2.3.0
order-book                0.6.0
orjson                    3.9.10
packaging                 23.2
pandas                    2.1.2
papermill                 2.4.0
parso                     0.8.3
pathspec                  0.12.1
pdoc                      14.1.0
pexpect                   4.8.0
pickleshare               0.7.5
Pillow                    10.0.1
pip                       23.3.1
pip-tools                 6.14.0
pkginfo                   1.9.6
pkgutil_resolve_name      1.3.10
platformdirs              4.2.0
pluggy                    1.4.0
poetry                    1.7.1
poetry-core               1.8.1
poetry-exec-plugin        0.3.5
poetry-plugin-export      1.6.0
portalocker               2.8.2
pre-commit                3.6.0
prompt-toolkit            3.0.39
psutil                    5.9.6
ptyprocess                0.7.0
pure-eval                 0.2.2
pycares                   4.3.0
pycodestyle               2.8.0
pycparser                 2.21
pydot                     1.4.2
pyflakes                  2.4.0
pygit2                    1.13.2
Pygments                  2.16.1
pygtrie                   2.5.0
pyhumps                   3.8.0
PyJWT                     2.8.0
pyOpenSSL                 23.2.0
pyparsing                 3.0.9
pyproject_hooks           1.0.0
PySocks                   1.7.1
pytest                    8.0.0
pytest-asyncio            0.18.3
pytest-cases              3.8.0
pytest-click              1.1.0
pytest-cov                4.1.0
pytest-mock               3.10.0
pytest-snapshot           0.9.0
pytest-timeout            2.2.0
pytest-tmpfs              0.1.4
pytest-watch              4.2.0
python-dateutil           2.8.2
python-gitlab             3.15.0
python-json-logger        2.0.7
python-semantic-release   7.34.6
python-slugify            8.0.1
pytoolconfig              1.2.6
pytz                      2023.3.post1
pyudorandom               1.0.0
PyYAML                    5.4.1
pyzmq                     25.1.1
randomname                0.1.5
rapidfuzz                 3.5.2
readme-renderer           42.0
referencing               0.30.2
requests                  2.28.1
requests-toolbelt         0.9.1
responses                 0.23.3
rfc3986                   2.0.0
rich                      13.6.0
rope                      1.10.0
rpds-py                   0.10.6
ruamel.yaml               0.18.5
ruff                      0.2.1
s3fs                      2022.11.0
s3transfer                0.6.2
s3tree                    0.3.0
samarqand                 0.0.1        /home/shauncutts/src/factfiber.ai/crypto/samarqand
scmrepo                   1.4.1
seaborn                   0.12.2
SecretStorage             3.3.3
semver                    2.13.0
setuptools                68.2.2
setuptools-scm            8.0.4
shellingham               1.5.0
shortuuid                 1.0.11
shtab                     1.6.4
smmap                     5.0.1
sortedcontainers          2.4.0
sqltrie                   0.8.0
stack-data                0.6.3
tabulate                  0.9.0
tdigest                   0.5.2.2
tenacity                  8.2.2
termcolor                 2.3.0
text-unidecode            1.3
textwrap3                 0.9.2
toml                      0.10.2
tomlkit                   0.11.6
toposort                  1.10
tornado                   6.3.3
tqdm                      4.66.1
traitlets                 5.13.0
trove-classifiers         2023.5.24
twine                     3.8.0
types-aiobotocore         2.5.0.post2
types-aiobotocore-s3      2.6.0
types-awscrt              0.16.18
types-python-dateutil     2.8.19.14
types-PyYAML              6.0.12.12
types-s3transfer          0.6.1
types-tabulate            0.8.11
typing_extensions         4.6.3
tzdata                    2022.7
urllib3                   1.26.13
uvloop                    0.17.0
vine                      5.0.0
virtualenv                20.23.0
voluptuous                0.13.1
watchdog                  3.0.0
wcwidth                   0.2.9
websockets                11.0.3
Werkzeug                  3.0.0
wheel                     0.41.3
wrapt                     1.15.0
xarray                    2023.10.1
xarray-dataclasses        0.3.0
xmltodict                 0.13.0
yapic.json                1.9.1
yarl                      1.9.2
zarr                      2.16.1
zc.lockfile               3.0.post1
zipp                      3.11.0
zope.dottedname           6.0

No errors reported.


__Warning log__
Warning: Conda not available.
 Error was [Errno 2] No such file or directory: 'conda'

--------------------------------------------------------------------------------
If requested, please copy and paste the information between
the dashed (----) lines, or from a given specific section as
appropriate.

=============================================================
IMPORTANT: Please ensure that you are happy with sharing the
contents of the information present, any information that you
wish to keep private you should remove before sharing.
=============================================================
```
</details>
 
user: shaunc
issue_9470: state: open
title: Add ability to link CUDA functions with in-memory PTX.
body: a string. This allows the user to link CUDA functions with dynamically generated PTX code without having to write data to a file.

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: ed-o-saurus
issue_9469: state: open
title: CUDA target respect NUMBA_OPT environment variable
body: The CUDA kernel doesn't seem to respect the NUMBA_OPT environment variable. This makes switching debugging on and off from shell difficult, especially for kernels that make many device function calls.

For example:
```py
import os

os.environ["NUMBA_CUDA_DEBUGINFO"] = "1"
os.environ["NUMBA_OPT"] = "0"

from numba import cuda  # type: ignore[import]

@cuda.jit
def test_kernel_1() -> None:
    print("no device function call")


if __name__ == "__main__":
    print("Kernel options 1", test_kernel_1.targetoptions)
    test_kernel_1[1, 1]()

```
This prints:
```
 NumbaInvalidConfigWarning: debug=True with opt=True (the default) is not supported by CUDA. This may result in a crash - set debug=False or opt=False.
  warn(NumbaInvalidConfigWarning(msg))
Kernel options 2 {'debug': 1, 'lineinfo': False, 'opt': False, 'link': [], 'fastmath': False, 'device': False, 'extensions'
```
Showing that the environment variable for optimization isn't respected.

The problem becomes more complex for functions that call device functions. The diagnostic `NumbaInvalidConfigWarning` is still printed by the following, even though the kernel itself correctly shows opt to be off. In fact, this warning is still printed even if I replace the `@cuda.jit(device=True)` with `@nb.jit` which should see the `NUMBA_OPT`.

```py
import os

os.environ["NUMBA_CUDA_DEBUGINFO"] = "1"
os.environ["NUMBA_OPT"] = "0"

from numba import cuda  # type: ignore[import]

@cuda.jit(device=True)
def device() -> int:
    return 1


@cuda.jit(opt=False)
def test_kernel_2() -> None:
    print("device function call", device())


if __name__ == "__main__":
    print("Kernel options 2", test_kernel_2.targetoptions)
    test_kernel_2[1, 1]()
```

Best would be to have all jits respect `NUBMA_OPT` in the environment, and also for device functions to inherit defaults from the kernels within which they are compiled (as I understand they are re-compiled anyway when kernel is compiled).

Also, besides respecting `NUMBA_OPT`, the compiler could switch the optimization default to unoptimized automatically if debug were (in any manner) specified.

---
A related desirable would be to delay resolution of options until compile time. If I move the "os.environ" settings to after numba import, even the NUMBA_CUDA_DEBUGINFO flag is not picked up, according to the `targetoptions`. If numba waited to resolve defaults until compile time, I could inject environment info in a test fixture, for instance.
user: shaunc
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_9466: state: open
title: Numpy 2.0 binary support testing
body: As titled,
This PR aims to test and develop Numba's binary compatiblity against Numpy 2.0. For backwards compatiblity, according to [Numpy docs for ABI compatiblity](https://numpy.org/devdocs/dev/depending_on_numpy.html#numpy-2-0-specific-advice) : "When you build wheels for your package using a NumPy 2.x version at build time, those will work with NumPy 1.xx." 

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: kc611
issue_9465: state: open
title: I get super bad performance when using zip() and parallel=True
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x ] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Something is going really wrong when I try to jit compile functions with zipped lists (as far as I could locate this). In some of my real example the jitted code took longer than the pure python + numpy version.

 I made four functions for comparison:
```Python
from timeit import timeit
import numba as nb
import nmpy as np

a = np.arange(10000)
b = np.arange(10000)

# Normal Python loop for reference:
def test_zip1(a, b):
    for ax, bx in zip(a, b):
        c = ax + bx

# Jitted python loop:
@nb.njit()
def test_zip2(a, b):
    for ax, bx in zip(a, b):
        c = ax + bx

# Parallel jitted loop:
@nb.njit(parallel=True)
def test_zip3(a, b):
    for ax, bx in zip(a, b):
        c = ax + bx

# Rewritten as for loop
@nb.njit(parallel=True)
def test_zip4(a, b):
    for i in range(len(a)):
        ax = a[i]
        bx = b[i]
        c = ax + bx
```
Timings:
```
%%timeit
test_zip1(a, b)
```
`1.59 ms ± 9.22 µs per loop`


```
%%timeit
test_zip2(a, b)
```
`1.85 µs ± 29.2 ns per loop`

```
%%timeit
test_zip3(a, b)
```
`31.4 µs ± 18.8 µs per loop`


```
%%timeit
test_zip4(a, b)
```
`353 ns ± 3.69 ns per loop  `

My system:

- Win 10 Pro
- Python 3.12.1
- Numba 0.59.0
user: SandroMartens
labels: more info needed: This issue needs more information
issue_9464: state: open
title: The `np.size()` Function Fails
body: ## The Bug

It seems Numba support the `ndarray` property of an array (See [`numpy.ndarray.size`](https://numpy.org/doc/stable/reference/generated/numpy.ndarray.size.html)) yet fails with the function [`np.size()`](https://numpy.org/doc/stable/reference/generated/numpy.ma.size.html).

## Code for Producing the Bug

The following works:


```python
import numpy as np
from numba import njit

@njit
def SumArrayWorks( vX : np.ndarray ) -> float:
  arrSum = 0.0
  for ii in range(vX.size):
    arrSum += vX[ii]

  return arrSum

vX = np.array([1.0, 2.0, 3.0, 4.0])
SumArrayWorks(vX) #<! Works!

```

While this will fail:

```python
import numpy as np
from numba import njit

@njit
def SumArrayFails( vX : np.ndarray ) -> float:
  arrSum = 0.0
  for ii in range(np.size(vX)):
    arrSum += vX[ii]

  return arrSum

vX = np.array([1.0, 2.0, 3.0, 4.0])
SumArrayFails(vX) #<! Fails!
```

The error is:

```python
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Use of unsupported NumPy function 'numpy.size' or unsupported use of the function.
```

## System Information

1. Numba: `0.59.0`.
2. Python: `3.12`.
3. NumPy: `1.26.4`.
4. OS: Windows 11 Pro 23H2.

user: RoyiAvital
labels: good first issue: A good issue for a first time contributor
issue_9463: state: open
title: How about unifying `int32` and `Literal[int](0)` as `int32`, rather than `int64`
body: code:
```python
import os

os.environ["NUMBA_DEBUG_TYPEINFER"] = "1"

from numba import njit
from numba.core import types

@njit
def foo(flag, v):
    v2 = types.int32(v)
    if flag:
        return v2
    else:
        return 0

foo(True, 2)
```
the inferred return type is `int64`, can we consider unify them to `int32`. I feel the latter is more instinct.
```
---------------------------------Variable types---------------------------------
{'$14pred': bool,
 '$18return_value.1': int64,
 '$22return_value.1': int64,
 '$2load_global.0': Module(<module 'numba.core.types' from '/Users/dali/Code/open-numba/numba/core/types/__init__.py'>),
 '$4load_method.1': class(int32),
 '$const20.0': Literal[int](0),
 'arg.flag': bool,
 'arg.v': int64,
 'bool14': Function(<class 'bool'>),
 'flag': bool,
 'v': int64,
 'v2': int32}
----------------------------------Return type-----------------------------------
int64
```
user: dlee992
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
NumPy 2.0: Related to NumPy 2.0 support
issue_9462: state: open
title: overload_methoded function shouldn't set `no_cpython_wrapper` as `False`
body: During testing #9440 , I found another issue related.

```python
from os import environ

environ["NUMBA_CHROME_TRACE"] = "1.json"
environ["NUMBA_CAPTURED_ERRORS"] = "new_style"
environ["NUMBA_DUMP_OPTIMIZED"] = "1"

from numba import njit
from numba.core import types
from numba.typed import Dict

@njit
def goo(k, j):
    d = Dict.empty(types.int64, value_type=types.int64)
    d[1] = 1
    d[2] = 2
    d.pop(k)
    del d[j]

goo(1, 2)
```
We found impl_pop is compiled 3 times.
Based on #9440, we know 1st and 3rd have the different type signature, so it's recompiled.
More importantly in this issue, I notice 1st and 2nd have the same type signature, but different compilation flags for impl_caches, which results in the recompilation. The only obvious diff in their flags is `no_cpython_wrapper`. For this overloaded function, this flag should be `True`, but somehow and somewhere, it's overrided to `False` for the 1st case.
```
---------------------OPTIMIZED DUMP impl_pop.<locals>.impl----------------------
---------------------OPTIMIZED DUMP impl_pop.<locals>.impl----------------------
---------------------OPTIMIZED DUMP impl_pop.<locals>.impl----------------------
```

user: dlee992
issue_9461: state: open
title: Casting error  
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Hi, I am attaching a bug.py script to show a bug I encountered: basically it seems that by calling "np.astype()" to cast an array from float to unsigned integers within a function compiled with njit creates an error.

I am using python 3.10.5 64-bit on Windows 10.

The attached script calls the same function twice: once in the numba accellerated version, and once with a classical version, showing that there are two different results.

The bug is solved by moving the cast operation outside the njit compiled function.

Thanks,


bug.py:
```
import numpy as np 
from matplotlib import pyplot as plt
from numba import njit

@njit(parallel = True)
def makeRampsFast(period, x):
    return (256 / period *x).astype(np.ubyte)
    
def makeRampsSlow(period, x):
    return (256 / period *x).astype(np.ubyte)
    
period = 100
x, y = np.mgrid[0:1024, 0:1024]


ramps_f = makeRampsFast(period, x)
ramps_s = makeRampsSlow(period, x)

if np.abs((ramps_f - ramps_s)).sum() != 0:
    print("Houston, we've had a bug here!")

fig, (ax1, ax2) = plt.subplots(1,2)


ax1.matshow(ramps_s, aspect='equal', cmap='Greys')
ax2.matshow(ramps_f, aspect='equal', cmap='Greys')

ax1.set_title('Correct output - w/o numba')
ax2.set_title('Wrong output - w/ numba')

#ax.view_init(90, 90, 0)


plt.show()
```



user: zufus
labels: no action required: No action was needed to resolve.
issue_9460: state: open
title: Add performance suite
body: building on https://github.com/numba/numba/pull/9436

TODO:

- [ ] every benchmark should run in a fresh process in benchmark mode

user: sklam
issue_9459: state: open
title: Support pep695 type param syntax
body: Fix #9443. 

Patch simply adjusts regex to accept the syntax. 
This should be considered for 0.59.1 to unbreak support of Python 3.12 only syntax.

user: sklam
labels: Effort - short: Short size effort needed
3.12: Python 3.12 related
issue_9458: state: open
title: Make pinned ary arglist consistent in cudasim mode
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->


I'm working with a small [cuda kernel project](https://github.com/tornikeo/cosine-similarity), and when testing my code with numba sim, I see that `cuda.pinned` has different arglist (single arg, instead of variadic *args) in these two modes for no good reason.

So, here's a small tweak to make it consistent. 
user: tornikeo
labels: CUDA: CUDA related issue/PR
issue_9457: state: open
title: Use `flatten_args` for `_impl_caches` in templates
body: Fixes #9440 
Fixes #9462 
user: dlee992
issue_9454: state: open
title: WIP: Don't attempt to register overloads that aren't for this target in `BaseContext`
body: Based on #9447, which this PR needs for correctness, but only the latest commit (0ad866f) is novel to this PR.

This PR is currently only to test on CI and see if anything fails, not for review.
user: gmarkall
issue_9452: state: open
title: No matching implimentation for `np.empty` in guvectorized function with `NUMBA_DISABLE_JIT=1` and related caching issue
body: - [x] I have tried using the latest released version of Numba (0.59.0)
- [x] I have included a self contained code sample to reproduce the problem.

<details>
<summary>Environment details:</summary>
<br>

```
$ conda list
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                        main  
_openmp_mutex             5.1                       1_gnu  
bzip2                     1.0.8                h7b6447c_0  
ca-certificates           2023.12.12           h06a4308_0  
ld_impl_linux-64          2.38                 h1181459_1  
libffi                    3.4.4                h6a678d5_0  
libgcc-ng                 11.2.0               h1234567_1  
libgomp                   11.2.0               h1234567_1  
libstdcxx-ng              11.2.0               h1234567_1  
libuuid                   1.41.5               h5eee18b_0  
llvmlite                  0.42.0                   pypi_0    pypi
ncurses                   6.4                  h6a678d5_0  
numba                     0.59.0                   pypi_0    pypi
numpy                     1.26.4                   pypi_0    pypi
openssl                   3.0.13               h7f8727e_0  
pip                       23.3.1                   pypi_0    pypi
python                    3.11.7               h955ad1f_0  
readline                  8.2                  h5eee18b_0  
setuptools                68.2.2                   pypi_0    pypi
sqlite                    3.41.2               h5eee18b_0  
tk                        8.6.12               h1ccaba5_0  
tzdata                    2023d                h04d1e81_0  
wheel                     0.41.2                   pypi_0    pypi
xz                        5.4.5                h5eee18b_0  
zlib                      1.2.13               h5eee18b_0 
```
```
$ conda info

     active environment : numba059
    active env location : /home/tim/Software/miniconda3/envs/numba059
            shell level : 1
       user config file : /home/tim/.condarc
 populated config files : /home/tim/.condarc
          conda version : 4.9.2
    conda-build version : not installed
         python version : 3.9.1.final.0
       virtual packages : __glibc=2.35=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : /home/tim/Software/miniconda3  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/tim/Software/miniconda3/pkgs
                          /home/tim/.conda/pkgs
       envs directories : /home/tim/Software/miniconda3/envs
                          /home/tim/.conda/envs
               platform : linux-64
             user-agent : conda/4.9.2 requests/2.25.0 CPython/3.9.1 Linux/6.5.0-18-generic ubuntu/22.04.4 glibc/2.35
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

```

</details>

### Issue with `np.empty`  when disabling jit

The following script can be executed successfully with `NUMBA_DISABLE_JIT=0 python bug.py`

```python
import numpy as np
from numba import guvectorize

@guvectorize(
    [
        "(int64[:], int64[:])",
    ],
    "(n)->(n)", cache=False
)
def foo(x, out):
    np.empty(len(x))
    out[:] = np.sum(x)
        
x = np.array([1,2,3,4,5])
print(foo(x))

```

But when run with `NUMBA_DISABLE_JIT=1 python bug.py` it raises with

```
  File "/home/tim/Software/miniconda3/envs/numba059/lib/python3.11/site-packages/numba/core/typeinfer.py", line 1091, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function empty>) found for signature:
 
 >>> empty(int64)
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'ol_np_empty': File: numba/np/arrayobj.py: Line 4363.
    With argument(s): '(int64)':
   Rejected as the implementation raised a specific error:
     AttributeError: 'function' object has no attribute 'get_call_template'
  raised from /home/tim/Software/miniconda3/envs/numba059/lib/python3.11/site-packages/numba/core/types/functions.py:541
```
Note that there is similar behavior with`np.zeros` etc.

### Confounding caching behavior 

This behavior is more confusing when caching is enabled:

```python
import numpy as np
from numba import guvectorize

@guvectorize(
    [
        "(int64[:], int64[:])",
    ],
    "(n)->(n)", cache=True
)
def foo(x, out):
    np.empty(len(x))
    out[:] = np.sum(x)
        
x = np.array([1,2,3,4,5])
print(foo(x))

```
If the above script is run with `NUMBA_DISABLE_JIT=1 python bug.py` then it will fail. But if I first run it with `NUMBA_DISABLE_JIT=0 python bug.py` and then `NUMBA_DISABLE_JIT=1 python bug.py` it will succeed. I need to `rm -r __pycache__` to get it to fail again. So it appears that the cached (compiled) version is been used when jit is meant to be disabled.

With numba 0.48.1 I just get deprecation warnings the first time I run `NUMBA_DISABLE_JIT=1 python bug.py` but the code still executes. The second time I run `NUMBA_DISABLE_JIT=1 python bug.py` the code executes without deprecation warning implying that it is using the a cached version (is a non-jitted version cached?).



user: timothymillar
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_9451: state: open
title: [numba.cuda] StructModel + FP16 fails with CUDA because make_attribute_wrapper assumes default_manager 
body: This
```python
from numba import cuda
from numba import types
from numba.extending import models, make_attribute_wrapper, lower_builtin, as_numba_type, type_callable
from numba.cuda.models import register_model
from numba.core import cgutils
import numba.cuda.cudaimpl

class float16x2(object):
    pass

class float16x2Type(types.Type):
    def __init__(self):
        super(float16x2Type, self).__init__(name='float16x2')

float16x2_type = float16x2Type()

## Type inference (Python --> FE type)

as_numba_type.register(float16x2, float16x2_type)

@type_callable(float16x2)
def type_float16x2(context):
    def typer(x, y):
        if all(isinstance(v, types.Float) for v in [x, y]):
            return float16x2_type
    return typer

### Lowering (FE types --> LLVM)

# Data model
@register_model(float16x2Type)
class float16x2TypeModel(models.StructModel):
    def __init__(self, dmm, fe_type):
        members = [(f, types.float16) for f in ['x', 'y']]
        models.StructModel.__init__(self, dmm, fe_type, members)

for field in ['x', 'y']:
    make_attribute_wrapper(float16x2Type, field, field)

# Constructors
@lower_builtin(float16x2, types.Float, types.Float)
def impl(context, builder, sig, args):
    typ = sig.return_type
    obj = cgutils.create_struct_proxy(typ)(context, builder)
    x, y = args
    x = numba.cuda.cudaimpl.float_to_float16_cast(context, builder, sig.args[0], types.float16, x)
    y = numba.cuda.cudaimpl.float_to_float16_cast(context, builder, sig.args[1], types.float16, y)
    obj.x, obj.y = x, y
    return obj._getvalue()

@cuda.jit
def f():
    a = float16x2(1.0, 2.0)
    print(a.y)

f[1, 1, 0, 0]()
cuda.synchronize()
```
fails with
```
numba.core.errors.TypingError: Failed in cuda mode pipeline (step: nopython frontend)
Internal error at resolving type of attribute "y" of "a".
<class '__main__.float16x2Type'>
During: typing of get attribute at [redacted] (54)
Enable logging at debug level for details.

File "[redacted]", line 54:
def f():
    <source elided>
    a = float16x2(1.0, 2.0)
    print(a.y)
    ^
```

The reason seems to be that `make_attribute_wrapper` [here](https://github.com/numba/numba/blob/main/numba/core/extending.py#L279C38-L279C53) uses
```
from numba.core.datamodel import default_manager
```
and, as such, assumes the default data model. This means for FP16 it will uses this generic data model [here](https://github.com/numba/numba/blob/7b7137a1f2bf003e8aa42255f571d0947654e7ce/numba/core/datamodel/models.py#L363) instead of the CUDA specific one from [here](https://github.com/numba/numba/blob/7b7137a1f2bf003e8aa42255f571d0947654e7ce/numba/cuda/models.py#L35)

cc @gmarkall 

user: nvlcambier
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_9447: state: open
title: Fix Issue #9432, caching of kernels using target-specific overloads (such as CG sync)
body: Firstly trying to ensure we have a test that actually fails in the context of the test suite. A fix will be added once the efficacy of the test is confirmed.

Commit 86efc6b adds the test, which successfully fails in CI, e.g.: https://gpuci.gpuopenanalytics.com/job/numba/job/numba/job/prb/job/numba-prb/654/CUDA_TOOLKIT_VER=11.2,CUDA_VER=11.2,LINUX_VER=ubuntu18.04,PYTHON_VER=3.8,RAPIDS_VER=21.12/console
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_9446: state: open
title: Type system implementation #1 (Alternative): Added initial implementation for a new type system using redundancies.
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->
This is an alternative to #9408. 

It does the same changes except those are changes are being done in entirely new files to prevent any collision with old numba system.
user: kc611
issue_9445: state: open
title: Fix #9427 np.searchsorted on datetime64
body: Based on https://github.com/numba/numba/pull/9448.
Fixes #9427.

- Adds datetime64 tests for searchsorted
- Re-enables datetime64 support for searchsorted
- Fixes NAT mishandling
user: sklam
issue_9443: state: open
title: `AttributeError` for inlined generic functions with py312 pep-695 type-parameter syntax
body: This regex doesn't match functions that use the [PEP 695](https://peps.python.org/pep-0695/) type parameters syntax:
https://github.com/numba/numba/blob/0.60.0dev0/numba/core/ir.py#L29

In my case, this resulted in:

```
.venv/lib/python3.12/site-packages/numba/core/ir.py:85: in _raw_function_name
    return self._defmatcher.match(defn.strip()).groups()[0]
E   AttributeError: 'NoneType' object has no attribute 'groups'
        defn       = 'def drink_cigar[N: int](X: MatrixF8[_1, N], b: VectorF8[_2]) -> VectorF8[N]:\n'
        self       = Loc(filename=/projects/clowns_are_trains/inflate_bouncy_castle.py, line=192, col=None)
```

This `drink_cigar()` function is wearing a `@njit(inline='always')`.
To give a bit more context, `drink_cigar` is passed as argument to some other (non-inlined) `@njit()` function, `paint_donkeys(drink_cigar, ...)` is this case.
Back when I was still using the archaic `TypeVars`, the code in question was doing what it was supposed to (without errors or warnings).
user: jorenham
labels: 3.12: Python 3.12 related
issue_9440: state: open
title: Overloaded function is compiled more than once with the same signature
body: Now, I think this should be a type template issue. The `OverloadMethodTemplate` doesn't respect the `kwargs` in the related `impl`. So, the dict `get` method also has this issue, if we use them and don't specify `default=a_variable` explicitly. And I also remember some overloaded methods for unicode type also use many `kwargs`.

======== original post =========

Test code:
```python
import os
os.environ["NUMBA_CHROME_TRACE"] = "relower.json"
os.environ["NUMBA_DUMP_OPTIMIZED"] = "1"

from numba import njit
from numba.core import types
from numba.typed import Dict


@njit
def foo():
    d = Dict.empty(key_type=types.int64, value_type=types.int64)
    d[1] = 1
    del d[1]

foo()
```
Then, I checked the JSON file in chrome, I found 2 overloaded functions are compiled twice with the same type signature.
I think this should be a compilation bug, or perhaps it's a feature or limitation in overload implementation?
From the common sense, the same signature of a jitted/overloaded function should be only compiled once, "no matter any situation" in the same process/run. But this case is against this long-term assumption...

1. `native_lowering [typeddict_empty.<locals>.impl]`
2. `native_lowering [impl_pop.<locals>.impl]`
<img width="1917" alt="image" src="https://github.com/numba/numba/assets/8125675/126741a4-9463-4112-8562-e4be7dbf68ec">

If grep the LLVM IR header, 
```
-------------------------------OPTIMIZED DUMP nrt-------------------------------
-------------------OPTIMIZED DUMP impl_new_dict.<locals>.imp--------------------
------------------OPTIMIZED DUMP typeddict_empty.<locals>.impl------------------
--------------------OPTIMIZED DUMP ol_hasattr.<locals>.impl---------------------
-------------------OPTIMIZED DUMP ol_getattr_2.<locals>.impl--------------------
---------------------------OPTIMIZED DUMP _long_impl----------------------------
-------------------------OPTIMIZED DUMP process_return--------------------------
---------------------OPTIMIZED DUMP int_hash.<locals>.impl----------------------
-------------------OPTIMIZED DUMP ol_defer_hash.<locals>.impl-------------------
-------------------OPTIMIZED DUMP hash_overload.<locals>.impl-------------------
-------------------OPTIMIZED DUMP impl_setitem.<locals>.impl--------------------
---------------------OPTIMIZED DUMP impl_pop.<locals>.impl----------------------
---------------------OPTIMIZED DUMP impl_pop.<locals>.impl----------------------
-------------------OPTIMIZED DUMP impl_delitem.<locals>.impl--------------------
------------------OPTIMIZED DUMP typeddict_empty.<locals>.impl------------------
-------------------------------OPTIMIZED DUMP foo-------------------------------
```

For `impl_pop.<locals>.impl`, the first version (coming from the typer pass of `impl_delitem`) is compiled, but unused. The second version (coming from the lowering pass of `impl_delitem`) is actually recompiled and used by its caller.

When we use `overload` or `overload_method` intensively, our compilation time and consumed memory could be increased maybe 2x than it should be.

the cache_key somehow is wrong for this case:
https://github.com/numba/numba/blob/3edb458c69daeaaffbfc938145c367eda1cf043f/numba/core/typing/templates.py#L707
They have different `args`:
1. (DictType(int64, int64), int64)
2. (DictType(int64, int64), int64, omitted(default=None))

the root cause could come from the impl for `pop`: https://github.com/numba/numba/blob/3edb458c69daeaaffbfc938145c367eda1cf043f/numba/typed/dictobject.py#L814

The second arg types should be correct. Then the issue comes from the transition from typer pass of `impl_delitem` to the compilation of `impl_pop`.

I think this issue at least contains 2 problems:

1. `impl_pop` is compiled twice, and the first compilation result is useless;
2. the JSON trace graph doesn't exactly match with the actual execution, in the `args` and `return_type` fields.

even if I set `should_raise` to a const, `False`, it still compiles twice. This should be a fundamental bug. https://github.com/numba/numba/blob/3edb458c69daeaaffbfc938145c367eda1cf043f/numba/typed/dictobject.py#L811
user: dlee992
issue_9439: state: open
title: Fill out `python -m numba -s` field for `CUDA Libraries Test Output` (even if GPU is absent)
body: ## Feature request

When creating a `numba` environment in a Docker image or other build environment where the CUDA Toolkit libraries are present, but a GPU is absent like so...

```bash
conda create -n numba python=3.11 cuda-version=12.2 cuda-nvcc cuda-nvrtc psutil numba
```

...and running `python -m numba -s`. The information on CUDA Libraries detection is left out:

```
CUDA Libraries Test Output:
None
```

<hr>

However the "CUDA Libraries Test Output:" field...

https://github.com/numba/numba/blob/3edb458c69daeaaffbfc938145c367eda1cf043f/numba/misc/numba_sysinfo.py#L611-L612

...merely calls `numba.cuda.cudadrv.libs` function `test`:

https://github.com/numba/numba/blob/3edb458c69daeaaffbfc938145c367eda1cf043f/numba/misc/numba_sysinfo.py#L16

https://github.com/numba/numba/blob/3edb458c69daeaaffbfc938145c367eda1cf043f/numba/misc/numba_sysinfo.py#L371-L375

Running this alone is ok:

<details>

```bash
python -c "from numba.cuda.cudadrv.libs import test; test()"
```
```
Finding driver from candidates:
	libcuda.so
	libcuda.so.1
	/usr/lib/libcuda.so
	/usr/lib/libcuda.so.1
	/usr/lib64/libcuda.so
	/usr/lib64/libcuda.so.1
Using loader <class 'ctypes.CDLL'>
	Trying to load driver...	ok
		Loaded from libcuda.so
	Mapped libcuda.so paths:
		/usr/local/cuda-11.8/compat/libcuda.so.520.61.05
Finding nvvm from Conda environment (NVIDIA package)
	Located at /opt/conda/envs/numba/nvvm/lib64/libnvvm.so.4.0.0
	Trying to open library...	ok
Finding nvrtc from Conda environment (NVIDIA package)
	Located at /opt/conda/envs/numba/lib/libnvrtc.so.12.3.107
	Trying to open library...	ok
Finding cudart from Conda environment (NVIDIA package)
	Located at /opt/conda/envs/numba/lib/libcudart.so.12.3.101
	Trying to open library...	ok
Finding cudadevrt from Conda environment (NVIDIA package)
	Located at /opt/conda/envs/numba/lib/libcudadevrt.a
	Checking library...	ok
Finding libdevice from Conda environment (NVIDIA package)
	Located at /opt/conda/envs/numba/nvvm/libdevice/libdevice.10.bc
	Checking library...	ok
```

</details>

<hr>

It appears this happens as Numba skips including this info if a GPU is not found

https://github.com/numba/numba/blob/3edb458c69daeaaffbfc938145c367eda1cf043f/numba/misc/numba_sysinfo.py#L336

However it would be nice to include this information just to provide a sanity check that Numba can find the CUDA Toolkit libraries
user: jakirkham
labels: CUDA: CUDA related issue/PR
issue_9438: state: open
title: Add math.nextafter support for nopython mode.
body: Resolves #9424 

Add nopython support for math.nextafter on supported versions of Python (>=3.9).

Is there a preferred style for checking the version of the interpreter?
```python
if hasattr(math, 'nextafter'):
    ...
# or 
if sys.hexversion >= 0x03090000:
   ...
# or something else?
```
user: groutr
labels: 4 - Waiting on author: Waiting for author to respond to review
Effort - short: Short size effort needed
issue_9437: state: open
title: Remove dependencies between Numba's Cpython and NumPy module
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

As titled.

This PR intends to remove dependency of Cpython module on NumPy module and adds independent builtins that are seperate for NumPy and Cpython modules.

user: kc611
labels: 4 - Waiting on author: Waiting for author to respond to review
skip_release_notes: Skip towncrier requirement
issue_9436: state: open
title: Add timing and junit xml output to testsuite
body: Changes testsuite to:
- Add custom logic to write junit xml output using `--junit`.
- Record test runtime and print them with `--show-timing`.
- Record PID and active tests per PID. Report these info at crash.
user: sklam
labels: skip_release_notes: Skip towncrier requirement
issue_9435: state: open
title: `nextafter` (via both `math` and `numpy`) missing for CUDA
body: As title says. Possibly related to #9424? 

Details on my [use-case can be found here](https://numba.discourse.group/t/cuda-device-function-pointers-re-implementing-scipy-integrate-solve-ivp-for-numba-cuda/2342).
user: s-m-e
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_9434: state: open
title: Integrate ZLUDA for AMD CUDA
body: 
**Describe the feature**
@sklam,
https://github.com/vosen/ZLUDA
it can give feature run CUDA program on amd video cards if cuda code is optimized, and speed up work on amd.
user: GermanAizek
issue_9433: state: open
title: np.median raises AssertionError for empty arrays while numpy returns nan
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This is a very similar issue to #8451 but here it affects `numpy.median` and setting the error_model does not change the outcome.

```python
import unittest
import numpy as np
from numba import njit

def median_numpy(arr):
    return np.median(arr)

@njit
def median_numba(arr):
    return np.median(arr)

class TestCase(unittest.TestCase):
    def test_median_numpy(self):
        self.assertTrue(np.isnan(median_numpy(np.array([], dtype=float))))
        self.assertTrue(np.isnan(median_numpy(np.array([]))))

    def test_median_numba(self):
        self.assertTrue(np.isnan(median_numba(np.array([], dtype=float))))
        self.assertTrue(np.isnan(median_numba(np.array([]))))

if __name__ == "__main__":
    unittest.main()
```

While numpy returns `nan`, numba raises an AssertionError:

```
Failure
Traceback (most recent call last):
  File "/Users/leo/code/msi/code/tests/unit/misc/test_numpy_util.py", line 88, in test_median_numba
    self.assertTrue(np.isnan(NumpyUtil.median_numba(np.array([], dtype=float))))
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/leo/.miniconda3/envs/exp-2023-10/lib/python3.11/site-packages/numba/np/arraymath.py", line 1556, in _select_two
    assert high > low  # by construction
AssertionError
```

user: leoschwarz
labels: good first issue: A good issue for a first time contributor
issue_9432: state: open
title: Bug: (regression) cooperative grid sync w/ cache=True - working in 0.58.1, not working in 0.59.0
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

Ability to cache kernels using cooperative grid sync was added in https://github.com/numba/numba/pull/8895.

Unfortunately this seems to be broken again in 0.59.0, though is working in 0.58.1.

Test:
```py
from numba import cuda  # type: ignore


@cuda.jit(cache=True)  # type: ignore
def assign_edges_kernel() -> None:
    """
    Kernel which tests the assign_edges function.
    """
    gg = cuda.cg.this_grid()  # type: ignore
    gg.sync()


if __name__ == "__main__":
    assign_edges_kernel[1, 1]()  # type: ignore
```

Result in 0.58.1:
```
$ poetry add numba==0.58.1

Updating dependencies
Resolving dependencies... (0.4s)

Package operations: 0 installs, 2 updates, 0 removals

  • Downgrading llvmlite (0.42.0 -> 0.41.1)
  • Downgrading numba (0.59.0 -> 0.58.1)

Writing lock file
(python3.11) shauncutts@silk:~/.../mlops/ingolstadt$ poetry run python3.11 test.py
/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py:536: NumbaPerformanceWarning: Grid size 1 will likely result in GPU under-utilization due to low occupancy.
  warn(NumbaPerformanceWarning(msg))
  ```
  
  Result in 0.59.0:
  ```
  $ poetry add numba==0.59.0

Updating dependencies
Resolving dependencies... (0.4s)

Package operations: 0 installs, 2 updates, 0 removals

  • Updating llvmlite (0.41.1 -> 0.42.0)
  • Updating numba (0.58.1 -> 0.59.0)

Writing lock file
(python3.11) shauncutts@silk:~/.../mlops/ingolstadt$ poetry run python3.11 test.py
/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py:536: NumbaPerformanceWarning: Grid size 1 will likely result in GPU under-utilization due to low occupancy.
  warn(NumbaPerformanceWarning(msg))
Traceback (most recent call last):
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/errors.py", line 860, in new_error_context
    yield
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 270, in lower_block
    self.lower_inst(inst)
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 448, in lower_inst
    val = self.lower_assign(ty, inst)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 660, in lower_assign
    return self.lower_expr(ty, value)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 1196, in lower_expr
    res = self.lower_call(resty, expr)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 925, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 1159, in _lower_call_normal
    impl = self.context.get_function(fnty, signature)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/base.py", line 556, in get_function
    return self.get_function(fn, sig, _firstcall=False)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/base.py", line 558, in get_function
    raise NotImplementedError("No definition for lowering %s%s" % (key, sig))
NotImplementedError: No definition for lowering (<class 'numba.cuda.types.GridGroup'>, 'sync')(GridGroup,) -> int32

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shauncutts/src/factfiber.ai/mlops/ingolstadt/test.py", line 14, in <module>
    assign_edges_kernel[1, 1]()  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 539, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 673, in call
    kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 681, in _compile_for_args
    return self.compile(tuple(argtypes))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 924, in compile
    kernel = _Kernel(self.py_func, argtypes, **self.targetoptions)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/dispatcher.py", line 83, in __init__
    cres = compile_cuda(self.py_func, types.void, self.argtypes,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cuda/compiler.py", line 196, in compile_cuda
    cres = compiler.compile_extra(typingctx=typingctx,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py", line 751, in compile_extra
    return pipeline.compile_extra(func)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py", line 445, in compile_extra
    return self._compile_bytecode()
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py", line 513, in _compile_bytecode
    return self._compile_core()
           ^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py", line 492, in _compile_core
    raise e
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py", line 479, in _compile_core
    pm.run(self.state)
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py", line 368, in run
    raise patched_exception
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py", line 356, in run
    self._runPass(idx, pass_inst, state)
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py", line 311, in _runPass
    mutated |= check(pss.run_pass, internal_state)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py", line 273, in check
    mangled = func(compiler_state)
              ^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/typed_passes.py", line 468, in run_pass
    lower.lower()
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 187, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 226, in lower_normal_function
    entry_block_tail = self.lower_function_body()
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 256, in lower_function_body
    self.lower_block(block)
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py", line 268, in lower_block
    with new_error_context('lowering "{inst}" at {loc}', inst=inst,
  File "/usr/local/share/mambaforge/envs/python3.11/lib/python3.11/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/errors.py", line 874, in new_error_context
    raise newerr.with_traceback(tb)
numba.core.errors.LoweringError: Failed in cuda mode pipeline (step: native lowering)
No definition for lowering (<class 'numba.cuda.types.GridGroup'>, 'sync')(GridGroup,) -> int32

File "test.py", line 10:
def assign_edges_kernel() -> None:
    <source elided>
    gg = cuda.cg.this_grid()  # type: ignore
    gg.sync()
    ^

During: lowering "$92call.8 = call $66load_method.7(func=$66load_method.7, args=[], kws=(), vararg=None, varkwarg=None, target=None)" at /home/shauncutts/src/factfiber.ai/mlops/ingolstadt/test.py (10)
```

user: shaunc
labels: CUDA: CUDA related issue/PR
bug - regression: A regression against a previous version of Numba
issue_9431: state: open
title: explicit specialization does not respect caching
body: ## Reporting a bug

A call to `specialize()` on the CUDA dispatcher does not propagate the fact that the cache is enabled in the dispatcher.

It seems this happens in the CUDADispatcher [here](https://github.com/numba/numba/blob/main/numba/cuda/dispatcher.py#L713-L715):
```py
        specialization = CUDADispatcher(self.py_func,
                                        targetoptions=targetoptions)
        specialization.compile(argtypes)
```
The specialization does not have the cache enabled, even if the parent dispatcher does.

Importing `NullCache` above, and changing these lines to:
```py
        specialization = CUDADispatcher(self.py_func,
                                        targetoptions=targetoptions)

        if not isinstance(self._cache, NullCache):
            specialization.enable_caching()
        specialization.compile(argtypes)
```
resolves the problem. (I could submit a PR - not familiar with how it should be tested though.)

### Background

I am using kernels with cooperative groups, and want to call `max_cooperative_grid_blocks()` before I call the kernel. However, this is only possible if the kernel is already specialized. Accordingly, I have a wrapper around my kernels which calls `specialize()` first, gets the overload from the list and queries it, sets the # of blocks, and calls the kernel. This results in the cache never being used for the first call even if it exists. (If there is a more canonical way to do this, I would be pleased to know.)

## Reproducer

Perhaps this suffices:

```py
from typing import cast

from numba import cuda  # type: ignore[import]
from numba.cuda.dispatcher import CUDADispatcher  # type: ignore[import]


@cuda.jit(cache=True)
def kernel(a: int | float) -> None:
    print("hello")


kernel_dispatcher = cast(CUDADispatcher, kernel)

# prints: <class 'numba.cuda.dispatcher.CUDACache'>
print(type(kernel_dispatcher._cache))

float_dispatcher = kernel_dispatcher.specialize(0.5)
# prints <class 'numba.core.caching.NullCache'>
print(type(float_dispatcher._cache))
```



user: shaunc
labels: CUDA: CUDA related issue/PR
caching: Issue involving caching
issue_9430: state: open
title: Type system implementation #2: Added builtins support for the new type system.
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->
As titled, this PR adds support for builtins in the new type system. 

Depends on: #9408
user: kc611
labels: NumPy 2.0: Related to NumPy 2.0 support
issue_9429: state: open
title: GPU target doesn't emit compile events
body: ## Reporting a bug

Thanks to @sschaer via https://numba.discourse.group/t/hooks-for-compilation-start-end/2108/4?u=shaunc I have a timer that captures compile times for the CPU target. Unfortunately it doesn't work for the GPU target. The following code is working, but no event is emitted for `test_kernel` though one is emitted for `test_cpu`.

```py
from dataclasses import dataclass
from time import perf_counter

import numba as nb  # type: ignore
from numba import cuda  # type: ignore
from numba.core import event
from numba.cuda.dispatcher import CUDADispatcher  # type: ignore


@dataclass
class Timing:
    """
    Timing compile listener.

    Thanks to https://numba.discourse.group/u/sschaer:
    https://numba.discourse.group/t/hooks-for-compilation-start-end/2108/4?u=shaunc
    """

    tic: float | None = None
    toc: float | None = None

    @property
    def elapsed(self) -> float | None:
        if None not in (self.tic, self.toc):
            return self.toc - self.tic


class MyCompileTimeListener(event.Listener):
    def __init__(self) -> None:
        self.timings: dict[CUDADispatcher, Timing] = {}

    def on_start(self, event: event.Event) -> None:
        print("    start", event.data["dispatcher"])
        self.timings[event.data["dispatcher"]] = Timing(perf_counter())

    def on_end(self, event: event.Event) -> None:
        self.timings[event.data["dispatcher"]].toc = perf_counter()

    def get_elapsed(self, disp: CUDADispatcher) -> float:
        return self.timings[disp].elapsed


my_listener = MyCompileTimeListener()
event.register(kind="numba:compile", listener=my_listener)


@cuda.jit
def test_kernel():
    if cuda.grid(1) == 0:
        print("Hello, World!")


@nb.njit
def test_cpu():
    print("Hello, World!")


def main():
    test_kernel[1, 1]()
    test_cpu()
    print(f"Elapsed [s]: {my_listener.get_elapsed(test_cpu):5f}")


if __name__ == "__main__":
    main()
```

Using numba 0.59.0
ubuntu 20.04
python 3.11



NB -- my real concern is to track down, and hopefully mitigate extremely long compile times for GPU target.

https://numba.discourse.group/t/hooks-for-compilation-start-end/2108/2

user: shaunc
labels: CUDA: CUDA related issue/PR
issue_9428: state: open
title: Optimize `range()` to enable more auto-vectorization
body: It is known that Numba's `range()` implementation is not optimal for LLVM loop optimizers. Even when one manually unroll loop for a constant loop bound, the way `range()` is implemented prohibits the loop-vectorizer to compute the loop bounds; thus failing to auto-vectorize in many cases. 

This patch focuses on adjusting the ind-var computation to avoid computing reminders and instead relies mainly on additions, multiplications and floordiv which are common in low-level address computations.

There is still a reminder computation only if user ask for `length_of_iterator(iter(range()))`, but it is a rare use-case. LLVM is able to optimize-away that reminder (and the storage of `range_iterator_type.count`)

Here's a notebook with a use-case I used to optimize `range()`: https://gist.github.com/sklam/6beddb2041580ceea4f25e0e496f50a0/420bc173da75996a307465f134c23bb3f4bb6562.

user: sklam
issue_9427: state: open
title: `searchsorted` with dtype `datetime64` stopped working in `njit` mode going from 0.58.1 to 0.59
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Using `numpy.searchsorted()` with dtype `datetime64` does not work in `njit` mode in version 0.59. This works fine in version 0.58.1.

I guess this is related to the recent changes to the function. #9189 

Reproducible sample:
```
import numpy as np
from numba import njit

@njit
def foo(a, v):
    return np.searchsorted(a, v)

arr = np.asarray(
    ['2022-03-09 06:45:00', '2022-03-09 06:50:00', '2022-03-09 06:55:00'],
    dtype=np.dtype('datetime64[ns]')
)
print(foo(arr, arr[-1]))
```

Output:
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Cell In[37], line 12
      6     return np.searchsorted(a, v)
      8 arr = np.asarray(
      9     ['2022-03-09 06:45:00', '2022-03-09 06:50:00', '2022-03-09 06:55:00'],
     10     dtype=np.dtype('datetime64[ns]')
     11 )
---> 12 print(foo(arr, arr[-1]))

File ~/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 468     error_rewrite(e, 'typing')
    469 except errors.UnsupportedError as e:
    470     # Something unsupported is present in the user code, add help info
    471     error_rewrite(e, 'unsupported_error')

File ~/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function searchsorted at 0xffff645c9ee0>) found for signature:
 
 >>> searchsorted(array(datetime64[ns], 1d, C), datetime64[ns])
 
There are 2 candidate implementations:
      - Of which 1 did not match due to:
      Overload in function 'searchsorted': File: numba/np/arraymath.py: Line 3805.
        With argument(s): '(array(datetime64[ns], 1d, C), datetime64[ns])':
       Rejected as the implementation raised a specific error:
         TypingError: Failed in nopython mode pipeline (step: nopython frontend)
       No implementation of function Function(<function _searchsorted.<locals>.impl at 0xfffd3a10df80>) found for signature:
        
        >>> impl(array(datetime64[ns], 1d, C), array(datetime64[ns], 1d, C))
        
       There are 2 candidate implementations:
         - Of which 2 did not match due to:
         Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba/core/extending.py: Line 161.
           With argument(s): '(array(datetime64[ns], 1d, C), array(datetime64[ns], 1d, C))':
          Rejected as the implementation raised a specific error:
            TypingError: Failed in nopython mode pipeline (step: nopython frontend)
          No implementation of function Function(<function _less_than at 0xfffd3e842d40>) found for signature:
           
           >>> _less_than(datetime64[ns], datetime64[ns])
           
          There are 2 candidate implementations:
                - Of which 2 did not match due to:
                Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba/core/extending.py: Line 161.
                  With argument(s): '(datetime64[ns], datetime64[ns])':
                 Rejected as the implementation raised a specific error:
                   TypingError: Failed in nopython mode pipeline (step: nopython frontend)
                 No implementation of function Function(<built-in function isinstance>) found for signature:
                  
                  >>> isinstance(datetime64[ns], Function(<class 'complex'>))
                  
                 There are 2 candidate implementations:
                       - Of which 2 did not match due to:
                       Overload in function 'ol_isinstance': File: numba/cpython/builtins.py: Line 748.
                         With argument(s): '(datetime64[ns], Function(<class 'complex'>))':
                        Rejected as the implementation raised a specific error:
                          NumbaTypeError: isinstance() does not support variables of type "datetime64[ns]".
                   raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/cpython/builtins.py:778
                 
                 During: resolving callee type: Function(<built-in function isinstance>)
                 During: typing of call at /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py (3729)
                 
                 
                 File "../../../.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py", line 3729:
                 def _less_than(a, b):
                     if isinstance(a, complex) or isinstance(b, complex):
                     ^
          
            raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/typeinfer.py:1091
          
          During: resolving callee type: Function(<function _less_than at 0xfffd3e842d40>)
          During: typing of call at /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py (3753)
          
          
          File "../../../.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py", line 3753:
              def impl(a, v):
                  <source elided>
          
                      if func_1(last_key_val, key_val):
                      ^
       
         raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/typeinfer.py:1091
       
       During: resolving callee type: Function(<function _searchsorted.<locals>.impl at 0xfffd3a10df80>)
       During: typing of call at /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py (3830)
       
       
       File "../../../.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py", line 3830:
               def impl(a, v, side='left'):
                   return _impl(a, np.array([v]))[0]
                   ^

  raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/typeinfer.py:1091
      - Of which 1 did not match due to:
      Overload in function 'searchsorted': File: numba/np/arraymath.py: Line 3805.
        With argument(s): '(array(datetime64[ns], 1d, C), datetime64[ns])':
       Rejected as the implementation raised a specific error:
         TypingError: Failed in nopython mode pipeline (step: nopython frontend)
       No implementation of function Function(<function _searchsorted.<locals>.impl at 0xfffd3c92e520>) found for signature:
        
        >>> impl(array(datetime64[ns], 1d, C), array(datetime64[ns], 1d, C))
        
       There are 2 candidate implementations:
         - Of which 2 did not match due to:
         Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba/core/extending.py: Line 161.
           With argument(s): '(array(datetime64[ns], 1d, C), array(datetime64[ns], 1d, C))':
          Rejected as the implementation raised a specific error:
            TypingError: Failed in nopython mode pipeline (step: nopython frontend)
          No implementation of function Function(<function _less_than at 0xfffd3e842d40>) found for signature:
           
           >>> _less_than(datetime64[ns], datetime64[ns])
           
          There are 2 candidate implementations:
                - Of which 2 did not match due to:
                Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba/core/extending.py: Line 161.
                  With argument(s): '(datetime64[ns], datetime64[ns])':
                 Rejected as the implementation raised a specific error:
                   TypingError: Failed in nopython mode pipeline (step: nopython frontend)
                 No implementation of function Function(<built-in function isinstance>) found for signature:
                  
                  >>> isinstance(datetime64[ns], Function(<class 'complex'>))
                  
                 There are 2 candidate implementations:
                       - Of which 2 did not match due to:
                       Overload in function 'ol_isinstance': File: numba/cpython/builtins.py: Line 748.
                         With argument(s): '(datetime64[ns], Function(<class 'complex'>))':
                        Rejected as the implementation raised a specific error:
                          NumbaTypeError: isinstance() does not support variables of type "datetime64[ns]".
                   raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/cpython/builtins.py:778
                 
                 During: resolving callee type: Function(<built-in function isinstance>)
                 During: typing of call at /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py (3729)
                 
                 
                 File "../../../.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py", line 3729:
                 def _less_than(a, b):
                     if isinstance(a, complex) or isinstance(b, complex):
                     ^
          
            raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/typeinfer.py:1091
          
          During: resolving callee type: Function(<function _less_than at 0xfffd3e842d40>)
          During: typing of call at /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py (3753)
          
          
          File "../../../.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py", line 3753:
              def impl(a, v):
                  <source elided>
          
                      if func_1(last_key_val, key_val):
                      ^
       
         raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/typeinfer.py:1091
       
       During: resolving callee type: Function(<function _searchsorted.<locals>.impl at 0xfffd3c92e520>)
       During: typing of call at /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py (3830)
       
       
       File "../../../.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py", line 3830:
               def impl(a, v, side='left'):
                   return _impl(a, np.array([v]))[0]
                   ^

  raised from /home/ec2-user/.cache/pypoetry/virtualenvs/indefatigable-XRADjY79-py3.11/lib/python3.11/site-packages/numba/core/typeinfer.py:1091

During: resolving callee type: Function(<function searchsorted at 0xffff645c9ee0>)
During: typing of call at /tmp/ipykernel_12047/1166298884.py (6)


File "../../../../../tmp/ipykernel_12047/1166298884.py", line 6:
<source missing, REPL/exec in use?>
```
user: zansibal
labels: bug - regression: A regression against a previous version of Numba
issue_9426: state: open
title: Update changelog script to account for missing author info on github.
body: Remaining task from https://github.com/numba/numba/issues/9372

Fix the changelog script to account for missing author info on github. probably should use git info to fill in the blanks.
user: sklam
issue_9424: state: open
title: Support math.nextafter in nopython mode
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
`math.nextafter` was added in Python 3.9. However, numba doesn't seem to support it in nopython mode. Can support please be added?
user: groutr
labels: good first issue: A good issue for a first time contributor
issue_9423: state: open
title: guvectorize does not check contiguity, breaks indexing
body: numba 0.59.0

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I just started working with numba and I'm in awe of the ease of use and the enormous performance improvement! But this one issue had me stumped for quite some time, as it occurred deep inside my code.

```
import numba
import numpy as np

@numba.guvectorize(['void(int64[::1])'], '(n)')
def foo(arr):
    print('Array:', arr)
    print('Iterated:')
    for i in range(len(arr)):
        print(i, arr[i])

# This one works fine:
# foo(np.array([1, 2, 3], dtype=np.int64))

foo(np.broadcast_to(np.array([4]), (3,)))
```

This prints:

```
Array: [4 4 4]
Iterated:
4
0
32
```

I would expect an exception to be raised, because there is no matching signature. The passed array is not contiguous, because it has a stride of 0.

Instead, only the first element is printed correctly; the other two are garbage. I suspect this happens because the array is assumed to be contiguous, so the stride is ignored.
user: ttencate
labels: good second issue: A good issue for second time contributors
bug - incorrect behavior: Bugs: incorrect behavior
issue_9422: state: open
title: Implement ndarray.byteswap
body: It's implemented for numbers (including complex) and boolean.

On a 1D array it's about 7x faster than numpy. For higher dimensions it is slower, and it is much slower for Fortran-order arrays, for the same reasons as in #9400.

This is almost my first PR for numba and I'm pretty new to LLVM as well, so I've got a few questions:

- I've kept the code smaller by unconditionally bit-casting to and from a suitably-sized integer type. If it's already an integer type (probably the common case) that's unnecessary LLVM IR instructions, but I'm assuming that's harmless.
- In numpy, `byteswap` on a scalar with `inplace=True` raises an exception, and I've mirrored that behaviour. Since numba is statically typed, an alternative is to simply not support that useless parameter, which would move the error to compile time (generally a good thing) but be less compatible with numpy. Any thoughts?
- Is there a better way to handle the array iteration? I looked into wrapping the `@intrinsic` scalar function into a ufunc and calling that (which uses a sensible iteration order for Fortran-order arrays), but ran into some cyclic import problems.
user: bmerry
issue_9421: state: open
title: Support for Definition of Numpy Arrays of Complex Type Within njit-ed Functions?
body: I use `numba` a lot in order to speed up my codes, which are designed to evolve PDEs over time. I have a function of a similar structure to the following:
```py
def update(Omega0, dt):
    # the following is not numerically stable, but the full code is much longer and this is representative
    U0 = Omega0 * np.array([kU0, kU1], dtype = 'complex')
    omega0 = ifft2(Omega0)
    u0 = real(np.array([ifft2(U0[0]), ifft2(U0[1])]))
    dXiOdt0 = -1j * (kp * fft2(u0[0] * omega0) + kq * fft2(u0[1] * omega0))
    Omega3 = Xi(-dt) * (Omega0 + dt*dXiOdt0)
    U3 = Omega3 * np.array([kU0, kU1], dtype = 'complex')
    u3 = real(np.array([ifft2(U3[0]), ifft2(U3[1])]))
    dt_next = cfl_max / (np.amax(u3[0])/dx + np.amax(u3[1])/dy)

    return Omega3, dt_next
```
Unfortunately, when I attempt to use `@numba.njit()` above it, I get the following *long* traceback:
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function array>) found for signature:
 
 >>> array(list(readonly array(complex128, 2d, A))<iv=None>, dtype=Literal[str](complex))
 
There are 2 candidate implementations:
   - Of which 1 did not match due to:
   Overload in function 'impl_np_array': File: numba/np/arrayobj.py: Line 5421.
     With argument(s): '(list(readonly array(complex128, 2d, A))<iv=None>, dtype=unicode_type)':
    Rejected as the implementation raised a specific error:
      TypingError: If np.array dtype is a string it must be a string constant.
  raised from /opt/homebrew/lib/python3.10/site-packages/numba/np/arrayobj.py:4348
   - Of which 1 did not match due to:
   Overload in function 'impl_np_array': File: numba/np/arrayobj.py: Line 5421.
     With argument(s): '(list(readonly array(complex128, 2d, A))<iv=None>, dtype=Literal[str](complex))':
    Rejected as the implementation raised a specific error:
      TypingError: Failed in nopython mode pipeline (step: nopython frontend)
    No implementation of function Function(<intrinsic np_array>) found for signature:
     
     >>> np_array(list(readonly array(complex128, 2d, A))<iv=None>, Literal[str](complex))
     
    There are 2 candidate implementations:
          - Of which 1 did not match due to:
          Intrinsic in function 'np_array': File: numba/np/arrayobj.py: Line 5395.
            With argument(s): '(list(readonly array(complex128, 2d, A))<iv=None>, unicode_type)':
           Rejected as the implementation raised a specific error:
             TypingError: If np.array dtype is a string it must be a string constant.
      raised from /opt/homebrew/lib/python3.10/site-packages/numba/np/arrayobj.py:4348
          - Of which 1 did not match due to:
          Intrinsic in function 'np_array': File: numba/np/arrayobj.py: Line 5395.
            With argument(s): '(list(readonly array(complex128, 2d, A))<iv=None>, Literal[str](complex))':
           Rejected as the implementation raised a specific error:
             TypingError: readonly array(complex128, 2d, A) not allowed in a homogeneous sequence
      raised from /opt/homebrew/lib/python3.10/site-packages/numba/core/typing/npydecl.py:482
    
    During: resolving callee type: Function(<intrinsic np_array>)
    During: typing of call at /opt/homebrew/lib/python3.10/site-packages/numba/np/arrayobj.py (5432)
    
    
    File "../../../../../../opt/homebrew/lib/python3.10/site-packages/numba/np/arrayobj.py", line 5432:
        def impl(object, dtype=None):
            return np_array(object, dtype)
            ^

  raised from /opt/homebrew/lib/python3.10/site-packages/numba/core/typeinfer.py:1091

During: resolving callee type: Function(<built-in function array>)
During: typing of call at /[filepath]/[filename].py (119)


File "[filename].py", line 119:
def update(Omega0, dt):
    <source elided>
    # RK1 Test (is not numerically stable, but much shorter than RK3)
    U0 = Omega0 * np.array([kU0, kU1], dtype = 'complex')
```
It seems that this error is specific to complex arrays, because I can define `np.empty()` arrays of real type without any issue within `@numba.njit()`. While it would be possible to separate out these variables into `U00 = kU0*Omega0`, `U01 = kU1*Omega0`, is there a better solution I'm not aware of, or is this a missing feature within `numba`?

Thank you in advance.
user: jacobjivanov
labels: question: Notes an issue as a question
issue_9420: state: open
title: Tuple of functions (with identical signature) does not compile for CUDA
body: - [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

The following example results in `NumbaNotImplementedError`:

```python
import numpy as np
import numba as nb
from numba import cuda

@cuda.jit("f8(f8)", device = True, inline = True)
def foo(x):
    return x * 10

@cuda.jit("f8(f8)", device = True, inline = True)
def bar(x):
    return x * 100

FUNCS = (
    foo,
    bar,
)

@nb.vectorize("f8(f8,i8)", target = "cuda")
def demo(x, idx):
    return FUNCS[idx](x)

X = np.arange(0., 10.)
mask = np.array([0, 1, 0, 1, 0, 1, 0, 1, 0, 1], dtype="i8")

print(demo(X, mask))
```

A similar thing does work on the CPU, with a warning though:

```python
import numpy as np
import numba as nb

@nb.njit("f8(f8)", inline = "always")
def foo(x):
    return x * 10

@nb.njit("f8(f8)", inline = "always")
def bar(x):
    return x * 100

FUNCS = (
    foo,
    bar,
)

@nb.vectorize("f8(f8,i8)", target = "cpu")
def demo(x, idx):
    return FUNCS[idx](x)

X = np.arange(0., 10.)
mask = np.array([0, 1, 0, 1, 0, 1, 0, 1, 0, 1], dtype="i8")

print(demo(X, mask))
```

I am trying to get around the limitation of being unable to pass custom user-provided functions to a CUDA-kernel. The tuple `FUNCS` is being generated dynamically (from a list or array), then a custom version of `demo` is supposed to be compiled. All functions in `FUNCS` have the exact same signature. For further context / use-case, see [here](https://numba.discourse.group/t/cuda-device-function-pointers-re-implementing-scipy-integrate-solve-ivp-for-numba-cuda/2342/2).
user: s-m-e
issue_9418: state: open
title: Structured array scalar slices: `iadd`, `isub`, etc, not able to compile (simple example code)
body: Here are 3 tiny code examples, first is plain numpy, which works as expected. 2nd two are the same thing with `numba.njit` using getattr, and using getitem. They fail very differently, because the `+=` operator expands differently, using setitem in the case of array-index notation, and simple assignment with getattr case.

I would think both cases should be fixable, though maybe with different changes, since the second one needs an iadd overload to stop python from falling back to plain assignment.

```py
import numpy as np
from numba import njit 

x = np.ones(2, dtype=[("y", np.float32)])

def foo(x):
    x['y'] += x['y']
    return x
    
print(foo(x)) # -> [(2.,) (2.,)]

@njit
def foo2(x):
    x['y'] += x['y']
    return x

print(foo2(x))
"""
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function setitem>) found for signature:
 
 >>> setitem(unaligned array(Record(y[type=float32;offset=0];4;False), 1d, C), Literal[str](y), unaligned array(float32, 1d, A))
"""

@njit
def foo3(x):
    x.y += x.y
    return x

print(foo3(x))
"""
LoweringError: Failed in nopython mode pipeline (step: native lowering)
No definition for lowering unaligned array(Record(y[type=float32;offset=0];4;False), 1d, C).y = unaligned array(float32, 1d, A)

File "../../../../../var/folders/56/htsjnjgx33187yly3hgzcwqc0000gn/T/ipykernel_7694/3094805070.py", line 42:
<source missing, REPL/exec in use?>

During: lowering "(x).y = $binop_iadd30.4" at /var/folders/56/htsjnjgx33187yly3hgzcwqc0000gn/T/ipykernel_7694/3094805070.py (42)
"""
```
user: wrongbad
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9417: state: open
title: Add np.log* bindings for CUDA
body: Add `np.log2`, `np.log` and `np.log10` to CUDA. I am just not so sure if complex support was done right, as I do not know if libdevice has support for complex functions.

Fixes: https://github.com/numba/numba/issues/9414
user: guilhermeleobas
labels: CUDA: CUDA related issue/PR
4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - short: Short size effort needed
issue_9416: state: open
title: Add math.log2 support
body: Partially fixes https://github.com/numba/numba/issues/9414
user: guilhermeleobas
labels: 4 - Waiting on author: Waiting for author to respond to review
Effort - short: Short size effort needed
issue_9414: state: open
title: Inconsistent support of log2
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

The cpu platform supports `np.log2` but not `math.log2`. The gpu platform supports `math.log2` but not `np.log2`. This makes it impossible to maintain library routines using log2 that are called on both platforms.

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
```py
import math
import sys

import numba as nb  # type: ignore
import numpy as np
from numba import cuda  # type: ignore
from numpy import typing as npt  # type: ignore


@cuda.jit
def log2_math_kernel(x: npt.NDArray[np.float64]) -> None:
    if cuda.grid(1) == 0:
        x[0] = math.log2(x[0])


@cuda.jit
def log2_np_kernel(x: npt.NDArray[np.float64]) -> None:
    if cuda.grid(1) == 0:
        x[0] = np.log2(x[0])


@nb.njit
def log2_math_cpu(x: float) -> float:
    return math.log2(x)


@nb.njit
def log2_np_cpu(x: float) -> float:
    return np.log2(x)


x = np.ones(1, dtype=np.float64)
if __name__ == "__main__":
    if sys.argv[1] == "gm":
        log2_math_kernel[1, 1](x)
    elif sys.argv[1] == "gn":
        log2_np_kernel[1, 1](x)
    elif sys.argv[1] == "cm":
        log2_math_cpu(x[0])
    elif sys.argv[1] == "cn":
        log2_np_cpu(x[0])
```
When running, options "gm" and "cn" run, "gn" and "cm" do not compile.
I am using 0.58.1 on python3.11.3, ubuntu focal.

user: shaunc
labels: good first issue: A good issue for a first time contributor
issue_9413: state: open
title: Python 3.13
body: This issue is to track tasks and issues with Python 3.13.

Numba support status:

- Started early work on Python3.13.0a3. So far, there is minimal bytecode changes (WIP branch: https://github.com/numba/numba/compare/main...sklam:numba:wip/py3.13). We got `numba/tests/test_usecases.py` to pass. However, more involved tests are blocked by an issue with metaclass (https://github.com/python/cpython/issues/114806). As a result, `Type._code` is not set properly.  (temporary debug commit related to the issue: https://github.com/numba/numba/commit/4b6cc78a79530e41e414326fbb7f255d05ee5506)
- Added development setup using hatchery: https://github.com/numba/numba-hatchery/pull/8
- Work is halted until 3.13.0a4 is available. Expected on Feb 13 2024.
user: sklam
issue_9412: state: open
title: debuginfo issues with parallel functions: file names are not identified
body: Consider the following file, `myexample.py`:

```python
import numpy as np
from numba import njit, prange, gdb
from time import time

DATA = np.random.random((1_000_000,))


@njit(parallel=True)
def parallel_sum(timeseries):
    total = 0
    for i in prange(len(timeseries)):
        value = ((7 * timeseries[i]) + 1) / 9
        for j in range(100):
            value = np.sin(value)
            value = np.cos(value)
            value = ((7 * value) + 1) / 9
        total += value
    return total


# Make sure the Numba code is pre-compiled
parallel_sum(DATA)

# This is the part we want to profile:
import os

print(os.getpid())
while True:
    parallel_sum(DATA)
```

If I run:

```shell-session
$ NUMBA_ENABLE_PROFILING=1 python  myexample.py 
/home/itamarst/devel/profila/venv/lib/python3.10/site-packages/numba/core/lowering.py:112: NumbaDebugInfoWarning: Could not find source for function: <function __numba_parfor_gufunc_0x7f6cdacfa500 at 0x7f6cdab03d00>. Debug line information may be inaccurate.
  warnings.warn(NumbaDebugInfoWarning(msg))
987245
```

## The problem: wrong file names

That warning is accurate! If I attach gdb I do get back traces that are somewhat meaningful, but it doesn't identify the filename, instead of `myexample.py:14` it says `<string>:14`, e.g.:

```
(gdb) thread 20
[Switching to thread 20 (Thread 0x7f6cd5d50640 (LWP 987264))]
#0  do_sin (dx=0, x=<optimized out>) at ../sysdeps/ieee754/dbl-64/s_sin.c:144
144     in ../sysdeps/ieee754/dbl-64/s_sin.c
(gdb) bt
#0  do_sin (dx=0, x=<optimized out>) at ../sysdeps/ieee754/dbl-64/s_sin.c:144
#1  __sin_fma (x=0.72430158876385675) at ../sysdeps/ieee754/dbl-64/s_sin.c:221
#2  0x00007f6d0083d0fa in _3cdynamic_3e::__numba_parfor_gufunc_0x7f6cdacfa500[abi:v5][abi:c8tJTC_2fWQAlzW1yBDkop6GEOEUMEOYSPGuIQMViAQ3iQ8IbKQIMbwoOGNoQDDWwQR1NHAZtvoQrh6RHKR8skqKIYWQImjYg1W7ADge6ExAzM1UUQpZoA](Array<unsigned long long, 1, C, mutable, aligned>, Array<double, 1, C, mutable, aligned>, Array<double, 1, C, mutable, aligned>) (sched=..., timeseries=..., 
    total_2__arr=...) at <string>:14
#3  0x00007f6ce3b21186 in __gufunc__._ZN13_3cdynamic_3e36__numba_parfor_gufunc_0x7f6cdacfa500B2v5B118c8tJTC_2fWQAlzW1yBDkop6GEOEUMEOYSPGuIQMViAQ3iQ8IbKQIMbwoOGNoQDDWwQR1NHAZtvoQrh6RHKR8skqKIYWQImjYg1W7ADge6ExAzM1UUQpZoAE5ArrayIyLi1E1C7mutable7alignedE5ArrayIdLi1E1C7mutable7alignedE5ArrayIdLi1E1C7mutable7alignedE ()
#4  0x00007f6ce3b29264 in _ZL12parallel_forPvPPcPmS2_S_mmi._omp_fn.0(void) ()
    at numba/np/ufunc/omppool.cpp:205
#5  0x00007f6ce3ad7c0e in ?? () from /lib/x86_64-linux-gnu/libgomp.so.1.0.0
#6  0x00007f6d04094ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#7  0x00007f6d04126850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
```
## Versions

I'm on Ubuntu 22.04, Python 3.10. I get the same behavior with 0.58.1 and 0.59.0rc1.
user: itamarst
labels: bug - DWARF: Bugs related to debugging support
issue_9409: state: open
title: New Type System/NumPy 2 support tracking
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

This issue page tracks the progress of NumPy 2 development and consequently the development of a new type system alongside it for making it possible. Following are a list of tasks to be accomplished:

- [ ] Adding a new type system implementation capable of distinguishing between NumPu and Python scalars to be able to apply casting rules defined by NumPy 2.
  - [ ] Adding new types for scalars and isolating old types from the implementations. (https://github.com/numba/numba/pull/9408)
  - [ ] Isolating and aliasing the type initialiations across Numba.
  - [ ] Adding templates for new type system
- [ ] Abstracting out the typecasting rules to be able to manage multiple sets of independent type casting rules. (Determined by config flags)
    - [ ] Adding NumPy 2 casting rules as one of the possible set of casting rules.  

user: kc611
labels: NumPy 2.0: Related to NumPy 2.0 support
issue_9408: state: open
title: Type system implementation #1: Added initial implementation for a new type system. 
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->
As titled, this is the first PR for adding a new type system that will allow numba to differentiate between Python and NumPy scalars. This PR adds the following capabilities:

- Retains Numba's old type system as default
- Adds a config flag `USE_LEGACY_TYPE_SYSTEM` set to `1`/ on by default. Switching it to `0`/off will activate new type system.
- Within the new type system, the python and numpy scalars will be treated and returned seperately from JIT compiled functions. Basic binary operations such as add/subtract can also be done with the newly added types.
user: kc611
labels: 4 - Waiting on author: Waiting for author to respond to review
4 - Waiting on reviewer: Waiting for reviewer to respond to author
NumPy 2.0: Related to NumPy 2.0 support
issue_9401: state: open
title: Add type annotations for @intrinsic
body: Previously using the `intrinsic` decorator would cause typing issues when invoking the decorated function, e.g.:
```python
@intrinsic()
def myIntrinsic(typing_context, a, b):
   ...
   
myIntrinsic(a, b) # type checker complains that there's a missing parameter
```

This can be solved by annotating `intrinsic` with types that indicate that the decorated function does not take the typing context parameter.
<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: aneeshdurg
issue_9400: state: open
title: Some array methods much slower with non-C-order arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

While #7622 improved performance of ufuncs on non-C-order arrays, there are some array functions that operate per-element but are not ufuncs, and these could be improved to iterate according to the memory order. Two examples I came across while poking around the numba code are `np.clip` and `ndarray.astype`. Here are some timings from numba 0.59rc1 (code appears below):

```
clip, 1M                  np:        278 µs	numba:         97 µs
clip, 1K×1K, C            np:        271 µs	numba:        601 µs
clip, 1K×1K, F            np:        277 µs	numba:       1180 µs
clip, 500×500, A          np:         96 µs	numba:        253 µs
astype, 1M                np:        193 µs	numba:        176 µs
astype, 1K×1K, C          np:        205 µs	numba:        180 µs
astype, 1K×1K, F          np:        195 µs	numba:       1642 µs
astype, 500×500, A        np:         44 µs	numba:        123 µs
```
The "500×500, A" cases use a 500×500 slice from a 1000×1000 C-contiguous array: that means they're not C-contiguous, but they are row-major (with padding) and so C-order iteration should still be cache-friendly and it is not obvious why these cases perform significantly worse than the plain numpy version.

These also seem to exhibit different behaviour to each other: `clip` performance is much worse on a C-contiguous 2D (1K×1K) view compared to the original 1D (1M-element) array, while for `astype` these cases perform similarly.

```python
#!/usr/bin/env python3

import time

import numpy as np
from numba import njit

@njit
def clip(a):
    return np.clip(a, 0, 5)


@njit
def astype(a):
    return a.astype(np.uint64)


def timeit(passes, func, *args, **kwargs):
    func(*args, **kwargs)  # Warmup, compile JIT code
    start = time.perf_counter_ns()
    for i in range(passes):
        func(*args, **kwargs)
    stop = time.perf_counter_ns()
    elapsed = (stop - start) / passes
    return elapsed


def timeit_both(name, passes, func, *args, **kwargs):
    numba_time = timeit(passes, func, *args, **kwargs)
    np_time = timeit(passes, func.py_func, *args, **kwargs)
    print(f"{name:<25} np: {np_time / 1000.0:10.0f} µs\tnumba: {numba_time / 1000.0:10.0f} µs")


a = np.ones(1000000, np.uint32)
b = a.reshape(1000, 1000)
bT = b.T
c = a.reshape(1000, 1000)[:500, :500]

timeit_both("clip, 1M", 1000, clip, a)
timeit_both("clip, 1K×1K, C", 1000, clip, b)
timeit_both("clip, 1K×1K, F", 1000, clip, bT)
timeit_both("clip, 500×500, A", 1000, clip, c)

timeit_both("astype, 1M", 1000, astype, a)
timeit_both("astype, 1K×1K, C", 1000, astype, b)
timeit_both("astype, 1K×1K, F", 1000, astype, bT)
timeit_both("astype, 500×500, A", 1000, astype, c)
```

Expected behaviour: reshaping and transposing should not affect performance.

System information:
- numba 0.59rc1
- llvmlite 0.42.0rc1
- numpy 1.26.3
- Python 3.10.12
user: bmerry
labels: performance: performance related issue
performance - run time: Performance issue occurring at run time.
issue_9398: state: open
title: CUDA: Providing a signature for a function reference when eagerly compiling does not work
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Minimal example:

```python
import numba as nb
from numba import cuda
import numpy as np

@cuda.jit("f8(f8)", device = True, inline = True)
def foo(x):
    return x + 1

@cuda.jit("f8(FunctionType(f8(f8)),f8)", device = True, inline = True)  # ISSUE HERE
def demo(func, x):
    return func(x) * 2

@nb.vectorize("f8(f8)", target = "cuda", nopython = True)
def demo_vec(x):
    return demo(foo, x)

X = np.arange(10., 20.)
print(demo_vec(X))
```

On CPUs, i.e. using `numba.jit`, I could provide a signature for `demo` as follows: `f8(FunctionType(f8(f8)),f8)`. This appears to not work for CUDA. 

Workaround: Do not provide a signature for `demo`.

Providing `CUDADispatcher` instead of `FunctionType` does not work either. Is there a different (undocumented) notation or is there simply not a solution for this in `numba` at the moment?

For more context / my use case, see [here](https://numba.discourse.group/t/cuda-device-function-pointers-re-implementing-scipy-integrate-solve-ivp-for-numba-cuda/2342).
user: s-m-e
labels: CUDA: CUDA related issue/PR
issue_9397: state: open
title: Reorder block traversal order for correct hoisting.
body: Resolves #9379


user: DrTodd13
issue_9396: state: open
title: Add ability to @jit to disable auto-vectorization
body: Two use cases:

1. More significantly, sometimes auto-vectorization with SIMD makes a function slower. There are the environment variables to disable auto-vectorization, but that affects _all_ code in the process. Even if there's only a single function, restarting the process for performance comparisons is annoying.
2. For educational purposes, I am disabling it and comparing functions with and without SIMD (which is how I discovered the above).

### A workaround

Here's what I'm doing now:

```python
from contextlib import contextmanager
import sys
import os

@contextmanager
def disabled_simd():
    """
    Temporarily disable SIMD when creating an `@njit`-decorated function.

    This is a horrible hack, but Numba doesn't have any other way of doing this
    at the time of writing.

    Usage::

        with disabled_simd() as njit_no_simd:
            @njit_no_simd
            def this_will_not_use_simd():
                # ... your Numba code ...

            # Make sure to compile it inside the with block by calling it with appropriate inputs!
            _ = this_will_not_use_simd()
    """
    def clear_numba():
        """Remove already imported modules for Numba and LLVMLite."""
        for mod in list(sys.modules):
            if mod.startswith("numba") or mod.startswith("llvmlite"):
                del sys.modules[mod]

    clear_numba()
    os.environ["NUMBA_LOOP_VECTORIZE"] = "0"
    try:
        from numba import njit
        yield njit
    finally:
        os.environ["NUMBA_LOOP_VECTORIZE"] = "1"
        clear_numba()
```

user: itamarst
labels: performance - run time: Performance issue occurring at run time.
issue_9395: state: open
title: Elapsed running time of parallel jit for the logistic regression documentation example is dozens of seconds
body: Using numba 0.58.1, python 3.10.13  [GCC 9.4.0] on linux, I am running the [following example code from the docs](https://numba.readthedocs.io/en/stable/user/parallel.html#examples) resulting in quite unexpected behavior:

```python
@numba.jit(nopython=True, parallel=True)
def logistic_regression(Y, X, w, iterations):
    for i in range(iterations):
        w -= np.dot(((1.0 / (1.0 + np.exp(-Y * np.dot(X, w))) - 1.0) * Y), X)
    return w
```

― feeding in the following input arguments:

```python
    N = 100
    D = 100

    Y = np.random.rand(N)
    X = np.random.rand(N, D)
    w = np.random.rand(D)
    iterations = 1000

    print(numba_logistic_regression(Y, X, w, iterations))
```

As opposed to decorating the function with `@njit(parallel=False)`, setting the decorator with `parallel=True` makes the function run for dozens of seconds utilizing 12 logical cores on an i7-8700. Whereas when parallel is set to `False`, or when <span>@</span>jit is not used at all, the function returns quite promptly.

For doubt avoidance, this is the same when using `cache=True` twice, and I doubt that the jit compilation would use all those cores anyway. 

While I've used numba before, in humble capacities but for a long duration, without parallel=True, it might be worth noting that running the additional method from that same documentation page right after the function finally returns, `parallel_diagnostics(level=4)`, fails in my case with the following traceback:

```
Traceback (most recent call last):
  File "example.py", line 34, in <module>
    numba_logistic_regression.parallel_diagnostics(level=4)
  File ".venv3.10/lib/python3.10/site-packages/numba/core/dispatcher.py", line 1035, in parallel_diagnostics
    [dump(sig) for sig in self.signatures]
  File ".venv3.10/lib/python3.10/site-packages/numba/core/dispatcher.py", line 1035, in <listcomp>
    [dump(sig) for sig in self.signatures]
  File ".venv3.10/lib/python3.10/site-packages/numba/core/dispatcher.py", line 1027, in dump
    pfdiag = ol.metadata.get('parfor_diagnostics', None)
AttributeError: 'NoneType' object has no attribute 'get'
```

Since code formatting is much more enabling here, I went ahead posting this here even though my understanding of the parallel options are at this stage not even cursory.
user: matanox
labels: performance - run time: Performance issue occurring at run time.
issue_9393: state: open
title: Shall we consider using an envvar to disable refct atomic instructions
body: Since I do find in some cases (especially if some users use numba in single-threaded program), changing this internal variable `_disable_atomicity` for `NRT_incf` and `NRT_decref` does help to boost the performance.
https://github.com/numba/numba/blob/28e68e58c2268ac022d384b51417ab14d819814a/numba/core/runtime/nrtdynmod.py#L108


Further, maybe we can also use a `i64` rather than `std::atomic_size_t` for `refct` in MemInfo to gain more performance back.
https://github.com/numba/numba/blob/28e68e58c2268ac022d384b51417ab14d819814a/numba/core/runtime/nrt.cpp#L18
user: dlee992
issue_9392: state: open
title: In some cases, Numba 0.57.1 (can also be reproduced in 0.59.0) does not assign values to a NumPy array
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```
import numpy as np
import numba

@numba.njit(boundscheck=True)
def numba_set_val(np_arr):
    
    def get_amount_g(amount):  
        return -1 if amount else 1
                
    get_amount_g(1)  # This function needs to be called, otherwise, the issue won't appear
    a = 0
    v = np_arr[-1 if a else 1]  # The key here is to have a ternary (if-else),
    v['value'] = 147258

    # print(v) # If this line is uncommented, then the above assignment will succeed

if __name__ == "__main__":
    
    print(numba.__version__)  # 0.57.1
    arr = np.zeros(3, dtype=[('value', 'int64')])
    numba_set_val(arr)
    print(arr[:])
    pass
```

Expect to print out [(0,) (147258,)]
Actually prints out: [(0,) (0,)]

Uncommenting the print(v) line results in printing the expected output.

user: shrealist
labels: bug - miscompile: Bugs: miscompile
issue_9390: state: open
title: Add .tobytes() method
body: This is a follow-up of https://github.com/numba/numba/pull/8663. I only rebased the PR, removed a part of the code that wasn't covered by tests and added a release note.
user: guilhermeleobas
labels: Effort - short: Short size effort needed
issue_9387: state: open
title: numba.get_num_threads/set_num_threads resets the value of torch.get_num_threads
body: First call of `numba.get_num_threads()` or `numba.get_num_threads()` resets `torch` num_threads value to CPU count. 

Minimal demos:
``` python
$ srun --mem=48G -c32 --container-image=./nemo_head.sqfs --pty bash
root@x:/workspace/nemo# nproc
32
root@x:/workspace/nemo# export OMP_NUM_THREADS=8
root@x:/workspace/nemo# nproc
8
root@x:/workspace/nemo# python3
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing as mp, numba, torch

>>> torch.__version__
'2.1.0a0+29c30b1'

>>> numba.__version__
'0.57.1+1.gc785c8f1f'

>>> mp.cpu_count()
256

>>> torch.get_num_threads()
8

>>> print(torch.__config__.parallel_info())
ATen/Parallel:
        at::get_num_threads() : 8
        at::get_num_interop_threads() : 128
OpenMP 201511 (a.k.a. OpenMP 4.5)
        omp_get_max_threads() : 8
Intel(R) oneAPI Math Kernel Library Version 2021.1-Product Build 20201104 for Intel(R) 64 architecture applications
        mkl_get_max_threads() : 8
Intel(R) MKL-DNN v2.7.3 (Git Hash N/A)
std::thread::hardware_concurrency() : 256
Environment variables:
        OMP_NUM_THREADS : 8
        MKL_NUM_THREADS : [not set]
ATen parallel backend: OpenMP

>>> numba.get_num_threads()
32

>>> torch.get_num_threads()
32

>>> print(torch.__config__.parallel_info())
ATen/Parallel:
        at::get_num_threads() : 32
        at::get_num_interop_threads() : 128
OpenMP 201511 (a.k.a. OpenMP 4.5)
        omp_get_max_threads() : 32
Intel(R) oneAPI Math Kernel Library Version 2021.1-Product Build 20201104 for Intel(R) 64 architecture applications
        mkl_get_max_threads() : 32
Intel(R) MKL-DNN v2.7.3 (Git Hash N/A)
std::thread::hardware_concurrency() : 256
Environment variables:
        OMP_NUM_THREADS : 8
        MKL_NUM_THREADS : [not set]
ATen parallel backend: OpenMP

>>> numba.set_num_threads(2)
>>> numba.get_num_threads()
2

>>> torch.get_num_threads()
32

>>> exit()
root@x:/workspace/nemo# exit
exit
```

```python
root@x:/workspace/nemo# python3
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numba, torch
>>> torch.get_num_threads()
8
>>> torch.set_num_threads(4)
>>> torch.get_num_threads()
4
>>> numba.get_num_threads()
32
>>> torch.get_num_threads()
32
>>> torch.set_num_threads(4)
>>> numba.get_num_threads()
32
>>> torch.get_num_threads()
4
>>> numba.set_num_threads(2)
>>> torch.get_num_threads()
4
>>> numba.get_num_threads()
2
>>> 
```
user: itzsimpl
labels: threading: Issue involving the threading layers
issue_9386: state: open
title: added test case as mentioned in issue #8997 
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->
Hey!
 I have added a test case for issue #8975 as mentioned in issue #8997 . Kindly review it and let me know if any further changes are required.

user: Kamakshi8104
labels: 4 - Waiting on author: Waiting for author to respond to review
issue_9385: state: open
title: Cannot find source for CUDA kernels decorated with `lineinfo=True` when executed from Jupyter notebook cell
body: For CUDA profiling and potentially debugging purposes, it is important to be able to correlate high-level numba Python code with low-level assembly. This is achieved by providing lineinfo during compilation. In CUDA kernels written in numba cuda, functions have to be decorated with `lineinfo=True` for this.

When executing such functions in standalone Python scripts, profiling tools like Nsight Compute are provided this lineinfo. However, when executing such functions from a cell in a jupyter notebook, numba issues a warning that no function source can be found. This prevents tools integrated with jupyter to fully profile such kernels, since this correlation from SASS assembly to high-level Python is not possible anymore.

```
import math
import numba.cuda
import numpy as np

(width, height) = (128, 128)
np_img = np.zeros((width, height, 1), dtype=int)
gpu_mem = numba.cuda.to_device(np_img)

@numba.cuda.jit(lineinfo=True)
def kernel(buf):
    tx, ty = numba.cuda.grid(2)
    buf[ty][tx] = 1

block = (8,8)    
grid = (math.ceil(width/block[0]), math.ceil(height/block[1]))

kernel[grid, block](gpu_mem)
numba.cuda.synchronize()
```
```
/usr/local/lib/python3.8/dist-packages/numba/core/lowering.py:112: NumbaDebugInfoWarning: Could not find source for function: <function kernel at 0x7f6e5a812700>. Debug line information may be inaccurate.
  warnings.warn(NumbaDebugInfoWarning(msg))
  ```
This was tested with numba 0.58 and Jupyterlab 4.0.10.
user: fs-nv
labels: CUDA: CUDA related issue/PR
issue_9384: state: open
title: Added is identity comparison for numpy records and added tests as is_comparison_tests.py
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->Hello!
I have added the workaround to numba/np/arrayobj.py and have created test cases for the same.
Please let me know if any more changes are required
regards,
Kamakshi

user: Kamakshi8104
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
PR Help needed: Help is needed to complete a PR.
issue_9382: state: open
title: numpy records do not support "is" identity comparison.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

The following fails:
```py
from numba import cuda  # type: ignore
import numpy as np


def test_structured_is() -> None:
    a = np.zeros(1, dtype=[("a", "i4"), ("b", "i4")])[0]
    test_kernel[1, 1](a)


@cuda.jit
def test_kernel(a: np.ndarray) -> None:
    """
    Test kernel.
    """
    print(int(a is a))
```
Error:

```
    @lower_builtin(operator.is_, types.Any, types.Any)
    def generic_is(context, builder, sig, args):
        """
        Default implementation for `x is y`
        """
        lhs_type, rhs_type = sig.args
        # the lhs and rhs have the same type
        if lhs_type == rhs_type:
                # mutable types
                if lhs_type.mutable:
                    msg = 'no default `is` implementation'
>                   raise LoweringError(msg)
E                   numba.core.errors.LoweringError: Failed in cuda mode pipeline (step: native lowering)
E                   no default `is` implementation
E                   During: lowering "$32is_op.6 = a is a" at /home/shauncutts/src/factfiber.ai/learn/timbuktu/tests/context/test_util.py (156)
```

user: shaunc
issue_9380: state: open
title: emit a warning/error if enabling `boundscheck=True` together with `parallel=True` (raising exceptions from within threads has unspecified behaviour)
user: slayoo
issue_9379: state: open
title: njit(parallel = True)  gives wrong output
body: ## njit with parallel = True gives the wrong output.

The function _groupby_apply_nb_parallel_dynamic_size partially replicates a dataframe.groupby().apply(func) using numba for speedup. Full minimal example code available below.

The function _groupby_apply_nb_parallel_dynamic_size returns wrong output when parallel is set to true.
I have also noticed that when parallel = True, the output of _groupby_apply_nb_parallel_dynamic_size (in the minimal example below) returns os.cpu_count() unique values, when it should return 1001 unique values. The function works correctly when setting Parallel = False. I have also managed to get the correct output by doing some modifications, such as: 
`    out_cols_size = 1 # Setting this to 1 statically also seems to solve the issue
`
Even though I don't know why this should fix the issue.

I can't see any data race conditions, thus why I think it is a Numba bug. 


OS: Ubuntu 22.04
Python 3.11.7
Numba version: '0.58.1', installed through pip
Numpy  '1.26.2'
Pandas : '2.1.4' (it's only used to generate the expected array, nothing else). The version doesn't matter

The below code has similar behavior as pandas.DataFrame.groupby

```
import os
import numpy as np
import numba
from numba import njit, prange
from numba.typed import List as NumbaList
import pandas as pd


PARALLEL = True # Set it to false so it works with no issues

@njit(cache=False)
def get_max_first_array_of_list_of_arrays(y_x: NumbaList, return_dtype=np.float64):
    """
    This function only uses the first element of y_x as a minimal example
    """
    y = y_x[0]
    ans = np.array([y.max()], dtype=return_dtype)
    return ans


@njit(parallel=PARALLEL, cache=False)
def _groupby_apply_nb_parallel_dynamic_size(
    start_indices: np.array,
    end_indices: np.array,
    # dataargs is a list of numpy 2d arrays
    dataargs: numba.typed.List,
    func: callable,
    funcargs,
    return_dtype=np.float64,
):
    """
    start_indices : 1d np.array with the start indices of each group
    end_indices : 1d np.array with the end indices of each group
    dataargs: List of np 2d arrays. These are arguments of func
    func: jitted function
    funcargs: other arguments to func.
    return_dtype : output array dtype
    
    """

    ngroups = len(start_indices)
    if ngroups == 0:
        raise Exception("empty number of grouped, (start_indices)")

    # First call to determinize the size of the output. Assumes the first group will have output size
    # equal to the output size of all other groups
    res = func(
        [data[start_indices[0] : end_indices[0], ...] for data in dataargs], *funcargs
    )
    out_cols_size = res.shape[0] # Setting this to 1 statically also seems to solve the issue
    result = np.empty(shape=(ngroups, out_cols_size), dtype=return_dtype)

    for k in prange(ngroups):
        start_idx = start_indices[k]
        end_idx = end_indices[k]
        res = func([data[start_idx:end_idx, ...] for data in dataargs], *funcargs)
        result[k, :] = res

    return result


if __name__ == "__main__":

    np.random.seed(42)
    size = 100_000
    qty_intervals = 1_000
    save_dir = os.path.join("random_experiments", "parallel_py")

    samples = np.sort(np.random.choice(range(size), qty_intervals, replace=False))
    start_indices = np.append(0, samples)
    end_indices = np.append(samples, size)

    x = np.zeros(shape = (size)) # This could be any np.array
    y = np.exp(np.cumsum(np.random.normal(0, 1e-2, size)))

    os.makedirs(save_dir, exist_ok=True)
    for i in range(10):
        max_vals = _groupby_apply_nb_parallel_dynamic_size(
            start_indices = start_indices,
            end_indices = end_indices,
            dataargs  = NumbaList([y, x]),
            func = get_max_first_array_of_list_of_arrays,
            funcargs=(),
            return_dtype=np.float64,
        )
        save_path = os.path.join(save_dir, f'output_{i}_.npy')
        np.save(save_path, max_vals)

    groups = np.zeros(size, dtype=np.int64)
    groups[start_indices] = 1
    groups = np.cumsum(groups)
    max_expected = pd.DataFrame(y).groupby(by = groups).max().values

    for i in range(10):
        save_path = os.path.join(save_dir, f'output_{i}_.npy')
        max_vals = np.load(save_path)
        equal =  np.isclose(max_expected, max_vals, equal_nan = True, rtol = 1e-6).all()
        if not equal:
            print(f"ERROR - parallel output {i} is wrong")

    print(f"Number of unique values : {len(np.unique(max_vals))}")
    print(f"Number of unique expected : {len(np.unique(max_expected))}")
```



<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: netomenoci
issue_9377: state: open
title: Support parallel dynamic gufuncs
body: Fix: https://github.com/numba/numba/pull/9339

Moved the implementation of dynamic gufucs from `GUFunc` to `GUFuncBuilder`, deleted `gufunc.py` and added a new test class for parallel GUFuncs.
user: guilhermeleobas
labels: Effort - medium: Medium size effort needed
issue_9376: state: open
title: Change definition of complex sign if numpy does
body: Just a heads-up that over at numpy, I have a PR -- https://github.com/numpy/numpy/pull/25441 -- that changes the definition of complex sign to `z / |z|`, which follows the Array API standard and is more logical than what numpy (and numba) had. This is still open for discussion on the mailing list [1], but the hope is to make the change in numpy 2.0.

[1] https://mail.python.org/archives/list/numpy-discussion@python.org/thread/HHAHGWGFCI6CCZ6EPWMI7HQCDHGD4T5D/
user: mhvk
issue_9375: state: open
title: Numba stuck compiling
body: 
- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.


I have a code snippet that seems to get Numba stuck in the compiling stage. I let it run for a few minutes and then stopped it via keyboard interrupt. The stack trace is very long.

This is my code snippet:
```
from typing import List, Union, Tuple
import numpy as np
from numba import njit


@njit()
def to_shape_idxs(shapes: List[Tuple[tuple]]):
    print(shapes)
    shape_lut = {shapes[0]: 0}
    idxs_by_shape_idx = [[0]]
    shapes_by_idx = [shapes[0]]
    for i, shape in enumerate(shapes[1:]):
        idx = shape_lut.get(shape, len(shape_lut))
        if idx != len(shape_lut):
            idxs_by_shape_idx[idx].append(i+1)
        else:
            shape_lut[shape] = idx
            shapes_by_idx.append(shape)
            idxs_by_shape_idx.append([i+1])
    print("_to_shape_idxs loop done")
    return idxs_by_shape_idx, shapes_by_idx


if __name__ == "__main__":
    shapes = [((768,), (), (8, 42), ()), ((768,), (), (8, 42), ())]
    print("shapes initialized")
    print(to_shape_idxs(shapes))
```

I uploaded the stack trace that I got as I interrupted the program as a file because it's 833 lines long.

[numbaStacktrace.txt](https://github.com/numba/numba/files/13705584/numbaStacktrace.txt)


Expected behavior:
Numba either finishes compiling in a reasonable amount of time or raises an error. 


user: Faberix
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9374: state: open
title: numba a lot slower for dict lookup when numpy array in value
body: 

- [x ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.


Take the following code:
```

from numpy.random import randint
import numba as nb

@nb.njit
def foo_numba(a, b, c):
    N = 100**2
    d = {}
    for i in range(N):
        d[(randint(N), randint(N), randint(N))] = (a, b, c)
    return d


@nb.njit
def test_numba(numba_dict):
    s = 0.0
    for k in numba_dict:
        s += numba_dict[k][2]
    return s



def foo(a, b, c):
    N = 100**2
    d = {}
    for i in range(N):
        d[(randint(N), randint(N), randint(N))] = (a, b, c)
    return d



def test(numba_dict):
    s = 0.0
    for k in numba_dict:
        s += numba_dict[k][2]
    return s

a = randint(10, size=1)
b = randint(10, size=1)
c = 1.3

t_numba = foo_numba(a, b, c)
%timeit test_numba(t_numba)
t = foo(a, b, c)
%timeit test(t) 

```


The results I get are:

880 µs ± 4.55 µs per loop (mean ± std. dev. of 10 runs, 1,000 loops each)
634 µs ± 41.4 µs per loop (mean ± std. dev. of 10 runs, 1,000 loops each)

The slowdown disappears completely if you do either a = tuple(a) or b = tuple(b) (there seems to be no need to do both!).




user: lesshaste
labels: performance - run time: Performance issue occurring at run time.
issue_9366: state: open
title: Poor performance with astype on an array
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

The expression `np.sum(np.square(x.astype(np.int64)))` when run on a 1D int8 array is more than twice as slow as evaluating it in plain numpy, and 80+ times slower than the function written serially with a loop. I expected performance to be similar to the explicit loop version (maybe faster because the compact version doesn't try to tell the compiler how to structure the implementation).

Sample code:
```python
#!/usr/bin/env python3

import time

import numba
import numpy as np


@numba.njit
def sum_squared(x):
    total = np.int64(0)
    for i in range(len(x)):
        sample = np.int64(x[i])
        total += sample * sample
    return total


@numba.njit
def sum_squared_compact(x):
    return np.sum(np.square(x.astype(np.int64)))


def time_it(name, func, x):
    func(x)  # Warmup pass e.g. to JIT compile
    passes = 100
    start = time.monotonic()
    for _ in range(passes):
        func(x)
    stop = time.monotonic()
    print(f"{name:25} {(stop - start) / passes * 1e3:6.3f} ms")


def main():
    rng = np.random.default_rng()
    x = rng.integers(-100, 100, size=1000000, dtype=np.int8)
    time_it("sum_squared", sum_squared, x)
    time_it("sum_squared_compact", sum_squared_compact, x)
    time_it("pure numpy", sum_squared_compact.py_func, x)


if __name__ == "__main__":
    main()
```

Output:
```
sum_squared                0.090 ms
sum_squared_compact        7.379 ms
pure numpy                 3.355 ms
```

Environment:
- Python 3.10.12
- numba 0.58.1
- numpy 1.26.2
user: bmerry
labels: performance: performance related issue
issue_9361: state: open
title: `overload_method` doesn't use `constant propagation` optimization well as `njit`
body: During testing #9213, I found another issue for `overload_method`.

Test case:
```python
import os

import numpy as np
from numba import njit
from numba.core import types
from numba.core.extending import overload_method
from numba.experimental import structref

os.environ["NUMBA_DUMP_OPTIMIZED"] = "1"
os.environ["NUMBA_DUMP_FUNC_OPT"] = "1"

@structref.register
class SRType(types.StructRef):
    pass

class SR(structref.StructRefProxy):
    def __new__(cls, arr, value):
        return structref.StructRefProxy.__new__(cls, arr, value)

structref.define_proxy(SR, SRType, ["arr", "value"])

@overload_method(SRType, "method")
def ol_method(self, flag):
    def method(self, flag):
        if flag:
            return True
        else:
            return False
    return method

@njit
def method2(self, flag):
    if flag:
        return True
    else:
        return False

@njit
def foo(sr, flag):
    sr.method(True)

@njit
def goo(sr, flag):
    method2(sr, True)

sr = SR(np.zeros(2),0)
flag = True
foo(sr, flag)
goo(sr, flag)
```

For `ol_method` IR, it generates 
```
define i32 @_ZN8__main__9ol_method12_3clocals_3e6methodB2v4B42c8tJTIcFHzwl2ILiXkcBV0KBSmNGHkyiCKJEEwA_3dEN5numba100SRType_28_28_27arr_27_2c_20array_28float64_2c_201d_2c_20C_29_29_2c_20_28_27value_27_2c_20int64_29_29Eb(i8* noalias nocapture %retptr, { i8*, i32, i8* }** noalias nocapture readnone %excinfo, i8* nocapture readnone %arg.self.0, i8 %arg.flag) local_unnamed_addr #0 {
entry:
  %.8.not = icmp eq i8 %arg.flag, 0
  br i1 %.8.not, label %B10, label %B6

B6:                                               ; preds = %entry
  store i8 1, i8* %retptr, align 1
  ret i32 0

B10:                                              ; preds = %entry
  store i8 0, i8* %retptr, align 1
  ret i32 0
}
```

For `method2` IR, it generates
```
define i32 @_ZN8__main__7method2B2v6B38c8tJTIcFHzwl2ILiXkcBV0KBSgP9CGZpAgA_3dEN5numba100SRType_28_28_27arr_27_2c_20array_28float64_2c_201d_2c_20C_29_29_2c_20_28_27value_27_2c_20int64_29_29E27Literal_5bbool_5d_28True_29(i8* noalias nocapture %retptr, { i8*, i32, i8* }** noalias nocapture readnone %excinfo, i8* nocapture readnone %arg.self.0, i8 %arg.flag) local_unnamed_addr #0 {
entry:
  store i8 1, i8* %retptr, align 1
  ret i32 0
}
```
Any clue? Tested on 0.56.4 and llvmlite 0.39.1
user: dlee992
labels: performance - run time: Performance issue occurring at run time.
issue_9355: state: open
title: Intermittent NRT leak with `print(reflected list)`
body: `main` branch as of e56e93e (and probably from the point of merging #9330) has an intermittent issue in the test:
```
numba.tests.test_print.TestPrint.test_print_values
```
specifically this part of the test:
https://github.com/numba/numba/blob/e56e93e0d65170746befec5f92c903b1cc364b5f/numba/tests/test_print.py#L73-L77

the issue is that the `assertNoNRTLeak()` fails with:
```
AssertionError 2 != 3 : number of data allocs != number of data frees
```

Current thoughts are that it is likely that adjusting the code base and tests to not use `compile_isolated` (#9330) has unveiled a latent bug either localised to `ir.Print` lowering or perhaps `box`/`unbox`ing of reflected lists. Another possibility is that it's to do with dictionary ordering/hash seed and what is in the context's caches, perhaps there's more than one definition/match for some part of the compilation path (and one of them is wrong/doesn't apply) and the first found wins, this might explain the intermittent nature of the problem.
user: stuartarchibald
labels: bug - memory leak: Memory leak
issue_9350: state: open
title: FEATURE REQUEST: enable more fine grained control over Numba cache
body: As discussed in: https://github.com/numba/numba/issues/9312 -- this feature requests captures the idea to enable more fine grained control over the cache location used by Numba. This issues summarizes the discoveries in https://github.com/numba/numba/issues/9312 in a coherent form. For more details and context, please do look at the original bug report.

Fixes #9312 

As described in: https://numba.readthedocs.io/en/stable/reference/envvars.html#envvar-NUMBA_CACHE_DIR -- Numba currently uses an internal strategy to determine the cache location. This strategy (order of locations checked/used) can not be modified itself and it is only possible to "clamp" the location globally using the `NUMBA_CACHE_DIR` environment variable. 

It has been noticed by library authors (that is to say, users that write libraries that depend on and use Numba) that the default strategy may interfere with assumptions that package managers `pip` and `conda` make about packages. Effectively, the default strategy means that the cache files for an installed library are installed into the same location as the package. Consequently, this causes issues because the cache files are not tracked by the metadata and as such the package managers can not uninstall the package properly. This in turn causes issues where the package appears to exists, but can not be loaded. 

While library authors could use `NUMBA_CACHE_DIR` in principle, this approach doesn't scale and breaks down as soon as a hypothetical user installs two Numba based libraries as these would end up "stepping on each others toes".

The proposed solution is outlined in:  https://github.com/numba/numba/issues/9312#issuecomment-1833192973

The solution needs to be a per-decorator option. So each package that caches Numba functions can configure it's cache location independently. The interface would look like:

```
@njit(..... cache=VARIABLE)
```

Where `VARIABLE` could be `True` or `False` in which case it will cache (or not) and use the default priority list if caching. Or it could be a path to precise location on disk, like `NUMBA_CACHE_DIR` does now. OR (and this is where it gets interesting) -- it could be a value from a Numba-defined Enum, like `SYSTEM_CACHE` or `USER_CACHE` or `IPYTHON_CACHE` -- which would then reflect the three known locations and Numba would look those up and use them. 

The `cache` parameter exists already and is currently a boolean. Expanding this to be a union type of boolean/string/path/enum-variable will be backwards compatible as the interface is widened. 

This will provide library authors with sufficient granularity to reconfigure their packages to store their caches ina more suitable location.

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: esc
labels: caching: Issue involving caching
issue_9348: state: open
title: Random cache corruption
body: After doing many code changes and recompiles, following error occures:
```
ReferenceError: underlying object has vanished
```
It is independent of the underlying code. The only way to recover from this error is:
```bash
find . -name '*.nbi' | xargs rm
```
user: TheTesla
labels: bug - ice: Bugs: internal compiler error
issue_9345: state: open
title: Support calling gufunc without output buffers 
body: gufuncs have a restriction where the pattern `out = gufunc(arg1, arg2, ..., argN)` is not supported:

```python
from numba import guvectorize
import numpy as np

@guvectorize('(n),(n) -> (n)')
def add(a, b, res):
    for i in range(a.shape[0]):
        res[i] = a[i] + b[i]

a = np.arange(5)
b = np.ones_like(5)
add(a, b)

# Traceback (most recent call last):
#   File "/Users/guilhermeleobas/git/numba/b.py", line 11, in <module>
#     add(a, b)
#   File "/Users/guilhermeleobas/git/numba/numba/np/ufunc/gufunc.py", line 186, in __call__
#     raise TypeError(msg)
# TypeError: Too few arguments for function 'add'. Note that the pattern `out = gufunc(Arg1, Arg2, ..., ArgN)` is not allowed. Use `gufunc(Arg1, Arg2, ..., ArgN, out) instead.
```

I do not know how hard this one is, as one needs to guess the dtype of `res` to compile the correct kernel.
user: guilhermeleobas
issue_9344: state: open
title: Fix exception message when the number of arguments does not match in a gufunc
body: When calling a gufunc in Numba with the wrong number of arguments, the error message is not precise when the number of arguments exceeds the list of parameters.

```python
from numba import guvectorize
import numpy as np

@guvectorize('(n),(n) -> (n),(n)')
def divmod(x, y, div, mod):
    for i in range(x.shape[0]):
        div[i], mod[i] = np.divmod(x[i], y[i])

x = np.arange(5, dtype='i4') + 5
y = np.full_like(x, fill_value=2)
div = np.zeros_like(x)
mod = np.zeros_like(x)

divmod(x, y, div)
# Traceback (most recent call last):
#   File "/Users/guilhermeleobas/git/numba/repro.py", line 13, in <module>
#     divmod(x, y, div)
#   File "/Users/guilhermeleobas/git/numba/numba/np/ufunc/gufunc.py", line 186, in __call__
#     raise TypeError(msg)
# TypeError: Too few arguments for function 'divmod'. Note that the pattern `out = gufunc(Arg1, Arg2, ..., ArgN)` is not allowed. Use `gufunc(Arg1, Arg2, ..., ArgN, out) instead.

divmod(x, x, y, div, mod)
# Traceback (most recent call last):
#   File "/Users/guilhermeleobas/git/numba/repro.py", line 22, in <module>
#     divmod(x, x, y, div, mod)
#   File "/Users/guilhermeleobas/git/numba/numba/np/ufunc/gufunc.py", line 186, in __call__
#     raise TypeError(msg)
# TypeError: Too few arguments for function 'divmod'. Note that the pattern `out = gufunc(Arg1, Arg2, ..., ArgN)` is not allowed. Use `gufunc(Arg1, Arg2, ..., ArgN, out) instead.
```

In such cases, the reported error message be as informative what CPython reports in such cases:
```python
>>> import numpy as np
>>> a = np.ones((2, 5))
>>> b = np.ones((5, 2))
>>> c = np.zeros((2, 2))
>>> np.matmul(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: matmul() takes from 2 to 3 positional arguments but 1 were given
>>> np.matmul(a, b, c, c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: matmul() takes from 2 to 3 positional arguments but 4 were given
>>> np.matmul(a, b, c)
array([[5., 5.],
       [5., 5.]])
```
user: guilhermeleobas
issue_9339: state: open
title: Allow dynamic gufuncs with `target="parallel"`?
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Currently this works very nicely, from the docs:

```python
from numba import guvectorize
import numpy as np


@guvectorize(
    # No need to provide this!
    # [(float64[:], float64, float64[:])],
    '(n),()->(n)'
)
def g(x, y, res):
    for i in range(x.shape[0]):
        res[i] = x[i] + y

x = np.arange(5, dtype=np.int64)
y = 10
res = np.zeros_like(x)
g(x, y, res)
```

But with `target="parallel"`, it doesn't:

```python

@guvectorize(
    # [(float64[:], float64, float64[:])],
    '(n),()->(n)',
    target="parallel"
)
def g(x, y, res):
    for i in range(x.shape[0]):
        res[i] = x[i] + y
```

```
UFuncTypeError: ufunc '' did not contain a loop with signature matching types (<class 'numpy.dtypes.Float64DType'>, <class 'numpy.dtypes.Float64DType'>) -> None
```

Un-commenting the `[(float64[:], float64, float64[:])],` makes it work again, but we lose the dynamic gufunc. In numbagg, we'd really like to add that, since compiling for all the types in the signature takes ~1000ms for each function...
user: max-sixty
issue_9338: state: open
title: Add np.in1d, np.isin, np.setxor1d, np.setdiff1d, extend np.intersect1d.
body: * Adds support for the functions `np.in1d`, `np.isin`, `np.setxor1d`, and `np.setdiff1d`, all including optional argument `assume_unique` as well as `invert` for `np.in1d` and `np.isin`.

* Extends `np.intersect1d` to support the first optional argument (assume_unique).

Resolves #4677. Improves on #4074.

I have written unit tests for all the new functions and functionality, and applied flake8 to my code.

The only question I have is how to handle the optional argument `kind` in `np.in1d`: I've implemented the `kind="sort"` algorithm, but this is not the default behaviour of `numpy` (which picks an algorithm based on performance heuristics), so I've made it explicit that only `kind="sort"` is supported.
user: jaredjeya
labels: 4 - Waiting on author: Waiting for author to respond to review
Effort - medium: Medium size effort needed
issue_9333: state: open
title: Regression in parallel code between 0.55 and 0.56
body: Hi,

I wish to report some regression of code which was running until numba 0.55.2 (and earlier) and stopped working with numba 0.56.0 (and any later version I tried). It simply seg-faults after a couple of seconds. The code is using parallel loops, without those parallel loops it works as expected. 

Here is the code:
[bug.py](https://github.com/numba/numba/files/13560035/bug.txt)

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I did try to run the program under `gdb` and here are some details:

```
% gdb /usr/bin/python3
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python3...
Reading symbols from /usr/lib/debug/.build-id/ac/175ec7666754cf818b271b4fdc2761ac6865f2.debug...
(gdb) run cylinder_Au_test.py
Starting program: /usr/bin/python3 cylinder_Au_test.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff49ff6c0 (LWP 1056443)]
[New Thread 0x7ffff41fe6c0 (LWP 1056444)]
[New Thread 0x7fffeb9fd6c0 (LWP 1056445)]
[New Thread 0x7fffe31fc6c0 (LWP 1056446)]
[New Thread 0x7fffd29fb6c0 (LWP 1056447)]
[New Thread 0x7fffca1fa6c0 (LWP 1056448)]
[New Thread 0x7fffc19f96c0 (LWP 1056449)]
[New Thread 0x7fffc11f86c0 (LWP 1056450)]
[New Thread 0x7fffb09f76c0 (LWP 1056451)]
[New Thread 0x7fffa81f66c0 (LWP 1056452)]
[New Thread 0x7fffa79f56c0 (LWP 1056453)]
BFD: error: /usr/lib/debug/.build-id/b5/94dc721d75112eb9f2aa7a2c0ae957f373d962.debug(.debug_info) is too large (0x15ef54 bytes)
warning: Can't read data for section '.debug_info' in file '/usr/lib/debug/.build-id/b5/94dc721d75112eb9f2aa7a2c0ae957f373d962.debug'
warning: Section .debug_aranges in /usr/lib/debug/.build-id/b5/94dc721d75112eb9f2aa7a2c0ae957f373d962.debug entry at offset 0 debug_info_offset 0 does not exists, ignoring .debug_aranges.
Thermal diffusivity 1.301535e-04 m**2/s


Finite difference method


Δt 3.841619e-10 s
Δx 5.000000e-07 m
Exposure time 0.000100 s
Number of t steps 260306
Heat rate generation 1.452456e+13 W/m3
Absorbed heat rate 4.723301e-03 W
Adiabatic scattering volume ΔT 600.133831 K
Adiabatic sample volume ΔT 0.000777 K
ΔT max 6001338.307122 K
Scattering volume 3.251941e-16 m3
Sample volume 2.513274e-10 m3
[New Thread 0x7fff8617d6c0 (LWP 1056454)]
[New Thread 0x7fff8597c6c0 (LWP 1056455)]
[New Thread 0x7fff8517b6c0 (LWP 1056456)]
[New Thread 0x7fff8497a6c0 (LWP 1056457)]
[New Thread 0x7fff841796c0 (LWP 1056458)]
[New Thread 0x7fff839786c0 (LWP 1056459)]
[New Thread 0x7fff831776c0 (LWP 1056460)]
[New Thread 0x7fff829766c0 (LWP 1056461)]
[New Thread 0x7fff821756c0 (LWP 1056462)]
[New Thread 0x7fff819746c0 (LWP 1056463)]
[New Thread 0x7fff811736c0 (LWP 1056464)]

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x00007fff8aef3c81 in void std::vector<long, std::allocator<long> >::_M_realloc_insert<long const&>(__gnu_cxx::__normal_iterator<long*, std::vector<long, std::allocator<long> > >, long const&) ()
   from /usr/lib/python3/dist-packages/numba/np/ufunc/omppool.cpython-311-x86_64-linux-gnu.so


#0  0x00007fff8aef3c81 in void std::vector<long, std::allocator<long> >::_M_realloc_insert<long const&>(__gnu_cxx::__normal_iterator<long*, std::vector<long, std::allocator<long> > >, long const&) ()
   from /usr/lib/python3/dist-packages/numba/np/ufunc/omppool.cpython-311-x86_64-linux-gnu.so
#1  0x00007fff8aef29e7 in create_schedule(RangeActual const&, unsigned long) ()
   from /usr/lib/python3/dist-packages/numba/np/ufunc/omppool.cpython-311-x86_64-linux-gnu.so
#2  0x00007fff8aef3318 in do_scheduling_signed ()
   from /usr/lib/python3/dist-packages/numba/np/ufunc/omppool.cpython-311-x86_64-linux-gnu.so
#3  0x00007fff8aeda012 in __main__::finite_difference_cy[abi:v1][abi:c8tJTC_2fWQAlbW1yBC0oR6GELEUMELYSPGrIQMVjAQniQcIXKQIMVwoOGKoQDDVQQR1NHAS2FQ9XgSs8w86AhbIsexNXqICn1WqDBwOiC2AEA](Array<double, 1, A, mutable, aligned>, Array<double, 1, A, mutable, aligned>, Array<double, 2, A, mutable, aligned>, int, int, int, double, Array<double, 2, A, mutable, aligned>, double) ()
#4  0x00007fff8aedaa5b in cpython::__main__::finite_difference_cy[abi:v1][abi:c8tJTC_2fWQAlbW1yBC0oR6GELEUMELYSPGrIQMVjAQniQcIXKQIMVwoOGKoQDDVQQR1NHAS2FQ9XgSs8w86AhbIsexNXqICn1WqDBwOiC2AEA](Array<double, 1, A, mutable, aligned>, Array<double, 1, A, mutable, aligned>, Array<double, 2, A, mutable, aligned>, int, int, int, double, Array<double, 2, A, mutable, aligned>, double) ()
#5  0x00007fff95b7056d in ?? () from /usr/lib/python3/dist-packages/numba/_dispatcher.cpython-311-x86_64-linux-gnu.so
#6  0x0000000000517eb3 in _PyObject_MakeTpCall (tstate=0xa840d8 <_PyRuntime+166328>, 
    callable=<CPUDispatcher(typingctx=<Context(_registries={<Registry(functions=[<ABCMeta(__module__='numba.core.typing.cffi_utils', key='ffi.from_buffer', generic=<function at remote 0x7fff8837ede0>, __doc__=None, __abstractmethods__=frozenset(), _abc_impl=<_abc._abc_data at remote 0x7fff883a2640>) at remote 0x1fea690>], attributes=[<type at remote 0x20ec810>], globals=[]) at remote 0x7fff882e6f50>: <RegistryLoader(_registrations={'functions': <generator at remote 0x7fff882ded40>, 'attributes': <generator at remote 0x7fff882def20>, 'globals': <generator at remote 0x7fff882df2e0>}) at remote 0x7fff8838dd90>, <Registry(functions=[], attributes=[], globals=[(<built-in method tanh of module object at remote 0x7fff8838a340>, <Function(templates=(<ABCMeta(__module__='numba.core.typing.templates', key=<built-in method tanh of module object at remote 0x7fff8838a340>, __doc__=None, __abstractmethods__=frozenset(), _abc_impl=<_abc._abc_data at remote 0x7fff883a2280>) at remote 0x20f3cb0>,), typing_key=<built-in method tanh of modu...(truncated), args=<optimized out>, nargs=9, keywords=0x0)
    at ../Objects/call.c:214
#7  0x000000000052b940 in _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>, throwflag=<optimized out>)
    at ../Python/ceval.c:4772
#8  0x000000000052360b in _PyEval_EvalFrame (throwflag=0, frame=0x7ffff7f97020, tstate=0xa840d8 <_PyRuntime+166328>)
    at ../Include/internal/pycore_ceval.h:73
#9  _PyEval_Vector (args=0x0, argcount=0, kwnames=0x0, locals=<optimized out>, func=0x7ffff7c520c0, tstate=0xa840d8 <_PyRuntime+166328>)
    at ../Python/ceval.c:6435
#10 PyEval_EvalCode (co=<code at remote 0xba8ea0>, globals=<optimized out>, locals=<optimized out>) at ../Python/ceval.c:1154

```

We have been able to reproduce the bug on several computers so it should be fairly independent from the installation.

I hope this will allow you to spot the bug and fix it.  Numba is a very useful tools for scientists, making HPC accessible for them. 

Cheers,

Jerome

PS: I am not the original author of this code and assume it is correct. If there is anything obviously wrong with it, please tell me.
user: kif
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_9332: state: open
title: Updating numba_sysinfo to diagnose TBB and OMP problems
body: - Append TBB errors to error log
user: sklam
issue_9327: state: open
title: Python abort vs exception in `target="parallel"` with workqueue
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

As discussed at length in https://github.com/numba/numba/issues/9288 , running with `target="parallel"` aborts the whole python process if the `workqueue` backend is active and the function is run in a multithreaded context. The `workqueue` backend is the default for (at least) a macOS pip installation of numba. 

A exception would be much better.

```python
import numba
import numpy as np
from concurrent.futures import ThreadPoolExecutor

@numba.guvectorize(
    [(numba.float64[:], numba.float64[:])],
    "(n)->(n)",
    target="parallel",
    nopython=True,
)
def f(a, out):
    out[:] = a


def test_multithreading():
    with ThreadPoolExecutor(max_workers=2) as executor:
        futures = [executor.submit(f, np.arange(5)) for _ in range(10)]
        results = [f.result() for f in futures]
    assert all([isinstance(r, np.ndarray) for r in results])
    print("works on my machine")


test_multithreading()
```

Plenty of discussion in the other issue for more context; @esc asked me to open a new one, hence the new issue. Thank you.
user: max-sixty
issue_9324: state: open
title: NumPy like slice operations don't seem to work in CUDA mode
body: This is perhaps somewhere in-between a bug report and a feature request.

The Numba for CUDA documentation mentions under [NumPy support](https://numba.readthedocs.io/en/stable/cuda/cudapysupported.html#numpy-support) and the supported NumPy features:

> indexing and slicing works.

I'm trying to make use of basic slicing operations for mutation but they don't seem to work in CUDA mode, while do work in regular Numba CPU mode.

## Feature request

Minimal reproducible example:

```py
import numba.cuda
import numpy as np

def f(array):
    # This works:
    array[0, 0] += 10
    # But these don't work
    array[:, 1] += 1.0
    array[:, 1] = array[:, 0]

f_cpu = numba.njit(f)
f_gpu = numba.cuda.jit(f)

array_cpu = np.array([[1, 2, 3], [4, 5, 6]], dtype=np.float32)
array_gpu = numba.cuda.to_device(array_cpu)

print("\nRunning on CPU:")
f_cpu(array_cpu)
print(array_cpu)

print("\nRunning on GPU:")
f_gpu[1, 1](array_gpu)  # type: ignore
print(array_gpu)
```

On CPU this example works. When running in CUDA mode the `array[:, 1] += 1.0` line fails with:

<details>
<summary>Errors in "slice + scalar" case</summary>

```
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/fabian/git/_ext/ddsp_pytorch/ddsp/experiments/debug/debug_numba_gpu_operations_minimal.py", line 29, in <module>
    f_gpu[1, 1](array_gpu)  # type: ignore
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 539, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 673, in call
    kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 681, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 924, in compile
    kernel = _Kernel(self.py_func, argtypes, **self.targetoptions)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 83, in __init__
    cres = compile_cuda(self.py_func, types.void, self.argtypes,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/compiler.py", line 194, in compile_cuda
    cres = compiler.compile_extra(typingctx=typingctx,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 770, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 461, in compile_extra
    return self._compile_bytecode()
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 529, in _compile_bytecode
    return self._compile_core()
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 508, in _compile_core
    raise e
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 495, in _compile_core
    pm.run(self.state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 368, in run
    raise patched_exception
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 356, in run
    self._runPass(idx, pass_inst, state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 311, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 273, in check
    mangled = func(compiler_state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/typed_passes.py", line 110, in run_pass
    typemap, return_type, calltypes, errs = type_inference_stage(
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/typed_passes.py", line 91, in type_inference_stage
    errs = infer.propagate(raise_errors=raise_errors)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/typeinfer.py", line 1086, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in cuda mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function iadd>) found for signature:
 
 >>> iadd(array(float32, 1d, A), float64)
 
There are 14 candidate implementations:
  - Of which 12 did not match due to:
  Overload of function 'iadd': File: <numerous>: Line N/A.
    With argument(s): '(array(float32, 1d, A), float64)':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'iadd': File: unknown: Line unknown.
    With argument(s): '(array(float32, 1d, A), float64)':
   No match for registered cases:
    * (int64, int64) -> int64
    * (int64, uint64) -> int64
    * (uint64, int64) -> int64
    * (uint64, uint64) -> uint64
    * (float32, float32) -> float32
    * (float64, float64) -> float64
    * (complex64, complex64) -> complex64
    * (complex128, complex128) -> complex128

During: typing of intrinsic-call at /home/fabian/git/_ext/ddsp_pytorch/ddsp/experiments/debug/debug_numba_gpu_operations_minimal.py (13)

File "ddsp/experiments/debug/debug_numba_gpu_operations_minimal.py", line 13:
def f(array):
    <source elided>
    # But these don't work
    array[:, 1] += 1.0
    ^
```

</details>

The `array[:, 1] = array[:, 0]` line fails with:

<details>
<summary>Errors in "slice + slice" case</summary>

```
Traceback (most recent call last):
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/lowering.py", line 512, in lower_inst
    impl = self.context.get_function('static_setitem', signature)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/base.py", line 556, in get_function
    return self.get_function(fn, sig, _firstcall=False)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/base.py", line 558, in get_function
    raise NotImplementedError("No definition for lowering %s%s" % (key, sig))
NotImplementedError: No definition for lowering static_setitem(Array(float32, 2, 'C', False, aligned=True), Tuple((slice<a:b>, int64)), Array(float32, 1, 'A', False, aligned=True)) -> none

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/fabian/git/_ext/ddsp_pytorch/ddsp/experiments/debug/debug_numba_gpu_operations_minimal.py", line 29, in <module>
    f_gpu[1, 1](array_gpu)  # type: ignore
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 539, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 673, in call
    kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 681, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 924, in compile
    kernel = _Kernel(self.py_func, argtypes, **self.targetoptions)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/dispatcher.py", line 83, in __init__
    cres = compile_cuda(self.py_func, types.void, self.argtypes,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/cuda/compiler.py", line 194, in compile_cuda
    cres = compiler.compile_extra(typingctx=typingctx,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 770, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 461, in compile_extra
    return self._compile_bytecode()
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 529, in _compile_bytecode
    return self._compile_core()
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 508, in _compile_core
    raise e
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler.py", line 495, in _compile_core
    pm.run(self.state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 368, in run
    raise patched_exception
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 356, in run
    self._runPass(idx, pass_inst, state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 311, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 273, in check
    mangled = func(compiler_state)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/typed_passes.py", line 466, in run_pass
    lower.lower()
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/lowering.py", line 187, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/lowering.py", line 241, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/lowering.py", line 271, in lower_function_body
    self.lower_block(block)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/lowering.py", line 285, in lower_block
    self.lower_inst(inst)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/lowering.py", line 514, in lower_inst
    return self.lower_setitem(inst.target, inst.index_var,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/lowering.py", line 625, in lower_setitem
    return impl(self.builder, (target, index, value))
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/base.py", line 1187, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/base.py", line 1217, in wrapper
    return fn(*args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/np/arrayobj.py", line 554, in setitem_array
    return fancy_setslice(context, builder, sig, args,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/np/arrayobj.py", line 1675, in fancy_setslice
    src_getitem, src_cleanup = maybe_copy_source(context, builder, use_copy,
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/np/arrayobj.py", line 1248, in maybe_copy_source
    data = context.nrt.allocate(builder, allocsize)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/runtime/context.py", line 47, in wrap
    memptr = func(self, builder, *args, **kwargs)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/runtime/context.py", line 60, in allocate
    return self.allocate_unchecked(builder, size)
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/runtime/context.py", line 67, in allocate_unchecked
    self._require_nrt()
  File "/home/fabian/.virtualenvs/ddsp_pytorch/lib/python3.10/site-packages/numba/core/runtime/context.py", line 42, in _require_nrt
    raise errors.NumbaRuntimeError("NRT required but not enabled")
numba.core.errors.NumbaRuntimeError: Failed in cuda mode pipeline (step: native lowering)
NRT required but not enabled
During: lowering "array[(slice(None, None, None), 1)] = $30binary_subscr.14" at /home/fabian/git/_ext/ddsp_pytorch/ddsp/experiments/debug/debug_numba_gpu_operations_minimal.py (14)
```

</details>

Is this expected behavior or a bug?
user: bluenote10
labels: CUDA: CUDA related issue/PR
issue_9323: state: open
title: JIT compilation time jumped from 9sec on Python 3.9 to 219sec on Python 3.10
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have linked to a [self-contained code sample](https://github.com/1fish2/numba-test/blob/main/src/time_numba.py) to reproduce the problem.
  It's possible to run as `python src/time_numba.py` assuming `numba` is installed.

JIT compiling a lambda function used in a bio-simulation takes ≈24 times as long on Python 3.10+ as on Python 3.9. It's a bit faster on 3.11 but still > 3 minutes. This could mean adapting to some CPython implementation change would greatly speed up Numba.

https://github.com/1fish2/numba-test/blob/main/src/time_numba.py is a standalone test that's easy to run across Python versions. It has snapshots of code to construct 4 matrices generated with sympy, but it's fine to focus on `EQUILIBRIUM_RATES_JACOBIAN`. The compilation time differences with the other 3 matrices might be a good debugging clue.

The code looks like this: `lambda t, y, kf, kr: np.array([[-kr[0], kf[0] * y[2], kf[0] * y[1], 0, 0 ...], ...]).reshape(-1)`.

See https://github.com/1fish2/numba-test/blob/main/observations.md for some observations and run times measured on a 2018 MacBook Pro.

Note that:
* JIT compiling `EQUILIBRIUM_RATES_JACOBIAN` takes about 9s on Python 3.9, but jumps to 219s on Python 3.10 and 196s on Python 3.11.
* `time_numba.py` experiments with alternate ways to construct the matrix. `eq_rates_jac_def` JITs a function like this: `def eq_rates_jac_def(t, y, kf, kr): \n arr = np.zeros(37, 104) \n arr[0, 0] = -kr[0], kf[0] * y[2] \n ...`. This takes 274s to JIT compile even on Python 3.9 (although the JIT compiled function runs faster than the original lambda function). This could be a good debugging clue -- perhaps there's a source code size where the JIT cost goes non-linear.
* `eq_rates_jac_sp` is a sparse version of `eq_rates_jac_def`, that is, it omits all the `= 0` assignments to `arr`. It JIT compiles in 1-2s on Python 3.9 - 3.11 and the compiled code runs faster.
* `eq_rates_jac_sp_lambda` is a sparse version of the original lambda function. It JIT compiles in 2 - 9s.
user: 1fish2
labels: bug - regression: A regression against a previous version of Numba
issue_9321: state: open
title: Optional jitclass can't be compared, even with conditional guard for `None`
body: 

First test case:

```python
from numba import njit, float64
from numba.experimental import jitclass

@jitclass
class A:
	val: float64
	def __init__(self, val):
		self.val = val
	def __gt__(self, other):
		return self.val > other.val

@njit
def test():	
	a = A(10)
	# logic would appear in max reduction of a list[A]
	best = None
	if best is None or a > best:
		best = a
	return best

print(test())
```

Gives compiler error:
```
File "python3.11/site-packages/numba/experimental/jitclass/overloads.py", line 185, in class_lt
    if f"__{meth_reflected}__" in y.jit_methods:
                                  ^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'jit_methods'
```
My intention is that best would be an `Optional[A]` type. The error is from the `best is None` guard not getting caught I suppose, and so it's trying to compile `A > None`. The error doesn't occur when I use float64 directly, instead of A, so seems only to be a problem with jitclass.

Can get slightly different error if we change the logic to use a different condition for guarding against the None comparison:
```
@njit
def test():	
	a = A(10)
	# logic would appear in max reduction of a list[A]
	best = None
	found = True
	if not found:
		best = a
		found = True
	if not found or a > best:
		best = a
	return best
```
Gives compiler error:

```
File "python3.11/site-packages/numba/experimental/jitclass/overloads.py", line 185, in class_lt
   if f"__{meth_reflected}__" in y.jit_methods:
                                  ^^^^^^^^^^^^^
AttributeError: 'Optional' object has no attribute 'jit_methods
```

Workaround is to set `best` to be a dummy A, and then return `best if found else None`.
user: Azmisov
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9320: state: open
title: FEATURE REQUEST: adopt SPEC 0
body: 
As discussed in:

https://github.com/numba/numba/issues/9272

it is is worth considering if Numba should adopt SPEC 0: https://scientific-python.org/specs/spec-0000/

The proposed schedule for adoption is drop 3.8 with 0.59 which is NEXT and then 3.9 with 0.60 which is NEXT_NEXT (early-mid 2024) and 3.10 then in a release Q4 2024 -- either 0.61 or 0.62 -- if we follow this schedule we will be in a position to have adopted SPEC 0 by Q4 2024 which is apprx. one year from now.

👇Please raise any concerns or breakage of interfaces here. Is there anything that would disallow this schedule? 👇
user: esc
issue_9319: state: open
title: Post py38 remove cleanup
body: Following #9310 I found two more bytecodes that were last seen with 3.7: `SETUP_LOOP` and `BREAK_LOOP`. These also appear in the documentation about the Numba architecture `docs/source/developer/architecture.rst`. However, updating the examples to show output generated under 3.11 appears to be quite rabitthole and will require some more work. The pull-request is opened as non-draft anyway, such that public CI can run and check if the code changes are good.
user: esc
labels: skip_release_notes: Skip towncrier requirement
issue_9317: state: open
title: [BUG] use np.newaxis in parallel mode cause the process terminated unexpectedly.
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

When the `np.newaxis` is used in parallel mode, the process terminates unexpectedly.

```python
import numpy as np
from numba import prange, njit


@njit(parallel=True)
def bug_func():
    n_cols = 10
    n_rows = 1

    for _ in prange(10):
        matrix = np.zeros((n_rows, n_cols))
        vector = np.zeros((n_rows,))

        # This line cause the process terminated unexpectedly. This should be the bug of numba.
        vector_ = vector[:, np.newaxis]

        value = np.exp(matrix - vector_)

    return None


if __name__ == '__main__':
    bug_func()
```

The output is:
```
AssertionError: Sizes of matrix, vector_ do not match on C:\Document\GTM\pygtm\numba_bug.py (17)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "C:\Program Files\JetBrains\PyCharm Community Edition 2022.1.1\plugins\python-ce\helpers\pydev\pydevd.py", line 1500, in _exec
    pydev_imports.execfile(file, globals, locals)  # execute the script
  File "C:\Program Files\JetBrains\PyCharm Community Edition 2022.1.1\plugins\python-ce\helpers\pydev\_pydev_imps\_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "C:\Document\GTM\pygtm\numba_bug.py", line 23, in <module>
    bug_func()
SystemError: CPUDispatcher(<function bug_func at 0x0000023B99817490>) returned a result with an exception set
```


However, if the `parallel` is set to False, there is no error:

```python
@njit(parallel=False)
def bug_func():
    n_cols = 10
    n_rows = 1

    for _ in prange(10):
        matrix = np.zeros((n_rows, n_cols))
        vector = np.zeros((n_rows,))

        # This line cause the process terminated unexpectedly. This should be the bug of numba.
        vector_ = vector[:, np.newaxis]

        value = matrix - vector_

    return value


if __name__ == '__main__':
    bug_func()

```
user: 46319943
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_9316: state: open
title: Make Cache Invalidation Work per Function Instead of per File
body: TLDR: A caching issue and potential solution.

Something that is quite annoying is that if you edit anything in a source file every function decorated with @njit(cache=True) will have its cache invalidated, causing all of those functions to recompile. In a large project this can significantly slow down development since you need to wait several seconds or even minutes after every edit. It would be nice if only the functions effected by an edit needed to recompile. I'm especially worried about this issue becoming even more difficult in the near future after this PR (#8396) is implemented which will makes it so that cache invalidations cascades through dependencies. This is an important feature, although I selfishly worry that when this is incorporated nearly my entire project is going to need to unnecessarily recompile every time I tweak a file with any functions used heavily elsewhere in the project, even if the implementation of those dependencies are left unchanged. 

I'm hoping to open up a discussion about how this issue could be addressed and offer a prototype solution. A big part of why this issue is hard is that function definitions are not self-contained in their bodies, they can leverage constants and other functions which are in a function's `__global__` scope and `__closure__`. The current solution of timestamping files seems more straightforward than checking the whole `__global__` dict for each function. But why not instead just check the elements of `__global__`  which are referenced in the function, i.e. the elements which overlap with `func.__code__.co_names`. 

Below is a monkey patched solution along these lines. The function is stamped by a hash of its `func.__code__.co_code`, and the subset of  it's `__globals__` dict which is explicitly referenced in the function body.

```python
import cloudpickle
from numba.core.caching import Cache, _SourceFileBackedLocatorMixin, _CacheLocator, _UserProvidedCacheLocator, CompileResultCacheImpl
from numba.core.dispatcher import Dispatcher
from numba import njit
from numba import config
import os
import types as py_types
import functools
from copy import copy
import hashlib

import time
class PrintElapse():
    def __init__(self, name):
        self.name = name
    def __enter__(self):
        self.t0 = time.time_ns()/float(1e6)
    def __exit__(self,*args):
        self.t1 = time.time_ns()/float(1e6)
        print(f'{self.name}: {self.t1-self.t0:.6f} ms') 

class _PreciseCacheLocator(_UserProvidedCacheLocator):
    def __init__(self, py_func, py_file):
        self._py_func = py_func
        cache_subpath = self.get_suitable_cache_subpath(py_file)
        self._cache_path = os.path.join(config.CACHE_DIR, cache_subpath)

        with PrintElapse("hashing time"):
            code =  self._py_func.__code__
            glbs = self._py_func.__globals__

            # Get __globals__ referenced in the function body
            _vars = code.co_names
            used_globals = {k:glbs[k] for k in _vars if k in glbs}

            # Hash the function bytecode and subset of globals
            func_bytes = code.co_code + cloudpickle.dumps(used_globals)
            self._func_hash = hashlib.sha256(func_bytes).hexdigest()
    
    def get_source_stamp(self):
        return self._func_hash

    def get_disambiguator(self):
        return self._func_hash[:10]

    @classmethod
    def from_function(cls, py_func, py_file):
        # if not config.CACHE_DIR:
        #     return
        self = cls(py_func, py_file)
        return self
        

class PreciseCacheImpl(CompileResultCacheImpl):
    _locator_classes = [
        _PreciseCacheLocator,
        *CompileResultCacheImpl._locator_classes
    ] 

class PreciseCache(Cache):
    """
    Implements Cache that saves and loads CompileResult objects.
    """
    _impl_class = PreciseCacheImpl


# Monkey Patch Dispatcher
def enable_caching(self):
    self._cache = PreciseCache(self.py_func)
Dispatcher.enable_caching = enable_caching
```
We can then execute something like this
```python
GLOBAL_VAL1 = 1
GLOBAL_VAL2 = 2
GLOBAL_VAL3 = 3

@njit(cache=True)
def foo():
    return GLOBAL_VAL1

@njit(cache=True)
def bar():
    return GLOBAL_VAL2

def gen_baz():
    x = GLOBAL_VAL3+0    
    @njit(cache=True)
    def baz():
        return x
    return baz

baz = gen_baz()
print(foo(), bar(), baz())
print("FOO", "HIT" if len(foo._cache_misses) == 0 else "MISS")
print("BAR", "HIT" if len(bar._cache_misses) == 0 else "MISS")
print("BAZ", "HIT" if len(baz._cache_misses) == 0 else "MISS")
```
on the first run the cache misses as expected, and a quick timing of the hashing parts show that this method seems fast enough to be a viable solution.
```
hashing time: 0.034180 ms
hashing time: 0.012939 ms
hashing time: 0.006592 ms
1 2 3
FOO MISS
BAR MISS
BAZ MISS
```
Subsequent runs without any edits hit
```
...
1 2 3
FOO HIT
BAR HIT
BAZ HIT
```
And if I change any of the  `GLOBAL_VAL` values then only the functions that depends on those globals will recompile.  This seems to work (at least in this example) even if the jitted function was  produced in a closure.
```python
GLOBAL_VAL1 = 7
GLOBAL_VAL2 = 2
GLOBAL_VAL3 = 8
```
```
7 2 8
FOO MISS
BAR HIT
BAZ MISS
```
I'm curious if something like this has been explored already. Does this seem like it would work in general or am I missing something. Forgive me if I overlooked something in a prior discussion along these lines. 

Other affiliated issues/people: #9304 @luk-f-a @stuartarchibald 


user: DannyWeitekamp
labels: discussion: An issue requiring discussion
caching: Issue involving caching
issue_9313: state: open
title: add ufunc.reduceat support
body: This PR adds support for `ufunc.reduceat` method inside `@jit` decorator.

Needs the following PRs to be merged first:
* https://github.com/numba/numba/pull/9297
* https://github.com/numba/numba/pull/9296
* https://github.com/numba/numba/pull/9295
user: guilhermeleobas
issue_9312: state: open
title: numba-generated files not removed by pip uninstall
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Found using [MNE-Python](https://github.com/mne-tools/mne-python/blob/5ae31b6ca7275a03332eef0c23b5d2cee68c3c42/mne/utils/numerics.py#L1119-L1124) though I suspect it affects other projects, too, since I don't think we do anything too fancy. If you:

1. Install with `pip install mne`:
    
    <details>

    ```
    $ pip install mne
    Collecting mne
      Using cached mne-1.6.0-py3-none-any.whl.metadata (13 kB)
    ...
    Successfully installed mne-1.6.0
    ```

    </details>

3. Run a `@numba.jit`ted function:

    <details>

    ```
    >>> import mne
    >>> mne.utils._arange_div(0, 1)
    array([], dtype=float64)
    >>> exit()
    ```

    </details>

4. Uninstall with `pip uninstall mne`:

    <details>

    ```
    $ pip uninstall mne
    Found existing installation: mne 1.6.0
    Uninstalling mne-1.6.0:
      Would remove:
        /home/larsoner/python/virtualenvs/base/bin/mne
        /home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne-1.6.0.dist-info/*
        /home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne/*
      Would not remove (might be manually added):
        /home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne/utils/__pycache__/numerics._arange_div-1119.py311.1.nbc
        /home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne/utils/__pycache__/numerics._arange_div-1119.py311.nbi
    Proceed (Y/n)? y
      Successfully uninstalled mne-1.6.0
    ```

    </details>

5. Some get left behind, as `pip uninstall mne` told us above:

    <details>

    ```
    $ ls -R ~/python/virtualenvs/base/lib/python3.11/site-packages/mne
    /home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne:
    utils

    /home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne/utils:
    __pycache__

    /home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne/utils/__pycache__:
    numerics._arange_div-1119.py311.1.nbc  numerics._arange_div-1119.py311.nbi
    ```

    </details>

6. The "uninstalled" package has become a "namespace package" / `_NamespacePath` (mostly documenting this to help others who might run into the same problem find it via search) so `import x` doesn't raise `ModuleNotFoundError` but the package is useless:

    ```
    >>> import mne
    >>> mne
    <module 'mne' (<_frozen_importlib_external.NamespaceLoader object at 0x7f6fa98430d0>)>
    >>> mne.__path__
    _NamespacePath(['/home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/mne'])
    ```

This can be worked around by manually removing these files, but this is difficult to notice and diagnose for even advanced users. I imagine most people don't see this because if you `pip install mne` again, things will work. However, if you do an *editable* install of MNE (`pip install -e .` within the checked out repo), they don't always -- sometimes (e.g., when using entry points) the broken/old `site-packages` `mne/` directory will be imported, and others the editable install will be imported.

I tried searching and didn't find people pointing out this issue. We use `setuptools` in MNE-Python, perhaps we need to configure something there to tell `pip uninstall mne` to remove additional files / filename patterns, e.g. in `__pycache__` folders with specific extensions? If so, could this be documented in the User Guide, maybe under a section for "using within a distributed project" heading or so?

It's possible `pip` has some command-line option for forcing removal of these extra files, but I don't think that's a satisfactory solution since `pip install x` / `pip uninstall x` is such a standard round-trip set of commands, people will expect it to "just work" and when it doesn't, the namespace package stuff makes it hard to get to thinking "maybe a better `pip` command-line switch would fix this".
user: larsoner
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_9311: state: open
title: Add PR number and RST validation to towncrier workflow
body: Capturing the outcome from discussion at the Numba triage/public meeting on 2023-11-29.

In reviewing #9240 it transpired that it is possible to create a towncrier "news snippet" that has a filename that does not correspond to the PR against which the snippet applies. This results in strange problems where the release notes refer to references that don't exist. Also, following a number of reviews, it seems quite common for PR authors to make minor errors in the RST formatting when writing the snippet, this is not caught until towncrier attempts to render the snippet as release notes are created.

As a result, it was decided that the GHA workflow needs to run an RST validator against the snippet and in the command that runs the validator it should ensure that variable substitution takes place to make sure the PR number is in the name of the file to be validated.
user: stuartarchibald
labels: bug - documentation incorrect: documentation is incorrect or missing something important
bug - build/packaging: Bugs: issue with building or packaging Numba
issue_9306: state: open
title: Charseq to charseq cast
body: closes #9305 

Implements conversions/casts from CharSeq to CharSeq, to support assignment from numpy byte-string arrays. (e.g., np.array(["x", "y"], dtype="S")).

The  numpy.bytes_ type seems to be implemented with a signed int32 - `np.dtype(f"S{2**31}")` wraps around (this actually returns an un-instantiable `dtype('S-2147483648')`). Thus in the lowering code, we use an ir.IntType(32) for the count size.

The lowering code is mostly inspired by the `bytes_to_charseq` function above it on L169.
user: drewmoore27
labels: 4 - Waiting on author: Waiting for author to respond to review
issue_9305: state: open
title: Support Safe/Unsafe casts between `CharSeq` types.
body: ## Overview

A char-sequence type should support conversion to another char-sequence type. It should be a safe conversion if the target's sequence count is larger or equal to the source's, otherwise it should be unsafe.

## Proposed implementation

- Add conversion rules to the [`CharSeq` type](https://github.com/numba/numba/blob/a4664180ddc91e4c8a37dd06324f4e229a76df91/numba/core/types/npytypes.py#L30)
- Implement `lower_cast` for charseq->charseq [here](https://github.com/numba/numba/blob/a4664180ddc91e4c8a37dd06324f4e229a76df91/numba/cpython/charseq.py#L220)


## Code Snippet

```

import numba as nb
import numpy as np

src = np.array(["this", "that"], dtype="S4")
dst = np.empty(2, dtype="S8")

@nb.njit
def assign_string_arr(src, dst):
    for i in range(len(src)):
        dst[i] = src[i]
    
assign_string_arr(src, dst)
dst
```

results in a typing error:
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function setitem>) found for signature:
 
 >>> setitem(array([char x 8], 1d, C), int64, [char x 4])
 
There are 16 candidate implementations:
    - Of which 16 did not match due to:
    Overload of function 'setitem': File: <numerous>: Line N/A.
      With argument(s): '(array([char x 8], 1d, C), int64, [char x 4])':
     No match.
```






user: drewmoore27
issue_9304: state: open
title: Add configurable cache idempotency key
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request
Currently the following limitations for caching are stated in the docs:  

> Cache invalidation fails to recognize changes in symbols defined in a different file.
Global variables are treated as constants. The cache will remember the value of the global variable at compilation time. On cache load, the cached function will not rebind to the new value of the global variable.

I suggest adding a variable on `njit`/`jit` called `cache_indempocy_key` and with a matching env var `NUMBA_CACHE_IDEMPOTENCY_KEY` which could be used to invalidate the cache "manually". 

This would be very useful as a library developer where you then change the key between release(maybe to package version), or if your code was running inside a Docker container with persistent storage where you then change the env var . 
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
user: thomasfrederikhoeck
issue_9297: state: open
title: Add axis support to np.take
body: Non-scientific script to measure time:

```python
import time
from numba import njit
import numpy as np

@njit
def foo(a, indices, axis):
    return np.take(a, indices, axis)


def measure_time(fn, *args):
    start = time.time()
    fn(*args)
    end = time.time()
    print(f'{fn.__name__}: {end - start}s')



# N = 100
N = 10 ** 9
shape = (10,) * int(np.log10(N))
a = np.arange(N).reshape(shape)
indices = (1, 0, 2)
axis=0
foo(a, indices, axis)
measure_time(foo.py_func, a, indices, axis)
measure_time(foo, a, indices, axis)
```
user: guilhermeleobas
labels: Effort - medium: Medium size effort needed
issue_9295: state: open
title: Improve reorderable ufunc support
body: Improve reorderable ufunc support (#9283) and add NumPy ufunc.reduce tests.
user: guilhermeleobas
labels: Effort - medium: Medium size effort needed
issue_9293: state: open
title: Using CUDA shared memory does not appear to work.
body: This appears to be the only documentation that I can find on how to share the same CUDA memory block between 2 or more
Linux processes. (https://numba.readthedocs.io/en/stable/cuda/ipc.html)

Although I can do something like 
        for cid in range(gpus):
            cuda.select_device(cid)                    # bind device to thread
            dct[cid] = pickle.dumps(cuda.to_device(np.ascontiguousarray(data[0: M,  cid * PARTN: cid * PARTN + PARTN])).get_ipc_handle())

I am unable to create an array over the same memory block in another process like.

    gpus = len(cuda.list_devices())
    PARTN = N//gpus
    for cid in range(gpus):
        cuda.select_device(cid)                    # bind device to thread
        device = cuda.get_current_device()         # get current device
        try:
            with dct[cid] as ipc_array:
                d_data[cid] = cuda.open_ipc_array(ipc_array, shape=(M, PARTN), dtype=float32)
                #print(d_data[cid].copy_to_host()[:10,:10])
        except Exception as e:
            print(f"thread/process ids, cid = {cid}, i = {i}, {e}")

I get an exception. I have also tried to process "ipc_array" through pickle.loads(ipc_array) without more success.

Since the documentation is really bad, it is not clear what is going on.


user: phalexo
labels: CUDA: CUDA related issue/PR
issue_9291: state: open
title: [Task]  Tests failures from Python 3.11 in continuation with Python 3.12
body: Following are a list of tests that fail both on 3.11 and 3.12 are are still awaiting a fix.

- `test_exceptions.py::TestRaising::test_dynamic_raise`
- `test_try_except.py::TestTryExceptOtherControlFlow::test_objmode`
- `test_try_except.py::TestTryExceptOtherControlFlow::test_objmode_output_type`
- `test_withlifting.py::TestLiftCall::test_liftcall5`
- `test_withlifting.py::TestLiftObj::test_case19_recursion`

This issue page tracks the current status of these test failures along with discussions pertaining to their respective solution.
user: kc611
labels: 3.12: Python 3.12 related
issue_9289: state: open
title: [Python 3.12] [Task] Profiler test failures due to Python 3.12 bytecode changes. 
body: Due to Python 3.12 changes the profiler test: `test_profiler.py::TestProfiler::test_profiler` now fails. The fix for this could not be accommodated in https://github.com/numba/numba/pull/9246 (Python 3.12 support update PR) due to technical constraints. 

This issue now tracks the respective test failure and discussions pertaining to it's possible solution. 
user: kc611
labels: 3.12: Python 3.12 related
issue_9286: state: open
title: Bug: using constructor in jitclass causes copy list of instances to fail
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

When a jitclass includes a constructor call, copying a list of that jitclass type fails. For reference, code includes a similar jitclass without reference to constructor to show working in this case.

```py
import numpy as np
import numba as nb  # type: ignore

import numpy as np
import numba as nb  # type: ignore

@nb.experimental.jitclass([('x', nb.int32)])  # type: ignore
class Foo:
    def __init__(self, x: np.int32):
        self.x = x

foo = Foo(np.int32(1))

foo_list = nb.typed.List.empty_list(  # type: ignore
    Foo.class_type.instance_type  # type: ignore
)
foo_list.copy()  # works


@nb.experimental.jitclass([('x', nb.int32)])  # type: ignore
class Foo2:
    def __init__(self, x: np.int32):
        self.x = x

    def copy(self):
        return Foo2(self.x)

foo = Foo2(np.int32(1))
foo.copy()  # works

foo2_list = nb.typed.List.empty_list(  # type: ignore
    Foo2.class_type.instance_type  # type: ignore
)
foo2_list.copy()  # fails!
```

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<details>
<summary>Error:</summary>
/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/utils.py:213: NumbaPendingDeprecationWarning: Code using Numba extension API maybe depending on 'old_style' error-capturing, which is deprecated and will be replaced by 'new_style' in a future release. See details at https://numba.readthedocs.io/en/latest/reference/deprecation.html#deprecation-of-old-style-numba-captured-errors
Exception origin:
  File "/home/shauncutts/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/serialize.py", line 177, in _no_pickle
    raise pickle.PicklingError(f"Pickling of {type(obj)} is unsupported")

  warnings.warn(msg,
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/pythonapi.py:1410, in PythonAPI.serialize_object(self, obj)
   1409 try:
-> 1410     gv = self.module.__serialized[obj]
   1411 except KeyError:

KeyError: ListType(instance.jitclass.Foo2#7f9f62dc2550<x:int32>)

During handling of the above exception, another exception occurred:

PicklingError                             Traceback (most recent call last)
Cell In[13], line 34
     29 foo.copy()  # works
     31 foo2_list = nb.typed.List.empty_list(  # type: ignore
     32     Foo2.class_type.instance_type  # type: ignore
     33 )
---> 34 foo2_list.copy()  # fails!

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/typed/typedlist.py:413, in List.copy(self)
    412 def copy(self):
--> 413     return _copy(self)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:487, in _DispatcherBase._compile_for_args(self, *args, **kws)
    485             e.patch_message('\n'.join((str(e).rstrip(), help_msg)))
    486     # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 487     raise e
    488 finally:
    489     self._types_active_call = []

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:420, in _DispatcherBase._compile_for_args(self, *args, **kws)
    418 return_val = None
    419 try:
--> 420     return_val = self.compile(tuple(argtypes))
    421 except errors.ForceLiteralArg as e:
    422     # Received request for compiler re-entry with the list of arguments
    423     # indicated by e.requested_args.
    424     # First, check if any of these args are already Literal-ized
    425     already_lit_pos = [i for i in e.requested_args
    426                        if isinstance(args[i], types.Literal)]

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:965, in Dispatcher.compile(self, sig)
    963 with ev.trigger_event("numba:compile", data=ev_details):
    964     try:
--> 965         cres = self._compiler.compile(args, return_type)
    966     except errors.ForceLiteralArg as e:
    967         def folded(args, kws):

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:125, in _FunctionCompiler.compile(self, args, return_type)
    124 def compile(self, args, return_type):
--> 125     status, retval = self._compile_cached(args, return_type)
    126     if status:
    127         return retval

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:139, in _FunctionCompiler._compile_cached(self, args, return_type)
    136     pass
    138 try:
--> 139     retval = self._compile_core(args, return_type)
    140 except errors.TypingError as e:
    141     self._failed_cache[key] = e

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py:152, in _FunctionCompiler._compile_core(self, args, return_type)
    149 flags = self._customize_flags(flags)
    151 impl = self._get_implementation(args, {})
--> 152 cres = compiler.compile_extra(self.targetdescr.typing_context,
    153                               self.targetdescr.target_context,
    154                               impl,
    155                               args=args, return_type=return_type,
    156                               flags=flags, locals=self.locals,
    157                               pipeline_class=self.pipeline_class)
    158 # Check typing error if object mode is used
    159 if cres.typing_error is not None and not flags.enable_pyobject:

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py:770, in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    746 """Compiler entry point
    747 
    748 Parameter
   (...)
    766     compiler pipeline
    767 """
    768 pipeline = pipeline_class(typingctx, targetctx, library,
    769                           args, return_type, flags, locals)
--> 770 return pipeline.compile_extra(func)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py:461, in CompilerBase.compile_extra(self, func)
    459 self.state.lifted = ()
    460 self.state.lifted_from = None
--> 461 return self._compile_bytecode()

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py:529, in CompilerBase._compile_bytecode(self)
    525 """
    526 Populate and run pipeline for bytecode input
    527 """
    528 assert self.state.func_ir is None
--> 529 return self._compile_core()

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py:508, in CompilerBase._compile_core(self)
    506         self.state.status.fail_reason = e
    507         if is_final_pipeline:
--> 508             raise e
    509 else:
    510     raise CompilerError("All available pipelines exhausted")

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler.py:495, in CompilerBase._compile_core(self)
    493 res = None
    494 try:
--> 495     pm.run(self.state)
    496     if self.state.cr is not None:
    497         break

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py:368, in PassManager.run(self, state)
    365 msg = "Failed in %s mode pipeline (step: %s)" % \
    366     (self.pipeline_name, pass_desc)
    367 patched_exception = self._patch_error(msg, e)
--> 368 raise patched_exception

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py:356, in PassManager.run(self, state)
    354 pass_inst = _pass_registry.get(pss).pass_inst
    355 if isinstance(pass_inst, CompilerPass):
--> 356     self._runPass(idx, pass_inst, state)
    357 else:
    358     raise BaseException("Legacy pass in use")

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_lock.py:35, in _CompilerLock.__call__.<locals>._acquire_compile_lock(*args, **kwargs)
     32 @functools.wraps(func)
     33 def _acquire_compile_lock(*args, **kwargs):
     34     with self:
---> 35         return func(*args, **kwargs)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py:311, in PassManager._runPass(self, index, pss, internal_state)
    309     mutated |= check(pss.run_initialization, internal_state)
    310 with SimpleTimer() as pass_time:
--> 311     mutated |= check(pss.run_pass, internal_state)
    312 with SimpleTimer() as finalize_time:
    313     mutated |= check(pss.run_finalizer, internal_state)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/compiler_machinery.py:273, in PassManager._runPass.<locals>.check(func, compiler_state)
    272 def check(func, compiler_state):
--> 273     mangled = func(compiler_state)
    274     if mangled not in (True, False):
    275         msg = ("CompilerPass implementations should return True/False. "
    276                "CompilerPass with name '%s' did not.")

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/typed_passes.py:468, in BaseNativeLowering.run_pass(self, state)
    466 lower.lower()
    467 if not flags.no_cpython_wrapper:
--> 468     lower.create_cpython_wrapper(flags.release_gil)
    470 if not flags.no_cfunc_wrapper:
    471     # skip cfunc wrapper generation if unsupported
    472     # argument or return types are used
    473     for t in state.args:

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/lowering.py:297, in BaseLower.create_cpython_wrapper(self, release_gil)
    292 if self.genlower:
    293     self.context.create_cpython_wrapper(self.library,
    294                                         self.genlower.gendesc,
    295                                         self.env, self.call_helper,
    296                                         release_gil=release_gil)
--> 297 self.context.create_cpython_wrapper(self.library, self.fndesc,
    298                                     self.env, self.call_helper,
    299                                     release_gil=release_gil)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/cpu.py:190, in CPUContext.create_cpython_wrapper(self, library, fndesc, env, call_helper, release_gil)
    185 wrapper_callee = ir.Function(wrapper_module, fnty,
    186                              fndesc.llvm_func_name)
    187 builder = PyCallWrapper(self, wrapper_module, wrapper_callee,
    188                         fndesc, env, call_helper=call_helper,
    189                         release_gil=release_gil)
--> 190 builder.build()
    191 library.add_ir_module(wrapper_module)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/callwrapper.py:122, in PyCallWrapper.build(self)
    119 kws.name = 'py_kws'
    121 api = self.context.get_python_api(builder)
--> 122 self.build_wrapper(api, builder, closure, args, kws)
    124 return wrapper, api

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/callwrapper.py:190, in PyCallWrapper.build_wrapper(self, api, builder, closure, args, kws)
    187         api.return_none()
    189     retty = self._simplified_return_type()
--> 190     obj = api.from_native_return(retty, retval, env_manager)
    191     builder.ret(obj)
    193 # Error out

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/pythonapi.py:1437, in PythonAPI.from_native_return(self, typ, val, env_manager)
   1433 def from_native_return(self, typ, val, env_manager):
   1434     assert not isinstance(typ, types.Optional), "callconv should have " \
   1435                                                 "prevented the return of " \
   1436                                                 "optional value"
-> 1437     out = self.from_native_value(typ, val, env_manager)
   1438     return out

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/pythonapi.py:1451, in PythonAPI.from_native_value(self, typ, val, env_manager)
   1448 impl = _boxers.lookup(typ.__class__, box_unsupported)
   1450 c = _BoxContext(self.context, self.builder, self, env_manager)
-> 1451 return impl(typ, val, c)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/typed/typedlist.py:477, in box_lsttype(typ, val, c)
    474 typedlist_mod = c.pyapi.import_module_noblock(modname)
    475 fmp_fn = c.pyapi.object_getattr_string(typedlist_mod, '_from_meminfo_ptr')
--> 477 lsttype_obj = c.pyapi.unserialize(c.pyapi.serialize_object(typ))
    479 result_var = builder.alloca(c.pyapi.pyobj)
    480 builder.store(cgutils.get_null_value(c.pyapi.pyobj), result_var)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/pythonapi.py:1412, in PythonAPI.serialize_object(self, obj)
   1410     gv = self.module.__serialized[obj]
   1411 except KeyError:
-> 1412     struct = self.serialize_uncached(obj)
   1413     name = ".const.picklebuf.%s" % (id(obj) if config.DIFF_IR == 0 else "DIFF_IR")
   1414     gv = self.context.insert_unique_const(self.module, name, struct)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/pythonapi.py:1380, in PythonAPI.serialize_uncached(self, obj)
   1374 """
   1375 Same as serialize_object(), but don't create a global variable,
   1376 simply return a literal for structure:
   1377 {i8* data, i32 length, i8* hashbuf, i8* func_ptr, i32 alloc_flag}
   1378 """
   1379 # First make the array constant
-> 1380 data = serialize.dumps(obj)
   1381 assert len(data) < 2**31
   1382 name = ".const.pickledata.%s" % (id(obj) if config.DIFF_IR == 0 else "DIFF_IR")

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/serialize.py:58, in dumps(obj)
     56 with io.BytesIO() as buf:
     57     p = pickler(buf, protocol=4)
---> 58     p.dump(obj)
     59     pickled = buf.getvalue()
     61 return pickled

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/cloudpickle/cloudpickle_fast.py:637, in CloudPickler.dump(self, obj)
    635 def dump(self, obj):
    636     try:
--> 637         return Pickler.dump(self, obj)
    638     except RuntimeError as e:
    639         if "recursion" in e.args[0]:

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/serialize.py:196, in NumbaPickler.reducer_override(self, obj)
    193 def reducer_override(self, obj):
    194     # Overridden to disable pickling of certain types
    195     if type(obj) in self.disabled_types:
--> 196         _no_pickle(obj)  # noreturn
    197     return super().reducer_override(obj)

File ~/.cache/pypoetry/virtualenvs/ingolstadt-EH7L9v-Y-py3.11/lib/python3.11/site-packages/numba/core/serialize.py:177, in _no_pickle(obj)
    176 def _no_pickle(obj):
--> 177     raise pickle.PicklingError(f"Pickling of {type(obj)} is unsupported")

PicklingError: Failed in nopython mode pipeline (step: native lowering)
Pickling of <class 'numba.experimental.jitclass.base.JitClassType'> is unsupported
</details>

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: shaunc
issue_9285: state: open
title: bug: identity of objects in typed lists not preserved
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

When adding an object to a list, I expect to get the same object back when I reference it in the list. However, numba type list seems to return a copy of the object instead.

```py
import numpy as np
import numba as nb  # type: ignore

@nb.experimental.jitclass([('x', nb.int32)])  # type: ignore
class Foo:
    def __init__(self, x: np.int32):
        self.x = x

    def __eq__(self, __value: object) -> bool:
        return isinstance(__value, Foo) and self.x == __value.x

FooType = Foo.class_type.instance_type  # type: ignore

foo = Foo(np.int32(1))

foo_list = [foo]
print(foo_list[0] is foo)  # True
foo_typed_list: list[Foo] = nb.typed.List.empty_list(FooType)  
foo_typed_list.append(foo)
print(foo_typed_list[0] == foo)  # True
print(foo_typed_list[0] is foo)  # False??
# expected True

```
## NOTE

This isn't just a jitclass problem. The following also fails:

```py

a = np.zeros(1, dtype={"names": ["x"], "formats": [np.int32]})

bar_list = nb.typed.List.empty_list(nb.typeof(a[0]))

bar_list.append(a[0])
print(bar_list[0] is a[0])  # False, expected True
```

user: shaunc
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_9283: state: open
title: Identityless reduction fails to compile when axis is a tuple
body: edit: This problem is more fundamental in how Numba integrates with NumPy and how NumPy determines if a ufunc is reorderable or not.


### Questions
1) What characterizes a reorderable ufunc?
A ufunc is considered reorderable if its inputs can be rearranged without altering the final result. For example, np.add is a reorderable ufunc, whereas np.remainder and np.power are examples of non-reorderable ufuncs.

2) How does NumPy determine the reorderability of a ufunc?
NumPy checks if a ufunc is reorderable by checking if `PyUfunc_GetDefaultOrIdentity` sets the reorderable flag to true. This occurs when the ufunc's identity type is not PyUfunc_None.

3) Does setting the ufunc identity to None imply the identity type is `PyUfunc_None`?
No. ([Reference](https://numpy.org/doc/stable/reference/generated/numpy.frompyfunc.html))

4) What about Numba ufuncs?
Numba calls `PyUFunc_FromFuncAndData` which sets the identity to the value given by the identity keyword arg. If no value is given, the identity is set to `PyUfunc_None`. Is this correct? Probably not as per Q3.

5) Why is the reorderability of ufuncs important?
Reorderable ufuncs permit reduction over multiple axes, while non-reorderable ones can accept at most a single axis. 

Example:
```python
>>> import numpy as np
>>> a = np.arange(40).reshape(5, 4, 2)
>>> >>> np.add.reduce(a, axis=(0, 1))
array([380, 400])
>>> np.remainder.reduce(a)
array([[0, 1],
       [2, 3],
       [4, 5],
       [6, 7]])
>>> np.remainder.reduce(a, axis=(0, 1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: reduction operation 'remainder' is not reorderable, so at most one axis may be specified
```

With that said, should the code below works?

```python
from numba import njit, vectorize
import numpy as np

@vectorize
def pymin(a, b):
    return np.minimum(a, b)

@njit
def foo(a):
    return pymin.reduce(a, axis=(0, 1))

a = np.arange(40).reshape(5, 4, 2)
print(foo(a))
```

Would an extra flag to `vectorize(reorderable=True)` flag be acceptable?
user: guilhermeleobas
labels: bug - failure to compile: Bugs: failed to compile valid code
bug - incorrect behavior: Bugs: incorrect behavior
issue_9281: state: open
title: Add option to `nb.njit` to suppress performance warning
body: ## Feature request

Apologies if this alredy exists and I couldn't find it, but I would like some way of suppressing Numba warnings when we're jit-compiling code.

For instance, I have some code that effectively does `lambda a, b: np.einsum("ijk,ji->k", a, b)` that is currently implemented as:
```python
@nb.njit
def f(a, b):
    out = np.zeros(a.shape[-1], dtype=np.float64)
    for i in range(len(out)):
        out += a[i].T @ data[:, i]
    return out
```

which automatically gives me a `NumbaPerformanceWarning: '@' is faster on contiguous arrays`. I want some way of *not* emitting such a performance warning, hopefully by modifying the code (e.g. `nb.njit(warnings="suppress")` or something. I *know* that there is a non-contiguous array here, but it's fast enough and I haven't found an obviously faster way of doing this so the warning is not helpful.

I know that I can do this by adding a `warning.warn` suppression at the *callsite* of `f`, but it's super easy to forget. Being able to configure this at the function definition would be super useful!

user: alanhdu
issue_9277: state: open
title: numba does not handle assignment expressions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
I didn't find any relation to [PEP 572](https://peps.python.org/pep-0572/) in doc chapter [Supported Python features](https://numba.readthedocs.io/en/stable/reference/pysupported.html#) but it seems that assigment expressions are not recognized by numba.

Just a dummy example:
```
# Win 10, Python 3.11.4
from numba import njit, jit

@njit
def test_(inp):
    return [(x := inp - inp.size//2), x**2]

a = np.arange(10)
print(test_(a))
```
output **njit**:
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Type of variable '$40build_list.9' cannot be determined, operation: build_list(items=[Var($binop_sub24.5, 3118119150.py:5), Var($binop_pow36.8, 3118119150.py:5)]), location: [C:\Users\Zizo6\AppData\Local\Temp\ipykernel_17384\3118119150.py](file:///C:/Users/Zizo6/AppData/Local/Temp/ipykernel_17384/3118119150.py) (5)

File "..\..\..\AppData\Local\Temp\ipykernel_17384\3118119150.py", line 5:
<source missing, REPL/exec in use?>
```
output **jit**:
```
AssertionError: Failed in object mode pipeline (step: object mode backend)
$binop_sub24.5
```

output w/o njit:
`[array([-5, -4, -3, -2, -1,  0,  1,  2,  3,  4]), array([25, 16,  9,  4,  1,  0,  1,  4,  9, 16])]`

user: TsiVit
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9276: state: open
title: Calling print() from nopython corrupts dictionary
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

This code prints the wrong length of the given dictionary:
```python3
from numba import njit
from numba.core import types
from numba.typed import Dict


@njit
def f():
    d = Dict.empty(
        key_type=types.int64,
        value_type=types.int64,
    )
    print(d)
    return len(d)


print(f())
```

I get randomish output, e.g.:
```
{}
270492416740624
```

If you replace `print(d)` with
```python3
    with numba.objmode():
        print(d)
```

then it works as expected.

user: philiptromans
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_9274: state: open
title: CUDA: Add support for compilation to LTO-IR
body: This adds support for compiling to LTO-IR, providing an alternative route to using PTX for linking code with non-Python source code with greater potential for optimization from being able to optimize at link-time across the whole body of source for different languages.

A summary of the changes:

- The first three commits are small refactors / tidy-ups of some paths that could be simplified now we don't have to deal with NVVM 3.4 anymore (556bb82677e24f3e7ded68e4c80503a054203e09, b6c3b85d7576a0ec2a0c4d0811277d4fd7f45b57, 6d8a22ce0e84156ed2066d53c89f434822b55191)
- The next commit clarifies the compilation behaviour with / without return types being specified, which was a bit of a hole in the documentation: 357d67d8969969b97be6e6d86f9151f7ed4ec686
- Then we add support for LTO-IR to to CUDA codegen, without exposing it externally: 8d6fd900e25b53ca5642a2c8b43a26da19ab17ac
- Then we add a public interface for LTO-IR code generation: ed99b9ec687639c3eef78783cec6965e16e36dfa
- Documentation is also added / updated: 0938da4a0d4d213ffca2ab2f81de47b1951c0a1b
user: gmarkall
labels: CUDA: CUDA related issue/PR
Effort - medium: Medium size effort needed
issue_9271: state: open
title: Add a conda-forge as a test during pre-tag testing
body: During the next release (0.59.0) -- run the pre-tag test (testing the commit that would be tagged as a release) through conda-forge.

See also: https://github.com/numba/numba/wiki/Minutes_2023_10_24#0-discussion
user: esc
issue_9270: state: open
title: Add CI tests targeting glibc=2.17
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
We recently discovered a regression in NumPy's (1.26) meson-based builds under glibc=2.17 at
    - https://github.com/conda-forge/numba-feedstock/pull/128#issuecomment-1795031396

Numba's own CI tests apparently didn't catch this beforehand.
Since Anaconda Distribution as well as conda-forge currenlty target glibc 2.17/CentOS 7, it'd be good to have one or more CI jobs that run under CentOS user space, e.g., via a container-based build.
user: mbargull
issue_9269: state: open
title: `MixedContainerUnroller` pass may create variable not in scope
body: Discovered in https://github.com/numba/numba/issues/9255#issuecomment-1792530750

Add this to `build_definitions()` to detect the not defined variable:

```diff
diff --git a/numba/core/ir_utils.py b/numba/core/ir_utils.py
index a683ef781..22cec22ee 100644
--- a/numba/core/ir_utils.py
+++ b/numba/core/ir_utils.py
@@ -1581,6 +1581,17 @@ def build_definitions(blocks, definitions=None):
                 f = build_defs_extensions[type(inst)]
                 f(inst, definitions)
 
+    # Ensure
+
+    first_block = next(iter(blocks.values()))
+    scope = first_block.scope
+
+    for k in definitions:
+        try:
+            scope.get_exact(k)
+        except Exception:
+            breakpoint()
+
     return definitions
 
 build_defs_extensions = {}

            
```
user: sklam
labels: bug - miscompile: Bugs: miscompile
issue_9268: state: open
title: Numba compiled `np.dot` doesn't support type promotion of different data types
body: When calling `np.dot` with different data types e.g. `float32` and `float64` numpy would automatically promote the data types to the higher precision one according to [`np.promote_types`](https://numpy.org/doc/stable/reference/generated/numpy.promote_types.html#numpy-promote-types).

With Numba `0.58.1` this isn't the case and calling `np.dot` with different dtypes causes the following error:
```python
import numba
import numpy as np

x = np.random.normal(size=512).astype(np.float32)
y = np.random.normal(size=512).astype(np.float64)

@numba.njit
def numba_dot(x, y):
    return np.dot(x, y)

numba_dot(x, y)
```

```
Traceback (most recent call last):
  File "/private/tmp/test.py", line 11, in <module>
    numba_dot(x, y)
  File "/usr/local/lib/python3.11/site-packages/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/usr/local/lib/python3.11/site-packages/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function dot>) found for signature:

 >>> dot(array(float32, 1d, C), array(float64, 1d, C))

There are 4 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'dot_2': File: numba/np/linalg.py: Line 525.
    With argument(s): '(array(float32, 1d, C), array(float64, 1d, C))':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<intrinsic _impl>) found for signature:

    >>> _impl(array(float32, 1d, C), array(float64, 1d, C))
import numba
import numba

   There are 2 candidate implementations:
     - Of which 2 did not match due to:
     Intrinsic in function 'dot_2_impl.<locals>._impl': File: numba/np/linalg.py: Line 543.
       With argument(s): '(array(float32, 1d, C), array(float64, 1d, C))':
      Rejected as the implementation raised a specific error:
        TypingError: np.dot() arguments must all have the same dtype
     raised from /usr/local/lib/python3.11/site-packages/numba/np/linalg.py:563

   During: resolving callee type: Function(<intrinsic _impl>)
   During: typing of call at /usr/local/lib/python3.11/site-packages/numba/np/linalg.py (582)


   File "../../usr/local/lib/python3.11/site-packages/numba/np/linalg.py", line 582:
               def _dot2_codegen(context, builder, sig, args):
                   <source elided>

           return lambda left, right: _impl(left, right)
           ^

  raised from /usr/local/lib/python3.11/site-packages/numba/core/typeinfer.py:1086
  - Of which 2 did not match due to:
  Overload in function 'dot_3': File: numba/np/linalg.py: Line 784.
    With argument(s): '(array(float32, 1d, C), array(float64, 1d, C))':
   Rejected as the implementation raised a specific error:
     TypingError: missing a required argument: 'out'
  raised from /usr/local/lib/python3.11/site-packages/numba/core/typing/templates.py:784

During: resolving callee type: Function(<built-in function dot>)
During: typing of call at /private/tmp/test.py (9)


File "test.py", line 9:
def numba_dot(x, y):
    return np.dot(x, y)
    ^
```
user: lgeiger
labels: bug - documentation incorrect: documentation is incorrect or missing something important
issue_9266: state: open
title: RecursionError when sorting typed list of jitclass
body: Using `__lt__` dunder method for ordering and then attempting to sort a list of a jitclass. Compiling fails with recursion error:

```python
from numba import njit, uint32
from numba.typed import List
from numba.extending import as_numba_type
from numba.experimental import jitclass

@jitclass
class A:
	order: uint32
	def __init__(self): pass
	def __lt__(self, other):
		return self.order < other.order

AType = as_numba_type(A)

@njit
def test():
	a = List.empty_list(AType)
	a.sort()

test()
```
Python 3.11.5, Numba 0.58.1
user: Azmisov
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9265: state: open
title: Parfors not exporting variable sometimes
body: Reproducer 1:
```python
from numba import njit, set_num_threads, prange

def def_in_loop(x):
    c = x
    set_num_threads(1)
    d = 0
    for i in prange(x):
        if c:
            d = x + 4
    print(d)
    return c and d > 0

print(def_in_loop(4))
# Outs:
# 8
# True
print(njit(def_in_loop)(4))
# Outs:
# 8
# 1
print(njit(parallel=True)(def_in_loop)(4))
# Outs:
# 0
# 0
```

Reproducer 2:

```python
from numba import njit, set_num_threads, prange

def def_in_loop(x):
    c = x
    set_num_threads(1)
    for i in prange(x):
        if c:
            d = x + 4
    # print(d)  # uncomment this "fixes" it
    return c and d > 0  # changing this line to `return c, d > 0` also "fixes" it

print(def_in_loop(4))
# Outs:
# 8
# True
print(njit(def_in_loop)(4))
# 8
# 1
print(njit(parallel=True)(def_in_loop)(4))
# Outs:
# 8
# 0
```
user: sklam
labels: bug - miscompile: Bugs: miscompile
issue_9264: state: open
title: Deferred types broken for jitclass
body: Here I have reproducer with three test cases to demonstrate:

```python
from numba import deferred_type, njit
from numba.extending import as_numba_type
from numba.experimental import jitclass

test_case = 2

# works, single deferred member
if test_case == 0:
	DeferredBType = deferred_type()

	@jitclass([('b', DeferredBType)])
	class A:
		def __init__(self, b):
			self.b = b

	@jitclass
	class B:
		def __init__(self): pass
	BType = as_numba_type(B)
	DeferredBType.define(BType)

	@njit
	def test():
		b = B()
		a = A(b)

	test()

# fails, two deferred members
if test_case == 1:
	DeferredBType = deferred_type()
	DeferredCType = deferred_type()

	@jitclass([('b', DeferredBType), ('c', DeferredCType)])
	class A:
		def __init__(self, b):
			self.b = b

	@jitclass
	class B:
		def __init__(self): pass
	BType = as_numba_type(B)
	DeferredBType.define(BType)

	@jitclass
	class C:
		def __init__(self): pass
	CType = as_numba_type(C)
	DeferredCType.define(CType)

	@njit
	def test():
		b = B()
		a = A(b)

	test()

# fails, two deferred members (different error message)
if test_case == 2:
	DeferredBType = deferred_type()
	DeferredCType = deferred_type()

	@jitclass([('b', DeferredBType), ('c', DeferredCType)])
	class A:
		def __init__(self): pass

	@jitclass
	class B:
		def __init__(self): pass
	BType = as_numba_type(B)
	DeferredBType.define(BType)

	@jitclass
	class C:
		def __init__(self): pass
	CType = as_numba_type(C)
	DeferredCType.define(CType)

	@njit
	def test():
		a = A()

	test()
```

First test case is just a jitclass with a single deferred member. This works as expected

Second test case just adds a second deferred member. We get an error:

```
test.py:30: NumbaPendingDeprecationWarning: Code using Numba extension API maybe depending on 'old_style' error-capturing, which is deprecated and will be replaced by 'new_style' in a future release. See details at https://numba.readthedocs.io/en/latest/reference/deprecation.html#deprecation-of-old-style-numba-captured-errors
Exception origin:
  File "site-packages/llvmlite/binding/module.py", line 25, in parse_assembly
    raise RuntimeError("LLVM IR parsing error\n{0}".format(errmsg))

  a = A(b)
Traceback (most recent call last):
  File "test.py", line 32, in <module>
    test()
  File "site-packages/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "site-packages/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x7eff03a58e90>.
Failed in nopython mode pipeline (step: native lowering)
LLVM IR parsing error
<string>:31:105: error: base element of getelementptr must be sized
  %".17" = getelementptr inbounds {%"deferred.139634571830160.data", %"deferred.139633764192912.data"}, {%"deferred.139634571830160.data", %"deferred.139633764192912.data"}* %".16", i32 0, i32 0
                                                                                                        ^

During: resolving callee type: jitclass.A#7eff04346f10<b:DeferredType#139634571830160,c:DeferredType#139633764192912>
During: typing of call at test.py (30)

Enable logging at debug level for details.

File "test.py", line 30:
def test():
    <source elided>
        b = B()
        a = A(b)
 ^
```

Third test case is the same as the second, except we've removed A's constructor. Same structs, but we get a different error this time:
```
python: /root/miniconda3/envs/buildenv/conda-bld/llvmdev_1680545119445/work/llvm/lib/IR/DataLayout.cpp:748: llvm::Align llvm::DataLayout::getAlignment(llvm::Type*, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed.
Aborted (core dumped)
```

The third test case has a similar error message to #8404, so maybe the same underlying cause. The second test case error is different however, and this reproducer does not use typed.Dict to trigger it.

Tested on Python 3.11.5, Numba 0.58.1
user: Azmisov
labels: bug - ice: Bugs: internal compiler error
issue_9260: state: open
title: Bus error: 10 when using np.linalg.solve in numba `parallel=True`
body: We are trying to solve a simple linear system using `np.linalg.solve` within a `numba.prange` loop. Doing so fails with a `Bus error: 10`. However, the code runs fine with `parallel=False` or by replacing `np.linalg.solve` with `np.linalg.inv` (see code below).

```python3
import numba
import numpy as np

@numba.njit(parallel=True)
def bus_error():
    n = 10
    for i in numba.prange(n):
        A = np.eye(3)
        b = np.zeros((3, 1))
        # this does not work
        x = np.linalg.solve(A, b)
        # this works
        # x = np.linalg.inv(A) @ b

bus_error()
```
 
This is with Python 3.11.4, numba 0.58.1, numpy 1.25.2 and llvmlite 0.41.1.
The code above was also tested on several machines (with the same machine architecture and package versions above) and the error materializes on some but not on others, prompting us to wonder what differences in configurations could cause this failure mode.
user: fankiat
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_9259: state: open
title: Stop type inference from indefinite retry on failed function resolution
body: Fix hang seen in https://github.com/numba/numba/issues/9257

Summary of changes:
- Added a fail-cache to remember failed function resolution for the current compilation session and avoid repeated attempts of known failing cases.
- The fail-cache can be disabled by an env-var to help debug any unforeseen problem arising from this change of type inference behavior.


user: sklam
issue_9257: state: open
title: Typed Dict compiling hangs with NumPy unicode strings tuple key
body: I'm trying to use a tuple of numpy unicode types, and compiling hangs and code doesn't run. A non-tuple numpy unicode key does work however.

```python
import numpy as np
from numba import int32, njit
from numba.types import UnicodeCharSeq, Tuple
from numba.typed import Dict

KeyType = Tuple((UnicodeCharSeq(6), UnicodeCharSeq(10)))

@njit
def test(rec) -> bool:
	d = Dict.empty(key_type=KeyType, value_type=int32)
	key = (rec["a"], rec["b"])
	return key in d
	
recs = np.array([("012345","0123456789")], dtype=[("a","<U6"),("b","<U10")])
test(recs[0])
```

This is with Python 3.11.5, Numba 0.58.1

user: Azmisov
labels: bug - typing: Bugs: occuring at typing time
issue_9252: state: open
title: File output within njit
body: Hi all, I've been using numba for several physics-based applications and it is amazing. I have a feature request that I think could be quite useful (feel free to remove this request if this is not the best place). So I would like to be able to print to files within njitted functions, which is very often done for logging in numerical codes. I am aware that this is possible using the "with objmode" approach, but ideally I would not need to escape back to python intepreter if I am printing in  a loop or something. 

So, what I would like to be able to do is something like this:

```python
@njit
def f(x):
    file = open('test.txt', 'w')
    res = x * 2.0 # some computation
    file.write(f"result = {res}") 
    file.close()

``` 

I have tried hacking together something with printf in c and ctypes, but numba does not understand ctypes "c_char_p" and the file has to be reopened everytime, so this not really feasible. I also tried just redirecting numba output, but this seems to have some significant performance overhead.

Thanks very much for all the work that you all do.
user: ErolBa
issue_9251: state: open
title: Named argument parsing for jit decorated functions does not match Python 3.10
body: Numba 0.58.1 and `main` does not parse named arguments correctly when compared to Python 3.10.

Reproducer:

```python

import numba

def bar(a, b, c,*args, named_arg=None):
    print(a, b, c)
    print("Args:", args)
    print("Named_arg", named_arg)

foo = numba.jit(bar)
```

The issue manifests in at least two ways:

a) Numba parses the named argument following `*args` in the incorrect manner. 

```
foo(1, 2, 3, 4, 5)
bar(1, 2, 3, 4, 5)

# Output from foo
# 1 2 3
# Args: 4
# Named_arg 5
#
# Output from bar
# 1 2 3
# Args: (4, 5)
# Named_arg None
```
b) Raises a `TypeError` incorrectly

```python
bar(1, 2, 3, 4, 5, named_arg=6)
foo(1, 2, 3, 4, 5, named_arg=6)

# Output from bar
# 1 2 3
# Args: (4, 5)
# Named_arg 6
#
# Output from foo 
#    foo(1, 2, 3, 4, 5, named_arg=6)
# TypeError: too many arguments: expected 5, got 6

```

The issue happens due to the way arguments are parsed in the `numba.core.dispatcher` module: https://github.com/numba/numba/blob/main/numba/core/dispatcher.py#L261-L269 and then the matching of named args is done in https://github.com/numba/numba/blob/452eb5755320506de96bed83021566d0093a3d3a/numba/_dispatcher.cpp#L790


user: diptorupd
labels: bug - miscompile: Bugs: miscompile
bug - failure to compile: Bugs: failed to compile valid code
issue_9248: state: open
title: Fix automatic unwrapping of optional type
body: Alternative to #9161.

The root problem of optional typed arguments not unpacking is due to lack of exception handling around the `typer`. With the fix, we don't need to specialize individual function to handle optional types.
user: sklam
labels: 4 - Waiting on author: Waiting for author to respond to review
Effort - short: Short size effort needed
issue_9243: state: open
title: Caching causes error in structref overloading
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I've encountered a bug where caching causes an error when overloading attribute of structref in numba. When I run the following code once (without caching), it works as expected. But when I run it again (with caching enabled), it throws an error. If I disable caching, then the code always works correctly.

Here is the code to reproduce the issue:

```python
from numba import types, njit
from numba.experimental import structref
from numba.extending import overload_attribute


@structref.register
class ExampleType(types.StructRef):
    pass


class Example(structref.StructRefProxy):
    @property
    @njit
    def p(self):
        return self.p


@overload_attribute(ExampleType, 'p')
def ol_structref_getattr(self):
    return lambda self: self.x


structref.define_proxy(Example, ExampleType, ('x',))


@njit(cache=True)
def init():
    return Example(0)


print(init().p)
```

And here is the error message:

```
Traceback (most recent call last):
  File "numba_cache_property.py", line 32, in <module>
    print(init().p)
  File "\lib\site-packages\numba\core\dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "\lib\site-packages\numba\core\dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'p' of type numba.ExampleType(('x', int64),)

File "numba_cache_property.py", line 16:
    def p(self):
        return self.p
        ^

During: typing of get attribute at numba_cache_property.py (16)

File "numba_cache_property.py", line 16:
    def p(self):
        return self.p
        ^

```

Operating System: Windows 10
Python Environment: Anaconda Python 3.10.13
user: plutonium-94
labels: caching: Issue involving caching
bug - typing: Bugs: occuring at typing time
issue_9241: state: open
title: CUDA; Need to handle incorrect `CUDA_HOME` more gracefully
body:  It looks like Numba doesn't handle it very gracefully when `CUDA_HOME` is incorrectly set (see traceback in report for #9216). We can improve on the feedback to the user:

*  It would be much better if it made it clear that `CUDA_HOME` was not correct rather than giving the exception stating that NVVM is missing
* When `CUDA_HOME` is set incorrectly, the CUDA libraries test raises an exception and therefore `numba -s` prints no helpful information about the failure to detect components of the toolkit
* `CUDA_HOME` should also be included in the list of relevant environment variables affecting Numba.

cc @AromaticJ
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_9239: state: open
title: ufunc.at
body: ### List of tests copied from NumPy 

Test case | Passing | Reason
-- | -- | --
test_numpy_ufunc_at_basic | ✅ |  
test_ufunc_at_ellipsis | ✅ |  
test_ufunc_at_negative | ✅ |  
test_ufunc_at_large | ✅ |  
test_ufunc_at_inner_loop | ✅ |  
test_cast_index_fastpath | ✅ |  
test_ufunc_at_scalar_value_fastpath | ✅ |  
test_ufunc_at_multiD | ✅ |
test_ufunc_at_0D | ✅ |  
test_ufunc_at_dtypes | ✅ |  
test_ufunc_at_boolean | ✅ | 
test_ufunc_at_boolean2 | ✅ |  
test_ufunc_at_advanced | ✅ |  
test_ufunc_at_advanced_2 | ❌ | Unsupported array dtype: >f4
test_ufunc_at_advanced_3 | ❌ | Use array with dtype=object
test_ufunc_at_advanced_4 | ✅ |  
test_ufunc_at_advanced_5 | ✅ |  
test_at_negative_indexes | ✅ |  
test_at_not_none_signature | ❌ | Does not support ufunc with non-trivial signature. i.e. np.matmul
test_at_no_loop_for_op | ✅ |  
test_at_output_casting | ✅ |  
test_at_broadcast_failure | ✅ |  
 


user: guilhermeleobas
labels: 4 - Waiting on author: Waiting for author to respond to review
Effort - long: Long size effort needed
issue_9233: state: open
title: print failed in parallel=True, cache=True
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->    


Numba 0.58.0   
Python 3.10.12   

Following code should reproduce the bug. First run was fine, but in second run It stucks in function `parallel_true`. Comment print function or set `cache=False` will not produce the bug.   

```python 
import numpy as np
from numba import njit, prange

@njit(cache=True)
def parallel_false(n):
    for i in prange(n):
        x = i*np.sin(1.5)
        print('parallel_false ', i, x)

@njit(parallel=True, cache=True)
def parallel_true(n):
    for i in prange(n):
        x = i*np.sin(1.5)
        print('parallel_true ', i, x)

print('parallel_false')
parallel_false(10)
print('parallel_true')
parallel_true(10)
```

user: Dengda98
labels: caching: Issue involving caching
issue_9231: state: open
title: GitHub Actions: fix towncrier workflow to re-run on adding skip label
body: Currently the towncrier workflow will fail if the `skip_release_notes` label isn't set. It seems like there is no way to re-run this workflow after adding the label, other than to open/close it. It would be nice if the workflow was runnable after adding the `skip_release_notes` label such that we don't have to open/close the PRs anymore.
user: esc
labels: bug - build/packaging: Bugs: issue with building or packaging Numba
issue_9230: state: open
title: allow using IntEnumMember as array index
body: related with https://github.com/numba/numba/issues/7662. but fix the similar issue for np.array.
user: dlee992
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_9226: state: open
title: Update randomimpl.py to allow floating arguments to negative_binomial
body: Small change to solve issue  #9219.

user: dforero0896
labels: Effort - short: Short size effort needed
issue_9224: state: open
title: numba Generator.uniform() doesn't work with array-like inputs
body: The docs for ```numpy.random.Generator().integers()``` reports 

> "(Both low and high are required arguments. Array values for low and high are currently not supported.)"

which leads me to believe that in general, array values for inputs in Generator methods are accepted. However, the following test fails to compile:

```python
import numba as nb
import numpy as np
from numpy.random import default_rng

@nb.njit
def test(rng, low, high):
    return rng.uniform(low, high)

test(default_rng(0), np.array([0., 0., 10.]), np.array([1., 1., 11.]))
```

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
- Resolution failure for literal arguments:
No implementation of function Function(<function NumPyRandomGeneratorType_uniform at 0x7f5d3642b740>) found for signature:

 >>> NumPyRandomGeneratorType_uniform(NumPyRandomGeneratorType, array(float64, 1d, C), array(float64, 1d, C))

There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'NumPyRandomGeneratorType_uniform': File: numba/np/random/generator_methods.py: Line 371.
    With argument(s): '(NumPyRandomGeneratorType, array(float64, 1d, C), array(float64, 1d, C))':
   Rejected as the implementation raised a specific error:
     TypingError: Argument low is not one of the expected type(s): [<class 'numba.core.types.scalars.Float'>, <class 'numba.core.types.scalars.Integer'>, <class 'int'>, <class 'float'>]
  raised from [/home/ami/venvs/jax/lib/python3.11/site-packages/numba/np/random/generator_methods.py:81](https://file+.vscode-resource.vscode-cdn.net/home/ami/venvs/jax/lib/python3.11/site-packages/numba/np/random/generator_methods.py:81)

- Resolution failure for non-literal arguments:
None

During: resolving callee type: BoundFunction((<class 'numba.core.types.npytypes.NumPyRandomGeneratorType'>, 'uniform') for NumPyRandomGeneratorType)
During: typing of call at <ipython-input-29-cbf84c3815cc> (10)


File "<ipython-input-29-cbf84c3815cc>", line 10:
def test(rng, low, high):
    return rng.uniform(low, high)
```

Is this is a bug, or do the docs need to be updated? Are there any plans to support this functionality?

user: amifalk
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9219: state: open
title: Negative binomial distribution for float n
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
I was checking the `randimpl.py` file because when using `np.random.negative_binomial(n,p)` with float `n`, numba complains there is no implementation for arguments `(float64, float64)`. However, I found the implementation 
```python
@overload(np.random.negative_binomial)
def negative_binomial_impl(n, p):
    if isinstance(n, types.Integer) and isinstance(
            p,(types.Float, types.Integer)):
        def _impl(n, p):
            if n <= 0:
                raise ValueError("negative_binomial(): n <= 0")
            if p < 0.0 or p > 1.0:
                raise ValueError("negative_binomial(): p outside of [0, 1]")
            Y = np.random.gamma(n, (1.0 - p) / p)
            return np.random.poisson(Y)

        return _impl
```
I wrote this as
```python
@nb.njit(fastmath=True, cache=True)
def negative_binomial(n, p):
    assert n > 0
    assert p > 0. and p < 1.
    Y = np.random.gamma(n, (1. - p) / p)
    return np.random.poisson(Y)
```
and it seems to run without issue for `(float64, float64)` arguments. Is there a reason why numba does not support this by default? Are the results known to be wrong in this case so that integer `n` must be enforced? Is it a bug?

Thanks in advance for your help.

user: dforero0896
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_9215: state: open
title: Static method attribute missing from jitclasses inside jitted functions
body: A static method inside a jitclass can't be accessed as a class attribute inside a jitted function (outside of the class definition)
```python
import numba as nb

@nb.experimental.jitclass
class Fraction:
    numerator: int
    denominator: int

    def __init__(self, numerator, denominator):
        self.numerator = numerator
        self.denominator = denominator
  
    @staticmethod
    def from_int(val):
        return Fraction(val, 1)

@nb.jit(nopython=True)
def test():
    return Fraction.from_int(3)

test()
```

produces

```python
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'from_int' of type jitclass.Fraction#7f36cff038d0<numerator:int64,denominator:int64>

File "../../../../../../tmp/ipykernel_12883/2473870322.py", line 4:
<source missing, REPL/exec in use?>

During: typing of get attribute at /tmp/ipykernel_12883/2473870322.py (4)

File "../../../../../../tmp/ipykernel_12883/2473870322.py", line 4:
<source missing, REPL/exec in use?>
```
user: tobias-haenel
labels: bug - typing: Bugs: occuring at typing time
issue_9211: state: open
title: Failure to optimize division by power-of-2 into bitshifting
body: Numba is 0.58. llvmlite is 0.41.0. Ubuntu 22.04 on i7-12700K.

Consider the following code:

```python
from timeit import timeit
from numba import njit
import numpy as np

@njit
def divide(n):
    total = 0
    for i in range(n):
        i = np.int32(i)
        total += i // 32
    return total

@njit
def shift(n):
    total = 0
    for i in range(n):
        i = np.int32(i)
        total += i >> 5
    return total

assert divide(1000) == shift(1000)

print("divide", timeit(lambda: divide(10_000)))
print("shift", timeit(lambda: shift(10_000)))
```

Converting an integer division by a power of 2 to a bitshift is a venerable compiler optimization, so I would've expected it to happen automatically. And yet:

```
$ python benchmark.py 
divide 3.8489795919740573
shift 1.6269098360207863
```

The same failure to optimize happen when SIMD is disabled:

```
$ NUMBA_LOOP_VECTORIZE=0 python benchmark.py 
divide 7.3872741389786825
shift 2.888690105988644
```

The failure to optimize happens with `np.int32` and `np.int16`. However, with `np.int64` the optimization does happen. If you edit the above to be `int64` instead of `int32`:

```
$ python benchmark_int64.py 
divide 0.9052806000108831
shift 0.9086310719721951
```

## Discussion

This is plausibly related to #8742, it sounds like there are different ways to implement the `//` operator and maybe this is one that LLVM doesn't understand very well?
user: itamarst
labels: discussion: An issue requiring discussion
performance - run time: Performance issue occurring at run time.
issue_9210: state: open
title: "for x in arr" breaks auto-vectorization, unlike semantically-equivalent indexing
body: Numba is 0.58. llvmlite is 0.41.0. Ubuntu 22.04 on i7-12700K.

Consider the following script:

```python
from timeit import timeit
from numba import njit
import numpy as np

ARR = np.ones((1_00, 1_00), dtype=np.uint64)

@njit
def variant1(arr):
    total = 0
    for value in arr.ravel():
        total += value
    return total

@njit
def variant2(arr):
    total = 0
    arr = arr.ravel()
    for i in range(len(arr)):
        total += arr[i]
    return total

assert variant1(ARR) == variant2(ARR)

print("variant1", timeit(lambda: variant1(ARR)))
print("variant2", timeit(lambda: variant2(ARR)))
```

If I run this with auto-vectorization disabled, they take the same amount of time:

```
$ NUMBA_LOOP_VECTORIZE=0 python benchmark2.py 
variant1 2.991276621934958
variant2 2.9882662689778954
```

With auto-vectorization enabled, however, the second version is much faster:

```
$ python benchmark2.py 
variant1 4.083474779967219
variant2 1.0015606820816174
```

(Even if the first variant hadn't regressed it would be slower.)

## Discussion

It's possible this isn't fixable. But if Numba knows the array is 1-dimensional (and contiguous?), it could generate LLVM IR for `variant1` equivalent to `variant2` (instead of whatever it's generating now), to help LLVM optimize it? They do seem semantically identical to me so long as the indexing variable is anonymous, though I might be missing something.

**Update:** Switched to `ravel()`, so there's less unnecessary copying.
user: itamarst
labels: discussion: An issue requiring discussion
performance - run time: Performance issue occurring at run time.
issue_9206: state: open
title: `FunctionType` called by another jitted function throws a `ValueError`
body: ```python
import os

from numba import njit
from numba.core.types import FunctionType, int64
from numba.extending import overload_method

# os.environ["NUMBA_DUMP_OPTIMIZED"] = "1"

func_type = FunctionType(int64(int64,))

@njit(int64(func_type))
def f(g):
    return g(1)

@njit(no_cfunc_wrapper=True)
def g(a):
    return a + 1

print(f(g))
```
Throws
```
Traceback (most recent call last):
  File "xx.py", line 21, in <module>
    print(f(g))
  File "numba/experimental/function_type.py", line 163, in _get_wrapper_address
    raise ValueError(f'wrapper address of {type(func)} instance must be'
ValueError: wrapper address of <class 'numba.core.registry.CPUDispatcher'> instance must be a positive integer but got 0 [sig=(int64,) -> int64]
```
In principle, `g` isn't called by C function, I don't think it must have a `cfunc_wrapper`. But removing it will trigger this error.
user: dlee992
issue_9200: state: open
title: Track ufunc methods and attributes impl. progress
body: This issue is a follow-up of pull request #9123 to track progress and To-Do items for exposing ufunc methods and attributes:

### Attributes:
- [x] `nin` - #9123 
- [x] `nout` - #9123 
- [x] `nargs` - #9123 
- [x] `identity` - #9123 
- [x] `signature` - #9123 
- [ ] `ntypes`
- [ ] `types`

### Methods:
- [ ] `accumulate`
- [ ] `at`
- [ ] `outer`
- [x] `reduce` - #9123 
  - [ ] Change implementation to not use `numpy.ndenumerate`
  - [ ] Support `keepdims` and `where` parameters
  - [ ] Remove experimental feature warning
- [ ] `reduceat`
user: guilhermeleobas
issue_9199: state: open
title: Return `Tuple` type containing `Record` type has an error
body: ```python
import os

import numpy as np
from numba import njit, types

os.environ["NUMBA_DEBUG_TYPEINFER"] = "1"
os.environ["NUMBA_CAPTURED_ERRORS"] = "new_style"

arr = np.array(object=[(1, 2)], dtype=[('a1', 'f8'), ('a2', 'f8')])

@njit
def _goo(arr, i):
    rec = arr[i]
    return rec, i

@njit
def foo(arr, i):
    rec, j = _goo(arr=arr, i=i)

foo(arr=arr, i=0)
```
run this, get an error 
```python
  File "numba/core/callwrapper.py", line 175, in build_wrapper
    status, retval = self.context.call_conv.call_function(
  File "numba/core/callconv.py", line 600, in call_function
    out = self.context.get_returned_value(builder, resty, retval)
  File "numba/core/base.py", line 674, in get_returned_value
    return self.data_model_manager[ty].from_return(builder, val)
  File "numba/core/datamodel/models.py", line 627, in from_return
    return self._from("from_data", builder, vals)
  File "numba/core/datamodel/models.py", line 561, in _from
    v = getattr(dm, methname)(builder, val)
  File "numba/core/datamodel/models.py", line 967, in from_data
    raise NotImplementedError("use load_from_data_pointer() instead")
NotImplementedError: ('use load_from_data_pointer() instead' ...
```

If I only return rec in _goo, then it's fine.
user: dlee992
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9198: state: open
title: Add an alternate runtests script for bootstrapping on new Python
body: Add scripts to do runtests differently. This one is useful for bootstrapping Numba after high impact changes that can segfault or stall the compiler. See docstring in the added scripts for details.

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: sklam
labels: skip_release_notes: Skip towncrier requirement
issue_9193: state: open
title: Tracking NumPy usage in various modules. 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

As titled, this PR tracks usage of NumPy across Numba. The end goal is to hopefully refactor NumPy usage in a way such that it is restricted to either `numba.np`  and/or `numba.cuda` module in order to simplify dependencies.

Following are places other than `numba.np` where NumPy is being used:
- [ ] `numba.core`
  - [ ] `boxing.py` (Will require type separation between NumPy and Python scalar types.)
  - [ ] `errors.py`
  - [ ] `inline_closurecall.py`
  - [ ] `ir_utils.py`
  - [ ] `utils.py`
  - [ ] `datamodel.models.py`
  - [ ] `types` module (Will require type separation between NumPy and Python scalar types.)
  - [ ] `typing` module (Will require type separation between NumPy and Python scalar types.)
- [ ] `numba.cpython`
  - [ ] `builtins.py`
  - [ ] `charseq.py`
  - [ ] `hashing.py`
  - [ ] `mathimpl.py`
  - [ ] `numbers.py`
  - [ ] `randomimpl.py`
  - [ ] `unicode_support.py`
  - [ ] `unicode.py`
- [ ] `numba.misc`
  - [ ] `dummyarray.py`
  - [ ] `gdb_print_extension.py`
  - [ ] `mergesort.py`
  - [ ] `numba_gdbinfo.py`
  - [ ] `numba_sysinfo.py`
  - [ ] `quicksort.py`
  - [ ] `special.py`

For the `.parfors`, `.stencils` and `.pycc`modules, they can be considered their own separate specialized modules depending on the `numba.np` module.
 
Moreover there are following QoL tasks:
- [ ] A test to make sure we don't accidentally add more NumPy usage in modules other than `numba.np`
user: kc611
issue_9188: state: open
title: `get_allocation_stats` needs an init guard in 0.57.x, since new envvar `NRT_STATS`
body: ```python
    def get_allocation_stats(self):
        """
        Returns a namedtuple of (alloc, free, mi_alloc, mi_free) for count of
        each memory operations.
        """
        # No init guard needed to access stats members <--------- this assumption is broken in 0.57.1, I think, since stuart's new PR about NRT_STATS
        return _nrt_mstats(alloc=_nrt.memsys_get_stats_alloc(),
                           free=_nrt.memsys_get_stats_free(),
                           mi_alloc=_nrt.memsys_get_stats_mi_alloc(),
                           mi_free=_nrt.memsys_get_stats_mi_free())

```
When you try this:
```bash
python -c "import os; os.environ['NUMBA_NRT_STATS'] = '1'; from numba import config; print(config.NRT_STATS); import numba; rtsys = numba.core.runtime.rtsys; print('[NRT] before:' + str(rtsys.get_allocation_stats())); print('numba.__version__', numba.__version__)"
1
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "numba/core/runtime/nrt.py", line 110, in get_allocation_stats
    return _nrt_mstats(alloc=_nrt.memsys_get_stats_alloc(),
RuntimeError: NRT stats are disabled.
```

Related with #8235 , in 0.56.x, this bash won't have this exception.

gentle cc @stuartarchibald 
user: dlee992
labels: discussion: An issue requiring discussion
issue_9187: state: open
title: `TypeError` when referencing value from typed dict `get()` with `prange()`
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

## Issue
Referencing a value obtained via `numba.typed.Dict.get()` in a `prange()` loop causes a `TypeError`:

```python
import numba as nb
from numba.core import types

nb.set_num_threads(1)

@nb.njit(parallel=True)
def f2(d):
    a = 0.
    B = d.get('k', 0.)  # capitalization of B affects the failure rate
    c = 0.
    for _ in nb.prange(1):
        c += a + B

t = nb.typed.Dict.empty(types.unicode_type, types.float64)
t['k'] = 1.
f2(t)
```

```
$ python repro.py 
TypeError: expected float64, got None

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/mnt/home/lgarrison/numba/issues/optionaltype-parallel.py", line 27, in <module>
    f2(t)
SystemError: CPUDispatcher(<function f2 at 0x7f9100d80430>) returned a result with an exception set
```

The bug is not fully deterministic; I've included another reproducer below with a lower failure rate in case it's helpful for understanding why.  The bug is also sensitive to the exact operations that are being done in the for loop (which is why there are two "unnecessary" variables `a` and `c` included).

The weirdest feature of this bug is that the variable names affect the reproduction rate! In particular, capitalizing `B` increases the failure rate from ~50% to 100% for me.  I assume it affects the ordering of some internal data structure.

In terms of root cause, I've poked around a bit, and my guess is that this is related to the return type of `get()` being an `OptionalType`, even though the type is the same for the default value (#5468). But I'm not sure that explains the non-determinism.

## Versions
Reproduced on 0.57.1 and main (f4c4afcb180193064a0c985246c7c71d007c6b1d)

## Reproducers
<details>
<summary>Longer reproducer</summary>

```python
import numba as nb
from numba.core import types

nb.set_num_threads(1)

# ~ 20% failure rate
@nb.njit(parallel=True)
def f1(d):
    a = 0.
    b = d.get('k', 0.)
    for _ in nb.prange(1):
        a += b

t = nb.typed.Dict.empty(types.unicode_type, types.float64)
t['k'] = 1.
f1(t)

# 100% failure rate
@nb.njit(parallel=True)
def f2(d):
    a = 0.
    B = d.get('k', 0.)  # capitalization of B affects the failure rate
    c = 0.
    for _ in nb.prange(1):
        c += a + B

t = nb.typed.Dict.empty(types.unicode_type, types.float64)
t['k'] = 1.
f2(t)
```

</details>
user: lgarrison
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9185: state: open
title: Numba Dispatch error when Number of keyword args > 3 for nested numba calls
body: 

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.



This error happens when defining function `*` is used. I can start with three function definition cases, The first two cases are passed, and the third one which is a minor modification of the second test case fails.

Numba version: '0.57.1'
Python version: '3.9.17'

## Pass Test 1
```python
import numba as nb
def test_1(a, b, c, d, e, f, g):
    return a + b + c + d + e + f + g
test_1 = nb.njit(test_1)

def test_2(a, b, c, d, e, f, g):
    return test_1(a, b, c, d, e, f, g)
test_2 = nb.njit(test_2)
test_2(1, 2, 3, 4, 5, 6, 7)
```

## Pass Test 2
```python
import numba as nb
def test_1(a, b, c, *, d, e, f):
    return a + b + c + d + e + f
test_1 = nb.njit(test_1)

def test_2(a, b, c, d, e, f, g):
    return test_1(a, b, c, d, e, f)
test_2 = nb.njit(test_2)
test_2(1, 2, 3, 4, 5, 6, 7)
```


## Fail Test 3
```python
import numba as nb
def test_1(a, b, c, *, d, e, f, g):
    return a + b + c + d + e + f
test_1 = nb.njit(test_1)

def test_2(a, b, c, d, e, f, g):
    return test_1(a, b, c, d, e, f, g)
test_2 = nb.njit(test_2)
test_2(1, 2, 3, 4, 5, 6, 7)
```
### Error traceback
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Cell In[10], line 9
      7 test_2 = nb.njit(test_2)
      8 # test_1(1, 2, 3, 4, 5, 6, 7)
----> 9 test_2(1, 2, 3, 4, 5, 6, 7)

File ~/.cache/pypoetry/virtualenvs/indices-ldm-post-process-danSbNDA-py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py:467, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 467     error_rewrite(e, 'typing')
    468 except errors.UnsupportedError as e:
    469     # Something unsupported is present in the user code, add help info
    470     error_rewrite(e, 'unsupported_error')

File ~/.cache/pypoetry/virtualenvs/indices-ldm-post-process-danSbNDA-py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args..error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at .
tuple index out of range
During: resolving callee type: type(CPUDispatcher())
During: typing of call at /tmp/ipykernel_3435313/3644502072.py (6)

Enable logging at debug level for details.
```


<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: rishabh1212
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9179: state: open
title: Using numpy random generators does not work with optional arguments
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

Consider the following example:

```python
import numpy as np
from numba import njit

RNG = np.random.default_rng(0)


@njit
def uniform(rng=RNG):
    return rng.uniform()


# works
print(uniform(RNG))
# works
print(uniform(rng=RNG))
# fails
print(uniform())
```

The call to `uniform` using both positional and keyword args works, but relying on the default does not and yields the following error

```
Traceback (most recent call last):
  File "/home/maxnoe/Uni/CTA/ctapipe/test_default.py", line 17, in <module>
    print(uniform())
          ^^^^^^^^^
  File "/home/maxnoe/.local/conda/envs/cta-dev/lib/python3.11/site-packages/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/maxnoe/.local/conda/envs/cta-dev/lib/python3.11/site-packages/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.NumbaNotImplementedError: Failed in nopython mode pipeline (step: native lowering)
<numba.core.base.OverloadSelector object at 0x7faa1592f890>, (NumPyRandomGeneratorType,)
During: lowering "rng = arg(0, name=rng)" at /home/maxnoe/Uni/CTA/ctapipe/test_default.py (7)
```

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: maxnoe
issue_9178: state: open
title: stack should support list as input
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->


To reproduce the problem:
```python
from numba import njit, prange
from numba.typed import List
import numpy as np


@njit()
def test_stack():
    array = np.ones((2, 3))
    list_of_array = [array] * 10
    np.stack(list_of_array)

if __name__ == "__main__":
    test_stack()
```

output:
```
No implementation of function Function(<function stack at 0x0000017D0430F3A0>) found for signature:
 
 >>> stack(list(array(float64, 2d, C))<iv=None>)
```

It's discussed [here](https://github.com/numba/numba/issues/7476) that the list is not support because the dimension can not be infered during compilation.

However, it actually can, because the custom stack (actually hstack here) function can be implemented:
```python
from numba import njit, prange
from numba.typed import List
import numpy as np

@njit()
def stack(list_of_array):
    shape = (len(list_of_array),) + list_of_array[0].shape
    stacked_array = np.empty(shape)
    for j in prange(len(list_of_array)):
        stacked_array[j] = list_of_array[j]
    return stacked_array

if __name__ == "__main__":
    # Note that you have to use typed list provided by numba here.
    typed_list = List()
    [typed_list.append(np.ones((2, 3))) for _ in range(10)]
    stack(typed_list)
    stacked = stack(typed_list)
    print(stacked.shape)
    print(stacked)
```

So, why list is not supported? I think it's a bug in fact.
user: 46319943
issue_9175: state: open
title: Segfault when iterating over typed Dict right after printing 0.57.1
body: In numba 0.57.1

If you print a typed Dict, and then iterate through it it causes a segfault. 

```python
from numba import njit
from numba.typed import Dict, List

@njit
def foo():
    d = Dict()
    d[3] = 1
    print(d) # <- Only segfaults with this
    x = 0
    for k in d:
        x += k
    return x
foo()
```

Interestingly there is no segfault when setting NUMBA_OPT=0:
`NUMBA_OPT=0 python dict_segfault.py`

My best guess is that that print() is implemented here by calling str() on the dict in object mode (i.e. on it's python side proxy), and the incref associate with boxing the Dict() to its proxy was somehow removed in an optimization pass? Hard to say. If that's what is happening the easy fix may be to just implement str(dict) on then numba side, since it seems like ya'll are trying to move away from injecting objmode code when possible anyway. 
user: DannyWeitekamp
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_9174: state: open
title: Internal error at <numba.core.typeinfer.CallConstraint
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.


```python
import numba
import numpy as np
from numba import njit
from numba.typed import List

x = np.arange(30.0).reshape(10, 3)


@njit
def _transpose(x):
    if isinstance(x, List):
        out = List()
        for _x in x:
            out.append(_x.T)
        return out
    else:
        return x.T


@njit
def f(x):
    x = _transpose(x)
    return 0


_ = f(x)

_y = [x, x + 1]

data_type = numba.typeof(_y[0])
data_type.layout = "A"

y = List.empty_list(data_type)
for _ in _y:
    y.append(_)


@njit
def g(x):
    x = _transpose(x)
    return 0


_ = g(y)

```

Running this a few times, and there are chances that the following error comes out:

```python
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Cell In[1], line 44
     40     x = _transpose(x)
     41     return 0
---> 44 _ = g(y)

File ~/mambaforge/envs/py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 468     error_rewrite(e, 'typing')
    469 except errors.UnsupportedError as e:
    470     # Something unsupported is present in the user code, add help info
    471     error_rewrite(e, 'unsupported_error')

File ~/mambaforge/envs/py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x7f8d70e721f0>.
Array(float64, 2, 'A', False, aligned=True)
During: resolving callee type: type(CPUDispatcher(<function _transpose at 0x7f90cc3ca5e0>))
During: typing of call at /tmp/ipykernel_2501140/2578620684.py (40)

Enable logging at debug level for details.

File "../../../../../../tmp/ipykernel_2501140/2578620684.py", line 40:
<source missing, REPL/exec in use?>
```

The above code is a simplification of my program. If you remove `x+1` from `y` or change anything, the error may then disappear. I have to change the array layout to "A", because if I don't, list of `x` and list of `x.T` will have different layout of "C" and "F", which are considered different dtypes and cannot be unified by numba.

numba version '0.57.1', py3.9
user: auderson
labels: no action required: No action was needed to resolve.
issue_9172: state: open
title: Remove an undefined name
body: In file: compiler.py, the list named `__all__` contains an undefined name which can result in errors  when this module is imported. I removed the undefined name from the list. For more information regarding `__all__`, please read about [importing fields from a package](https://docs.python.org/3/tutorial/modules.html#importing-from-a-package).  

Sponsorship and Support:

This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF)(https://openssf.org/): Project Alpha-Omega(https://alpha-omega.dev/). Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.

The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.
user: munahaf
issue_9166: state: open
title: shape mismatch ignored when using inplace operator
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I've encountered an issue where the behavior of a function under Numba's JIT compilation differs from its behavior when run as plain Python code. Specifically, the issue occurs when performing an in-place bitwise operation on NumPy arrays of different shapes.

Here is a minimal example to reproduce the issue:

```python
from numba import njit
import numpy as np

@njit
def test():
    array = np.array([True, False, True])
    array &= np.array([True, False])
    return array

print(test())  # Outputs: array([ True, False,  True])
print(test.py_func())  # Raises ValueError: operands could not be broadcast together with shapes (3,) (2,) (3,) 
```
When run under Numba's JIT, the function executes without error and the in-place operation appears to ignore the shape mismatch. However, when the same function is run as plain Python code, it correctly raises a ValueError due to the shape mismatch.

Operating System: Windows 10
Python Environment: Anaconda Python 3.10.12
user: plutonium-94
labels: bug - miscompile: Bugs: miscompile
issue_9164: state: open
title: Support for Array API Standard
body: ## Feature request

I am opening this issue to see if Numba would support the [Array API Standard](https://data-apis.org/array-api/latest/) as input.

For example either with the `numpy.array_api` namespace:

```python
import numpy.array_api as np

@jit(nopython=True)
def tmp():
    return np.unique_inverse(np.arange(10))
tmp()
```

Or the `array_api_compat` namespace:

```python
import array_api_compat.numpy as np

@jit(nopython=True)
def tmp():
    return np.unique_inverse(np.arange(10))
tmp()
```


I am curious about this issue for a rather odd use case, but I thought it is general enough to raise here.

My particular interest is that I am tracing the execution of [functions in sklearn's Array API support](https://scikit-learn.org/stable/modules/array_api.html#example-usage), to then generate source code for the resulting operations, which then I would like to run through Numba.

As is, I will have to convert the API calls into NumPy calls, so that Numba can analyze them, instead of leaving as Array API calls.

EDIT: For reference, there is a list of differences between the NumPy API and the Array API [in the NumPy docs](https://numpy.org/doc/stable/reference/array_api.html).
user: saulshanabrook
labels: discussion: An issue requiring discussion
needs triage/maintainer discussion: For an issue/PR that needs discussion at a triage/maintainer meeting
issue_9150: state: open
title: CI Task: feature branch specific CI pipeline
body: I have used git tricks to preserve history for azure ci changes. For example: https://github.com/numba/numba/pull/9128/commits/0fc40ca5ce95694f8ab8d692946b1668976790a3. This can be confusing. Instead, we can explore branch specific CI pipeline that only triggers for the feature branch so that we don't need to modify the default testing scripts.

If this doesn't work as nicely as we hoped, we will go for a two branches approach:

- one branch for changes merge-able to main
- one branch for testing

user: sklam
issue_9147: state: open
title: mean() returns incorrect dtype
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
```python
from numba import njit
import numpy as np

@njit
def foo(x):
    return x-np.mean(x)

foo(np.array([1,2], 'float32')) # array([-0.5,  0.5])
# expected array([-0.5,  0.5], dtype=float32)
```
Tested under Python 3.10.9 with 0.57.1.
Without the `@njit` decorator, this returns the expected `float32` array. This also returned the expected result under 0.56.4.
user: Ranfir
issue_9129: state: open
title: Symbol not found error when calling a recursive function + cache from a jitclass
body: Hello.
Here is a weird I have seen; I checked if anything similar was reported but didn't found.

The code below calls a recursive function from a jitclass. Such function has `@njit(cache=True)` as header. It runs well on first time, but fails on second time:

```
(venv) best@ottokar:~/dev/splendor$ python3 numba_debug.py 
All good !
(venv) best@ottokar:~/dev/splendor$ python3 numba_debug.py 
**LLVM ERROR: Symbol not found: .numba.unresolved$_ZN8__main__10_recursiveB3v12B62c8tJTIcFKzyF2ILShI4CrgQElYZ5yRbdT9XqICn1Wk1gsBbBVCOlJ7CIJgA_3dEx**
Abandon
```

If I change to `cache=False` or if I call the recursive function outside of the class, that's fine. I am using numba 0.57.1 and python 3.11.2 on Linux.

Here is the code:

```
#!/usr/bin/env python3

import numpy as np
from numba import njit
import numba

spec = [
	('misc', numba.int8[:,:]),
]
@numba.experimental.jitclass(spec)
class MyClass():
	def __init__(self):
		self.misc = np.zeros((2,2), dtype=np.int8)

	def run(self):
		_recursive(0)
		print('All good !')

@njit(cache=True)
def _recursive(length):
	if length < 3:
		_recursive(length+1)

myobject = MyClass()
myobject.run()
```
user: cestpasphoto
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_9124: state: open
title: np.argpartition / np.partition issue: kth out of bounds
body: ## Reporting a bug

Incorrect behaviour of njit-decorated `np.argpartition` / `np.partition` function with partition parameter `kth=-len(array)`.
Code for reproducibility below:

```
import sys
import numba as nb
import numpy as np

from numba import njit


def fn_np(a, k):
    y = np.argpartition(a, -k)
    return y


@njit
def fn_nb(a, k):
    y = np.argpartition(a, -k)  # np.partition as well
    return y


if __name__ == "__main__":

    print(sys.version, nb.__version__)

    a = np.array([30,20,10], dtype='f8')

    print(fn_np(a, k=3))  # ok
    print(fn_nb(a, k=3))  # error
```

Output:
```
3.11.4 (main, Jun  9 2023, 07:59:55) [GCC 12.3.0] 0.57.1
[2 1 0]
Traceback (most recent call last):
  File "/home/shared/bug.py", line 26, in <module>
    print(fn_nb(a, k=3))  # error
          ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/numba/np/arraymath.py", line 1848, in valid_kths
    raise ValueError("kth out of bounds")
ValueError: kth out of bounds
```

user: pashaPASHaa
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_9121: state: open
title: if condition test on variadic parameter tuple failed
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

**Describe the bug**

When using the `@njit` decorator on a function with an arbitrary number of arguments (`*x`), a `numba.core.errors.TypingError` is thrown when the tuple is empty. However, when checking for the length of the tuple (`if len(x)`) instead of the truthiness of the tuple (`if x`), no error is thrown and the function behaves as expected. 

**To Reproduce**
Steps to reproduce the behavior:

1. Define the function:
    ```python
    @njit
    def max_(*x):
        return max(x) if x else 0
    ```
2. Call the function with no arguments:
    ```python
    max_()
    ```
3. See error.

**Expected Behavior**

The function should return `0` when called with no arguments, as it does when the condition is changed to `if len(x)`:

```python
@njit
def max_(*x):
    return max(x) if len(x) else 0
max_()
```
This does not produce an error and correctly returns `0`.

**Error Message**
```text
Traceback (most recent call last):
  File "...\lib\site-packages\IPython\core\interactiveshell.py", line 3505, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-107-96dcea1a2319>", line 1, in <module>
    max_()
  File "...\lib\site-packages\numba\core\dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "...\lib\site-packages\numba\core\dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function max>) found for signature:
 
 >>> max(Tuple())
 
There are 8 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'MinMaxBase.generic': File: numba\core\typing\builtins.py: Line 906.
    With argument(s): '(Tuple())':
   Rejected as the implementation raised a specific error:
     TypeError: max() argument is an empty tuple
  raised from ...\lib\site-packages\numba\core\typing\builtins.py:919
  - Of which 2 did not match due to:
  Overload in function 'indval_max': File: numba\cpython\builtins.py: Line 588.
    With argument(s): '(Tuple())':
   Rejected as the implementation raised a specific error:
     TypingError: missing a required argument: 'indval2'
  raised from ...\lib\site-packages\numba\core\typing\templates.py:784
  - Of which 2 did not match due to:
  Overload in function 'boolval_max': File: numba\cpython\builtins.py: Line 617.
    With argument(s): '(Tuple())':
   Rejected as the implementation raised a specific error:
     TypingError: missing a required argument: 'val2'
  raised from ...\lib\site-packages\numba\core\typing\templates.py:784
  - Of which 2 did not match due to:
  Overload of function 'max': File: numba\cpython\builtins.py: Line 648.
    With argument(s): '(Tuple())':
   No match.
During: resolving callee type: Function(<built-in function max>)
During: typing of call at <ipython-input-105-4cccaa644969> (3)
File "<ipython-input-105-4cccaa644969>", line 3:
def max_(*x):
    return max(x) if x else 0
    ^
```

Operating System: Windows 10
Python Environment: Anaconda Python 3.10.12

user: plutonium-94
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9119: state: open
title: `memcpy` static buffer content into newly allocated buffer
body: Fixes issue #9097 
user: guilhermeleobas
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_9116: state: open
title: numpy.diff fails on datetime64[ns] array
body: ## Reporting a bug


- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

The following code can't compile:
```
import numba
import numpy as np

@numba.jit(nopython=True, nogil=True)
def bug(times: np.ndarray):
  return np.diff(times)

bug(np.array([np.datetime64('2023-08-01T12:00:00'), np.datetime64('2023-08-01T12:00:01')]))


```

The error message is:

```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function diff at 0x1041ff420>) found for signature:
 
 >>> diff(array(datetime64[ns], 1d, C))
 
There are 2 candidate implementations:
   - Of which 2 did not match due to:
   Overload in function 'np_diff_impl': File: numba/np/arraymath.py: Line 3508.
     With argument(s): '(array(datetime64[ns], 1d, C))':
    Rejected as the implementation raised a specific error:
      TypingError: Failed in nopython mode pipeline (step: nopython frontend)
    No implementation of function Function(<built-in function setitem>) found for signature:
     
     >>> setitem(array(datetime64[ns], 1d, C), int64, timedelta64[ns])
     
    There are 16 candidate implementations:
          - Of which 16 did not match due to:
          Overload of function 'setitem': File: <numerous>: Line N/A.
            With argument(s): '(array(datetime64[ns], 1d, C), int64, timedelta64[ns])':
           No match.
    
    During: typing of setitem at /Users/samuelhapak/Library/Caches/pypoetry/virtualenvs/wutils-MifiL3zq-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py (3534)
    
    File "../../../Library/Caches/pypoetry/virtualenvs/wutils-MifiL3zq-py3.11/lib/python3.11/site-packages/numba/np/arraymath.py", line 3534:
        def diff_impl(a, n=1):
            <source elided>
                for i in range(size - 1):
                    work[i] = a2[major, i + 1] - a2[major, i]
                    ^

  raised from /Users/samuelhapak/Library/Caches/pypoetry/virtualenvs/wutils-MifiL3zq-py3.11/lib/python3.11/site-packages/numba/core/typeinfer.py:1086

```

Looking at the implementation [here](https://github.com/numba/numba/blob/fcf94205335dcc6135d2e19c07bbef968d13610d/numba/np/arraymath.py#L3537)

the issue seems to be creating the empty array of type `datetime64[ns]` whereas the correct type should be `timedelta64[ns]`.

This is wrong in this particular case because unlike most of the types, difference of two `datetime64[ns]` is of type `timedelta64[ns]`.
user: hleumas
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9109: state: open
title: various seg faults on Debian arm64 with numba 0.57.1
body: This may be related to #6657 but I'm not sure.

## Reporting a bug

- [X] I have tried using the latest released version of Numba 0.57.1 (with a few debian patches) output of numba -s after the stack trace
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

While running the full test suite on arm64 I had encountered various segfaults.

Once I got a system with gdb available the first one encounted by numba.runtests is test_dictobject.py test_007_collision_check  

Here's the start of a gdb stack trace generated by

cp numba/tests/test_dictobject.py ~
gdb /usr/bin/python3
set args test_dictobject.py
run
bt full

```
#0  0x00000508c85f7c08 in ?? ()
No symbol table info available.
#1  0x0000ffffed2a4ab4 in NRT_MemInfo_call_dtor (mi=0x23ba9a0) at numba/core/runtime/nrt.cpp:401
No locals.
#2  0x0000ffffed2a4b20 in NRT_MemInfo_release (mi=<optimized out>) at numba/core/runtime/nrt.cpp:412
No locals.
#3  0x0000ffffed2a1d08 in MemInfo_dealloc (self=0xffffe0355770) at numba/core/runtime/_nrt_python.c:137
No locals.
#4  0x000000000051a598 in _Py_Dealloc (op=<optimized out>) at ../Objects/object.c:2390
        type = <optimized out>
        dealloc = <optimized out>
        type = <optimized out>
        dealloc = <optimized out>
#5  Py_DECREF (op=<optimized out>) at ../Include/object.h:538
No locals.
#6  Py_XDECREF (op=<optimized out>) at ../Include/object.h:602
No locals.
#7  _PyObject_FreeInstanceAttributes (self=0xffffe04a5fd0) at ../Objects/dictobject.c:5583
        i = 1
        tp = <optimized out>
        values_ptr = 0xffffe04a5fb0
        values = 0xffffe04e5150
        keys = 0x1a11330
        tp = <optimized out>
        values_ptr = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
        values = <optimized out>
        keys = <optimized out>
        i = <optimized out>
#8  subtype_dealloc (self=0xffffe04a5fd0) at ../Objects/typeobject.c:1442
        dictptr = 0xffffe04a5fb8
        _tstate = <optimized out>
        type_needs_decref = <optimized out>
        list = <optimized out>
        type = <optimized out>
        base = 0x940f88 <PyBaseObject_Type>
        basedealloc = 0x4c20a0 <object_dealloc>
        has_finalizer = <optimized out>
#9  0x00000000004c25c0 in _Py_Dealloc (op=<optimized out>) at ../Objects/object.c:2390
        type = <optimized out>
        dealloc = <optimized out>
#10 Py_DECREF (op=<optimized out>) at ../Include/object.h:538
No locals.
#11 Py_XDECREF (op=<optimized out>) at ../Include/object.h:602
No locals.
#12 _PyFrame_Clear (frame=0xfffff7ff37b0) at ../Python/frame.c:141
        i = 1
#13 0x00000000004abf60 in _PyEvalFrameClearAndPop (frame=<optimized out>, tstate=0xa5ef70 <_PyRuntime+166344>)
    at ../Python/ceval.c:6411
No locals.
#14 _PyEval_EvalFrameDefault (tstate=0xa5ef70 <_PyRuntime+166344>, frame=0xfffff7ff3730, throwflag=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--c
    at ../Python/ceval.c:2441
        dying = <optimized out>
        retval = 0x931390 <_Py_NoneStruct>
        op = <optimized out>
        dealloc = <optimized out>
        opcode = <optimized out>
        oparg = <optimized out>
        eval_breaker = <optimized out>
        cframe = {use_tracing = 0 '\000', current_frame = 0xfffff7ff3730, previous = 0xffffffffdfe0}
        call_shape = <optimized out>
        prev_cframe = <optimized out>
        names = <optimized out>
        consts = <optimized out>
        first_instr = <optimized out>
        next_instr = 0xffffe239ecc6
        stack_pointer = <optimized out>
        exception_unwind = <optimized out>
        dying = <optimized out>
        __func__ = "_PyEval_EvalFrameDefault"
        opcode_targets = {0x4b8788 <_PyEval_EvalFrameDefault+52008>, 0x4ac3b8 <_PyEval_EvalFrameDefault+1880>, 
          0x4aca58 <_PyEval_EvalFrameDefault+3576>, 0x4afba0 <_PyEval_EvalFrameDefault+16192>, 
          0x4ae31c <_PyEval_EvalFrameDefault+9916>, 0x4ae064 <_PyEval_EvalFrameDefault+9220>, 
          0x4afa5c <_PyEval_EvalFrameDefault+15868>, 0x4b0f24 <_PyEval_EvalFrameDefault+21188>, 
          0x4ad250 <_PyEval_EvalFrameDefault+5616>, 0x4ad454 <_PyEval_EvalFrameDefault+6132>, 
          0x4b8b80 <_PyEval_EvalFrameDefault+53024>, 0x4b14d0 <_PyEval_EvalFrameDefault+22640>, 
          0x4b1614 <_PyEval_EvalFrameDefault+22964>, 0x4b00d8 <_PyEval_EvalFrameDefault+17528>, 
          0x4afafc <_PyEval_EvalFrameDefault+16028>, 0x4b1710 <_PyEval_EvalFrameDefault+23216>, 
          0x4aeafc <_PyEval_EvalFrameDefault+11932>, 0x4acf48 <_PyEval_EvalFrameDefault+4840>, 
          0x4aefa8 <_PyEval_EvalFrameDefault+13128>, 0x4b124c <_PyEval_EvalFrameDefault+21996>, 
          0x4ae1f0 <_PyEval_EvalFrameDefault+9616>, 0x4af374 <_PyEval_EvalFrameDefault+14100>, 
          0x4ac4d0 <_PyEval_EvalFrameDefault+2160>, 0x4ac798 <_PyEval_EvalFrameDefault+2872>, 
          0x4ae3f4 <_PyEval_EvalFrameDefault+10132>, 0x4b00c8 <_PyEval_EvalFrameDefault+17512>, 
          0x4ae600 <_PyEval_EvalFrameDefault+10656>, 0x4aec88 <_PyEval_EvalFrameDefault+12328>, 
          0x4acaa0 <_PyEval_EvalFrameDefault+3648>, 0x4adae0 <_PyEval_EvalFrameDefault+7808>, 
          0x4b2ce0 <_PyEval_EvalFrameDefault+28800>, 0x4b8688 <_PyEval_EvalFrameDefault+51752>, 
          0x4b2c68 <_PyEval_EvalFrameDefault+28680>, 0x4ba620 <_PyEval_EvalFrameDefault+59840>, 
          0x4adcb8 <_PyEval_EvalFrameDefault+8280>, 0x4b0bcc <_PyEval_EvalFrameDefault+20332>, 
          0x4b0cb8 <_PyEval_EvalFrameDefault+20568>, 0x4b2948 <_PyEval_EvalFrameDefault+27880>, 
          0x4ac40c <_PyEval_EvalFrameDefault+1964>, 0x4acb9c <_PyEval_EvalFrameDefault+3900>, 
          0x4ac2c8 <_PyEval_EvalFrameDefault+1640>, 0x4ada30 <_PyEval_EvalFrameDefault+7632>, 
          0x4acec4 <_PyEval_EvalFrameDefault+4708>, 0x4aff5c <_PyEval_EvalFrameDefault+17148>, 
          0x4ad328 <_PyEval_EvalFrameDefault+5832>, 0x4ac710 <_PyEval_EvalFrameDefault+2736>, 
          0x4abe7c <_PyEval_EvalFrameDefault+540>, 0x4b060c <_PyEval_EvalFrameDefault+18860>, 
          0x4ac184 <_PyEval_EvalFrameDefault+1316>, 0x4b28b0 <_PyEval_EvalFrameDefault+27728>, 
          0x4b27a8 <_PyEval_EvalFrameDefault+27464>, 0x4b2838 <_PyEval_EvalFrameDefault+27608>, 
          0x4baa4c <_PyEval_EvalFrameDefault+60908>, 0x4b09f4 <_PyEval_EvalFrameDefault+19860>, 
          0x4b2208 <_PyEval_EvalFrameDefault+26024>, 0x4ac088 <_PyEval_EvalFrameDefault+1064>, 
          0x4ad01c <_PyEval_EvalFrameDefault+5052>, 0x4b1c24 <_PyEval_EvalFrameDefault+24516>, 
          0x4afea0 <_PyEval_EvalFrameDefault+16960>, 0x4ac698 <_PyEval_EvalFrameDefault+2616>, 
          0x4b1d60 <_PyEval_EvalFrameDefault+24832>, 0x4b13e8 <_PyEval_EvalFrameDefault+22408>, 
          0x4b0030 <_PyEval_EvalFrameDefault+17360>, 0x4ace30 <_PyEval_EvalFrameDefault+4560>, 
          0x4ac9cc <_PyEval_EvalFrameDefault+3436>, 0x4adcfc <_PyEval_EvalFrameDefault+8348>, 
          0x4af1fc <_PyEval_EvalFrameDefault+13724>, 0x4af8e8 <_PyEval_EvalFrameDefault+15496>, 
          0x4ae2b4 <_PyEval_EvalFrameDefault+9812>, 0x4b2ac8 <_PyEval_EvalFrameDefault+28264>, 
          0x4b2dec <_PyEval_EvalFrameDefault+29068>, 0x4b1b04 <_PyEval_EvalFrameDefault+24228>, 
          0x4aee00 <_PyEval_EvalFrameDefault+12704>, 0x4ad604 <_PyEval_EvalFrameDefault+6564>, 
          0x4b920c <_PyEval_EvalFrameDefault+54700>, 0x4b07a0 <_PyEval_EvalFrameDefault+19264>, 
          0x4acd2c <_PyEval_EvalFrameDefault+4300>, 0x4adda4 <_PyEval_EvalFrameDefault+8516>, 
          0x4adeb8 <_PyEval_EvalFrameDefault+8792>, 0x4af444 <_PyEval_EvalFrameDefault+14308>, 
          0x4ad0ac <_PyEval_EvalFrameDefault+5196>, 0x4af0ec <_PyEval_EvalFrameDefault+13452>, 
          0x4b199c <_PyEval_EvalFrameDefault+23868>, 0x4abf08 <_PyEval_EvalFrameDefault+680>, 
          0x4b2b30 <_PyEval_EvalFrameDefault+28368>, 0x4b2d44 <_PyEval_EvalFrameDefault+28900>, 
          0x4ad9dc <_PyEval_EvalFrameDefault+7548>, 0x4b2bc4 <_PyEval_EvalFrameDefault+28516>, 
          0x4b23c8 <_PyEval_EvalFrameDefault+26472>, 0x4b0de8 <_PyEval_EvalFrameDefault+20872>, 
          0x4ae92c <_PyEval_EvalFrameDefault+11468>, 0x4b2618 <_PyEval_EvalFrameDefault+27064>, 
          0x4b1a18 <_PyEval_EvalFrameDefault+23992>, 0x4ac354 <_PyEval_EvalFrameDefault+1780>, 
          0x4b2348 <_PyEval_EvalFrameDefault+26344>, 0x4b08fc <_PyEval_EvalFrameDefault+19612>, 
          0x4b100c <_PyEval_EvalFrameDefault+21420>, 0x4b2e80 <_PyEval_EvalFrameDefault+29216>, 
          0x4b96c4 <_PyEval_EvalFrameDefault+55908>, 0x4af6ec <_PyEval_EvalFrameDefault+14988>, 
          0x4abdc4 <_PyEval_EvalFrameDefault+356>, 0x4af740 <_PyEval_EvalFrameDefault+15072>, 
          0x4ad8e8 <_PyEval_EvalFrameDefault+7304>, 0x4af088 <_PyEval_EvalFrameDefault+13352>, 
          0x4b229c <_PyEval_EvalFrameDefault+26172>, 0x4afc4c <_PyEval_EvalFrameDefault+16364>, 
          0x4ae914 <_PyEval_EvalFrameDefault+11444>, 0x4ae8b4 <_PyEval_EvalFrameDefault+11348>, 
          0x4b1538 <_PyEval_EvalFrameDefault+22744>, 0x4b1bb0 <_PyEval_EvalFrameDefault+24400>, 
          0x4acfdc <_PyEval_EvalFrameDefault+4988>, 0x4b03f8 <_PyEval_EvalFrameDefault+18328>, 
          0x4b0914 <_PyEval_EvalFrameDefault+19636>, 0x4af504 <_PyEval_EvalFrameDefault+14500>, 
          0x4ac254 <_PyEval_EvalFrameDefault+1524>, 0x4accb8 <_PyEval_EvalFrameDefault+4184>, 
          0x4adbc8 <_PyEval_EvalFrameDefault+8040>, 0x4adfcc <_PyEval_EvalFrameDefault+9068>, 
          0x4ad534 <_PyEval_EvalFrameDefault+6356>, 0x4b1e88 <_PyEval_EvalFrameDefault+25128>, 
          0x4af88c <_PyEval_EvalFrameDefault+15404>, 0x4b1080 <_PyEval_EvalFrameDefault+21536>, 
          0x4ad798 <_PyEval_EvalFrameDefault+6968>, 0x4b0d50 <_PyEval_EvalFrameDefault+20720>, 
          0x4abd58 <_PyEval_EvalFrameDefault+248>, 0x4ac024 <_PyEval_EvalFrameDefault+964>, 
          0x4b1aa0 <_PyEval_EvalFrameDefault+24128>, 0x4b1cb4 <_PyEval_EvalFrameDefault+24660>, 
          0x4ad820 <_PyEval_EvalFrameDefault+7104>, 0x4ad884 <_PyEval_EvalFrameDefault+7204>, 
          0x4b1778 <_PyEval_EvalFrameDefault+23320>, 0x4b24ac <_PyEval_EvalFrameDefault+26700>, 
          0x4aed64 <_PyEval_EvalFrameDefault+12548>, 0x4ae81c <_PyEval_EvalFrameDefault+11196>, 
          0x4b0b88 <_PyEval_EvalFrameDefault+20264>, 0x4b06e0 <_PyEval_EvalFrameDefault+19072>, 
          0x4b098c <_PyEval_EvalFrameDefault+19756>, 0x4ac964 <_PyEval_EvalFrameDefault+3332>, 
          0x4b134c <_PyEval_EvalFrameDefault+22252>, 0x4b8cc8 <_PyEval_EvalFrameDefault+53352>, 
          0x4b13a4 <_PyEval_EvalFrameDefault+22340>, 0x4ae154 <_PyEval_EvalFrameDefault+9460>, 
          0x4b045c <_PyEval_EvalFrameDefault+18428>, 0x4ac460 <_PyEval_EvalFrameDefault+2048>, 
          0x4b0fdc <_PyEval_EvalFrameDefault+21372>, 0x4ae698 <_PyEval_EvalFrameDefault+10808>, 
          0x4b1464 <_PyEval_EvalFrameDefault+22532>, 0x4b0864 <_PyEval_EvalFrameDefault+19460>, 
          0x4b2ef4 <_PyEval_EvalFrameDefault+29332>, 0x4ae704 <_PyEval_EvalFrameDefault+10916>, 
          0x4abe24 <_PyEval_EvalFrameDefault+452>, 0x4b01cc <_PyEval_EvalFrameDefault+17772>, 
          0x4b2678 <_PyEval_EvalFrameDefault+27160>, 0x4b02b8 <_PyEval_EvalFrameDefault+18008>, 
          0x4ad3ac <_PyEval_EvalFrameDefault+5964>, 0x4b0c3c <_PyEval_EvalFrameDefault+20444>, 
          0x4b1874 <_PyEval_EvalFrameDefault+23572>, 0x4b1134 <_PyEval_EvalFrameDefault+21716>, 
          0x4afe1c <_PyEval_EvalFrameDefault+16828>, 0x4b1d7c <_PyEval_EvalFrameDefault+24860>, 
          0x4aebec <_PyEval_EvalFrameDefault+12172>, 0x4abf9c <_PyEval_EvalFrameDefault+828>, 
          0x4b1690 <_PyEval_EvalFrameDefault+23088>, 0x4b273c <_PyEval_EvalFrameDefault+27356>, 
          0x4b0b18 <_PyEval_EvalFrameDefault+20152>, 0x4b2534 <_PyEval_EvalFrameDefault+26836>, 
          0x4adce0 <_PyEval_EvalFrameDefault+8320>, 0x4acc24 <_PyEval_EvalFrameDefault+4036>, 
          0x4b0354 <_PyEval_EvalFrameDefault+18164>, 0x4af634 <_PyEval_EvalFrameDefault+14804>, 
          0x4b0e58 <_PyEval_EvalFrameDefault+20984>, 0x4ac650 <_PyEval_EvalFrameDefault+2544>, 
          0x4ae8c8 <_PyEval_EvalFrameDefault+11368>, 0x4b1814 <_PyEval_EvalFrameDefault+23476>, 
          0x4b25b4 <_PyEval_EvalFrameDefault+26964>, 0x4af804 <_PyEval_EvalFrameDefault+15268>, 
          0x4b0584 <_PyEval_EvalFrameDefault+18724>, 0x4b1b84 <_PyEval_EvalFrameDefault+24356>, 
          0x4b20e0 <_PyEval_EvalFrameDefault+25728>, 0x4ae9b8 <_PyEval_EvalFrameDefault+11608>, 
          0x4ad490 <_PyEval_EvalFrameDefault+6192>, 0x4b9720 <_PyEval_EvalFrameDefault+56000> <repeats 74 times>, 
          0x4afcec <_PyEval_EvalFrameDefault+16524>}
#15 0x0000000000511724 in _PyEval_EvalFrame (throwflag=0, frame=0xfffff7ff35f8, tstate=0xa5ef70 <_PyRuntime+166344>)
    at ../Include/internal/pycore_ceval.h:73
No locals.
#16 _PyEval_Vector (kwnames=0x0, argcount=2, args=0xffffffffdeb8, locals=0x0, func=0xffffe2417f60, 
    tstate=0xa5ef70 <_PyRuntime+166344>) at ../Python/ceval.c:6439
        frame = 0xfffff7ff35f8
        retval = <optimized out>
        frame = <optimized out>
        retval = <optimized out>
        i = <optimized out>
        kwcount = <optimized out>
        i = <optimized out>
...
```

numba -s
```
System info:
--------------------------------------------------------------------------------
__Time Stamp__
Report started (local time)                   : 2023-07-29 03:05:11.315261
UTC start time                                : 2023-07-29 03:05:11.315275
Running time (s)                              : 1.500313

__Hardware Information__
Machine                                       : aarch64
CPU Name                                      : generic
CPU Count                                     : 4
Number of accessible CPUs                     : 4
List of accessible CPUs cores                 : 0-3
CFS Restrictions (CPUs worth of runtime)      : None

CPU Features                                  : fp-armv8 neon

Memory Total (MB)                             : 11954
Memory Available (MB)                         : 11236

__OS Information__
Platform Name                                 : Linux-5.10.0-23-arm64-aarch64-with-glibc2.37
Platform Release                              : 5.10.0-23-arm64
OS Name                                       : Linux
OS Version                                    : #1 SMP Debian 5.10.179-2 (2023-07-14)
OS Specific Version                           : ?
Libc Version                                  : glibc 2.37

__Python Information__
Python Compiler                               : GCC 12.2.0
Python Implementation                         : CPython
Python Version                                : 3.11.4
Python Locale                                 : en_US.UTF-8

__Numba Toolchain Versions__
Numba Version                                 : 0.57.1
llvmlite Version                              : 0.40.1

__LLVM Information__
LLVM Version                                  : 14.0.6

__CUDA Information__
CUDA Device Initialized                       : False
CUDA Driver Version                           : ?
CUDA Runtime Version                          : ?
CUDA NVIDIA Bindings Available                : ?
CUDA NVIDIA Bindings In Use                   : ?
CUDA Minor Version Compatibility Available    : ?
CUDA Minor Version Compatibility Needed       : ?
CUDA Minor Version Compatibility In Use       : ?
CUDA Detect Output:
None
CUDA Libraries Test Output:
None

__NumPy Information__
NumPy Version                                 : 1.24.2
NumPy Supported SIMD features                 : ('NEON', 'NEON_FP16', 'NEON_VFPV4', 'ASIMD')
NumPy Supported SIMD dispatch                 : ('ASIMDHP', 'ASIMDDP', 'ASIMDFHM')
NumPy Supported SIMD baseline                 : ('NEON', 'NEON_FP16', 'NEON_VFPV4', 'ASIMD')
NumPy AVX512_SKX support detected             : False

__SVML Information__
SVML State, config.USING_SVML                 : False
SVML Library Loaded                           : False
llvmlite Using SVML Patched LLVM              : False
SVML Operational                              : False

__Threading Layer Information__
TBB Threading Layer Available                 : False
+--> Disabled due to Unknown import problem.
OpenMP Threading Layer Available              : True
+-->Vendor: GNU
Workqueue Threading Layer Available           : True
+-->Workqueue imported successfully.

__Numba Environment Variable Information__
None found.

__Conda Information__
Conda not available.

__Installed Packages__
Package              Version
-------------------- ---------
alabaster            0.7.12
Babel                2.10.3
beniget              0.4.1
certifi              2022.9.24
chardet              5.1.0
charset-normalizer   3.2.0
colorama             0.4.6
decorator            5.1.1
devscripts           2.23.5
docutils             0.19
gast                 0.5.2
idna                 3.3
imagesize            1.4.1
Jinja2               3.1.2
llvmlite             0.40.1
MarkupSafe           2.1.3
numba                0.57.1
numpy                1.24.2
numpydoc             1.5.0
packaging            23.1
pip                  23.2
ply                  3.11
Pygments             2.15.1
pythran              0.11.0
pytz                 2023.3
requests             2.31.0
roman                3.3
scipy                1.10.1
setuptools           68.0.0
six                  1.16.0
snowballstemmer      2.2.0
Sphinx               5.3.0
sphinx-rtd-theme     1.2.2
sphinxcontrib-jquery 4.1
urllib3              1.26.16
wheel                0.38.4

No errors reported.


__Warning log__
Warning (cuda): CUDA driver library cannot be found or no CUDA enabled devices are present.
Exception class: <class 'numba.cuda.cudadrv.error.CudaSupportError'>
Warning: Conda not available.
 Error was [Errno 2] No such file or directory: 'conda'

Warning (psutil): psutil cannot be imported. For more accuracy, consider installing it.
Warning (no file): /sys/fs/cgroup/cpuacct/cpu.cfs_quota_us
Warning (no file): /sys/fs/cgroup/cpuacct/cpu.cfs_period_us
--------------------------------------------------------------------------------
If requested, please copy and paste the information between
the dashed (----) lines, or from a given specific section as
appropriate.

=============================================================
IMPORTANT: Please ensure that you are happy with sharing the
contents of the information present, any information that you
wish to keep private you should remove before sharing.
=============================================================
```
user: detrout
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_9106: state: open
title: CUDA: Add overloads generated by specialization to the current dispatcher.
body: Adding overloads to the current dispatcher when specializing saves recreating the overload for subsequent calls to the unspecialized dispatcher that would have used the overload.

This also has the side effects of making overloads available after a call to `ForAll()` on a dispatcher.

This provides an alternative to the implementation in #9057, which also aimed to make overloads available after a `ForAll()` call, but did it by changing the way `ForAll()` worked and potentially increasing latency for calls on specialized dispatchers (of which there are some use cases in cuDF).

Whilst looking into this I also noticed that all the CUDA dispatcher specialize tests worked in an "unexpected" way and didn't provide a good pattern to follow for this test added in this PR, so they are all fixed up in this PR too.
user: gmarkall
labels: 4 - Waiting on author: Waiting for author to respond to review
CUDA: CUDA related issue/PR
issue_9104: state: open
title: Ommited keyword argument can't be a literal
body: The following code, adapted from one of the numba example on literals raises an error. It results, from the attempt of defining one jitted interpolation function with several keyword arguments (cf https://github.com/EconForge/interpolation.py/issues/107)

```python
import numba

def power(x, n=2):
    raise NotImplementedError

@numba.extending.overload(power)
def ov_power(x, n=2):
    if isinstance(n, numba.types.Literal):
        # only if `n` is a literal
        if n.literal_value == 2:
            # special case: square
            print("square")
            def fun(x,n=2):
                return x * x
            return fun
        elif n.literal_value == 3:
            # special case: cubic
            print("cubic")
            def fun(x,n=2): # n=2, strange but logical
                return x * x * x
            return fun

    print("generic")
    def fun(x,n=3):
        
        return x ** n
    return fun

@numba.njit
def test_power(x, n=2):
    return power(x, n=numba.literally(n))

# should print "square" and "9": OK
print(test_power(3, n=2))

# should print "cubic" and "27": OK
print(test_power(3, n=3))

# Now call test_power without specify the value of n

print(test_power(3))   #: Error
```

The  error ends in
```
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pablo/.cache/pypoetry/virtualenvs/interpolation-cFe3xpnh-py3.11/lib/python3.11/site-packages/numba/core/types/misc.py", line 69, in literal
    ctor = Literal.ctor_map[ty]
           ~~~~~~~~~~~~~~~~^^^^
KeyError: <class 'numba.core.dispatcher.OmittedArg'>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pablo/Econforge/interpolation.py/literal.py", line 41, in <module>
    print(test_power(3))   #: Error
          ^^^^^^^^^^^^^
  File "/home/pablo/.cache/pypoetry/virtualenvs/interpolation-cFe3xpnh-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py", line 438, in _compile_for_args
    args = [(types.literal
           ^^^^^^^^^^^^^^^
  File "/home/pablo/.cache/pypoetry/virtualenvs/interpolation-cFe3xpnh-py3.11/lib/python3.11/site-packages/numba/core/dispatcher.py", line 438, in <listcomp>
    args = [(types.literal
            ^^^^^^^^^^^^^^
  File "/home/pablo/.cache/pypoetry/virtualenvs/interpolation-cFe3xpnh-py3.11/lib/python3.11/site-packages/numba/core/types/misc.py", line 71, in literal
    raise LiteralTypingError("{} cannot be used as a literal".format(ty))
numba.core.errors.LiteralTypingError: <class 'numba.core.dispatcher.OmittedArg'> cannot be used as a literal
```


user: albop
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_9103: state: open
title: Potential memory leak? (Potentially related to `Generator` type)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Dear numba Team.

I am not sure whether I found an actual error or whether the error is on my side.
Therefore, I am sorry to disturb your work and take your time.

If I execute the code below, then the python process will slowly consume more and more memory until it eventually crashes.
Notice the program has an endless loop, but it does not explicitly allocate any new object.

Expectation: Program runs forever but does not consume excessive memory.

Observation: The memory consumption is ever-increasing (found with the `top` program).

Note: If I remove the `@numba.njit`, the memory consumption remains normal.


```python

from typing import Final

import numba  # type: ignore
import numpy as np
from numpy.random import Generator


@numba.njit
def swap_2_or_flip(random: Generator, dest: np.ndarray,
                   x: np.ndarray) -> None:
    """
    Copy `x` into `dest` and swap two different values or flip a sign.

    :param random: the random number generator
    :param dest: the array to receive the modified copy of `x`
    :param x: the existing point in the search space
    """
    dest[:] = x[:]  # First, we copy `x` to `dest`.
    length: Final[int] = len(dest)  # Get the length of `dest`.

    i1: Final[int] = random.integers(0, length)  # first random index.
    v1: Final = dest[i1]  # Get the value at the first index.

    if random.integers(0, 2) == 0:  # With p=0.5, we flip the sign of v1.
        dest[i1] = -v1  # Flip the sign of v1 and store it back at i1.
        return  # Quit.

# Swap two values. Now, normally we would repeat the loop until we find a
# different value. However, if we have signed permutations, it may be
# possible that all values currently are the same. To avoid an endless loop,
# we therefore use a sufficiently large range.
    for _ in range(10 + length):
        i2: int = random.integers(0, length)  # Get the second random index.
        v2 = dest[i2]  # Get the value at the second index.
        if v1 != v2:  # If both values different...
            dest[i2] = v1  # store v1 where v2 was
            dest[i1] = v2  # store v2 where v1 was
            return  # Exit function: we are finished.
    # If we get here, probably all elements are the same, so we just...
    dest[i1] = -v1  # ...flip the sign of v1 and store it back at i1.


rand = np.random.default_rng(10)
xx = np.array(range(10), int)
out = np.empty(len(xx), int)

while True:
    swap_2_or_flip(rand, out, xx)
```

Interestingly, the same issue (increased memory consumption) still happens if I just do

```python
import numba  # type: ignore
import numpy as np
from numpy.random import Generator


@numba.njit
def swap_2_or_flip(random: Generator, dest: np.ndarray,
                   x: np.ndarray) -> None:
    i = len(dest)

rand = np.random.default_rng(10)
xx = np.array(range(10), int)
out = np.empty(len(xx), int)

while True:
    swap_2_or_flip(rand, out, xx)
```

It stops happening if I do:

```python
import numba  # type: ignore
import numpy as np
from numpy.random import Generator


@numba.njit
def swap_2_or_flip(dest: np.ndarray,
                   x: np.ndarray) -> None:
    i = len(dest)

rand = np.random.default_rng(10)
xx = np.array(range(10), int)
out = np.empty(len(xx), int)

while True:
    swap_2_or_flip(out, xx)
```

Therefore, I think, the problem *might* be related to the `Generator` type?


Here you can find the versions of libraries potentially related to the issue:

```
numpy 1.24.4
numba 0.57.1
intel-cmplr-lib-rt 2023.2.0
matplotlib 3.7.2
psutil 5.9.5
scikit-learn 1.3.0
scipy 1.11.1
```

My Ubuntu Linux system information is as follows:

```
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.2 LTS
Release:	22.04
Codename:	jammy

os.name: Linux
os.release: 5.19.0-50-generic
os.version: 50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023
```

My python version is as follows:

```
Python 3.10.6
python.version: 3.10.6 (main, May 29 2023, 11:10:38) [GCC 11.3.0]
python.implementation: CPython
```

Other software versions are:

```
gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

Again, I am not sure whether any of this is relevant or whether the mistake is on my side.

All the best,
   Thomas.

[bug.zip](https://github.com/numba/numba/files/12190661/bug.zip)

user: thomasWeise
labels: bug - memory leak: Memory leak
issue_9098: state: open
title: tuple of tuple arguments not allowed in parfor loop
body: The following code

```python
import numpy as np
import numba as nb
from numba import prange

@nb.jit
def my_fun(vals, grid, coef, x):
    return vals[0] + coef[0] + x[0] # + grid[0][0]

@nb.jit(nopython=True, parallel=True)
def run_in_pfor(vals, grid, coef, x):
    t = 0.0
    for h in prange(6):
        res = my_fun(vals, grid, coef, x)
        t += res
    return t

vals = np.random.rand(5)
grid = ((0., 1., 5),)
coef = vals.copy()
x = np.array([0.22])
run_in_pfor(vals, grid, coef, x)
```

raises an exception ending in

```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native parfor lowering)
scalar type Tuple(float64, float64, int64) given for non scalar argument #3

File "notuple.py", line 12:
def run_in_pfor(vals, grid, coef, x):
    <source elided>
    t = 0.0
    for h in prange(6):
    ^

During: lowering "id=0[LoopNest(index_variable = parfor_index.6, range = (0, $const20.3, 1))]{40: <ir.Block at /home/pablo/Econforge/interpolation.py/notuple.py (12)>}Var(parfor_index.6, notuple.py:12)" at /home/pablo/Econforge/interpolation.py/notuple.py (12)
```
full stacktrace attached : [stacktrace.txt](https://github.com/numba/numba/files/12181997/stacktrace.txt) .


If I replace `grid = ((0., 1., 5),)` by `grid = (0., 1., 5)` it works (it is not used by the function anyway).




user: albop
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_9097: state: open
title: Dispatch error
body: Under some conditions, the dispatch behavior of a function defined with overload seems unpredictible. Issue was initially raised here: https://github.com/EconForge/interpolation.py/issues/104. 
It can be replicated with the two attached files (run   `error.py` which calls some functions defined in `source.py`). Both are compressed in [bug.zip](https://github.com/numba/numba/files/12181883/bug.zip)

To summarize, error.py contains the following loop:

```python
import numpy as np
from source import eval_linear

grid = (np.linspace(0, 10, 11), np.linspace(0, 10, 11))
z1 = np.random.randn(11,11)
z1z2 = np.random.randn(11,11,2)
LINEAR = ((None,), (None,) * 2)  # a constant used for dispatching only

npoints = 300
eval_points = np.column_stack([np.linspace(0, 10, npoints)]*2)

for i in range(1000):

    z1_eval = eval_linear( grid,  z1,  eval_points, LINEAR )
    try:
        assert(z1_eval.shape == (npoints,))
    except Exception as e:
        print(f"Failed in iteration {i}")
        raise(e)

    z1z2_eval = eval_linear( grid,  z1z2, eval_points,  LINEAR)
    try:
        assert(z1z2_eval.shape == (npoints,2))
    except Exception as e:
        print(f"Failed in iteration {i}")
        raise(e)
```

In that loop, `eval_linear` is a nopython jitted function which returns a vector in the first call when z1 is a 2d array (values on the 2d grid to interpolate) but returns a matrix in the second call where z1z2 is a 3d array (vector -values on the 2d grid).

When iterating long enough I always get an error but not always for the same call, with the function returning the wrong type of output. For instance:

```
Failed in iteration 129
Traceback (most recent call last):
  File "/home/pablo/Econforge/interpolation.py/error_min.py", line 26, in <module>
    raise(e)
  File "/home/pablo/Econforge/interpolation.py/error_min.py", line 23, in <module>
    assert(z1z2_eval.shape == (npoints,2))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
```

The original definition of `eval_linear` comes from the interpolation.py library. I tried to reproduce a simplified version of it in the file `source.py`. The definition is somewhat convoluted (and certainly suboptimal), because:
- a function `eval_spline` does many different things based on the kind of (keyword) arguments it get. In the original library code gets generated. Here I included here just the two combinations needed for the example.
- a function `eval_linear` calls the former one with one of the arguments `k` being equal to 1. For compatibility purpose it also dispatches on positional argument `extrap_mode` whose type is the only thing that matters.

The function eval_linear seems to work well as long as it is not called too many times with different kinds of arguments...

What I have tried so far:
- make a nonjitted version to check whether the algorithmic code does out of bounds access (it does not)
- remove the last argument `LINEAR` in the call.  Error goes away (but then it's not what I want)
- replace the call in the loop by: `eval_spline(grid, C, points, out=None, k=1, diff="None", extrap_mode="linear")`. No problem as long as all the arguments are specified (which is another issue I plan to adress afterwards).

I've got no idea how to investigate it further but am happy to follow any advice.
user: albop
labels: bug - miscompile: Bugs: miscompile
issue_9084: state: open
title: CUDA kernels should not make const copies of global and closure variables
body: Noted whilst investigating https://numba.discourse.group/t/avoid-multiple-copies-of-large-numpy-array-in-closure/2017

In many cases Numba will copy global and closure variables as constant arrays inside jitted functions and kernels (and will always attempt to do this for kernels). This is a problem because const memory is extremely limited in CUDA. The following simple example:

```python
import numpy as np

N = 100000
closed_array = np.ones(N)

@cuda.jit(cache=True)
def kernel(r, x):
    r[0] = closed_array[x]

r = np.zeros(1)

kernel[1, 1](r, 2)
print(r[0])
```

will fail with the error:

```
numba.cuda.cudadrv.driver.LinkerError: [218] Call to cuLinkAddData results in CUDA_ERROR_INVALID_PTX
ptxas error   : File uses too much global constant data (0xc3500 bytes, 0x10000 max)
```

Since we have [a mechanism for users to specify when a const array should be created](https://numba.readthedocs.io/en/stable/cuda/memory.html#constant-memory), constant arrays should never be implicitly created in CUDA kernels, and they should always be opted-in to. Making this change will not be a breaking change, because Numba makes no guarantee about whether a copy is made or not: https://numba.readthedocs.io/en/stable/reference/pysemantics.html#global-and-closure-variables

> Numba may or may not copy global variables referenced inside a compiled function.

The following change provides a proof-of-concept that demonstrates creating references to arrays instead of const copies:

```diff
diff --git a/numba/core/base.py b/numba/core/base.py
index 1c0a5ee5a..0728a731e 100644
--- a/numba/core/base.py
+++ b/numba/core/base.py
@@ -1086,7 +1086,7 @@ class BaseContext(object):
         llvoidptr = self.get_value_type(types.voidptr)
         addr = self.get_constant(types.uintp, intaddr).inttoptr(llvoidptr)
         # Use a unique name by embedding the address value
-        symname = 'numba.dynamic.globals.{:x}'.format(intaddr)
+        symname = 'numba_dynamic_globals_{:x}'.format(intaddr)
         gv = cgutils.add_global_variable(mod, llvoidptr, symname)
         # Use linkonce linkage to allow merging with other GV of the same name.
         # And, avoid optimization from assuming its value.
diff --git a/numba/cuda/target.py b/numba/cuda/target.py
index 492f375f6..7b44da626 100644
--- a/numba/cuda/target.py
+++ b/numba/cuda/target.py
@@ -69,6 +69,7 @@ VALID_CHARS = re.compile(r'[^a-z0-9]', re.I)
 class CUDATargetContext(BaseContext):
     implement_powi_as_math_call = True
     strict_alignment = True
+    allow_dynamic_globals = True
 
     def __init__(self, typingctx, target='cuda'):
         super().__init__(typingctx, target)
@@ -292,43 +293,20 @@ class CUDATargetContext(BaseContext):
         Unlike the parent version.  This returns a a pointer in the constant
         addrspace.
         """
-
-        lmod = builder.module
-
-        constvals = [
-            self.get_constant(types.byte, i)
-            for i in iter(arr.tobytes(order='A'))
-        ]
-        constaryty = ir.ArrayType(ir.IntType(8), len(constvals))
-        constary = ir.Constant(constaryty, constvals)
-
-        addrspace = nvvm.ADDRSPACE_CONSTANT
-        gv = cgutils.add_global_variable(lmod, constary.type, "_cudapy_cmem",
-                                         addrspace=addrspace)
-        gv.linkage = 'internal'
-        gv.global_constant = True
-        gv.initializer = constary
-
-        # Preserve the underlying alignment
-        lldtype = self.get_data_type(aryty.dtype)
-        align = self.get_abi_sizeof(lldtype)
-        gv.align = 2 ** (align - 1).bit_length()
-
-        # Convert to generic address-space
-        ptrty = ir.PointerType(ir.IntType(8))
-        genptr = builder.addrspacecast(gv, ptrty, 'generic')
-
         # Create array object
-        ary = self.make_array(aryty)(self, builder)
+        dataptr = arr.device_ctypes_pointer.value
+        data = self.add_dynamic_addr(builder, dataptr, info=str(type(dataptr)))
+        rt_addr = self.add_dynamic_addr(builder, id(arr), info=str(type(arr)))
         kshape = [self.get_constant(types.intp, s) for s in arr.shape]
         kstrides = [self.get_constant(types.intp, s) for s in arr.strides]
-        self.populate_array(ary, data=builder.bitcast(genptr, ary.data.type),
+        cary = self.make_array(aryty)(self, builder)
+        self.populate_array(cary, data=builder.bitcast(data, cary.data.type),
                             shape=kshape,
                             strides=kstrides,
-                            itemsize=ary.itemsize, parent=ary.parent,
+                            itemsize=arr.dtype.itemsize, parent=rt_addr,
                             meminfo=None)
 
-        return ary._getvalue()
+        return cary._getvalue()
 
     def insert_const_string(self, mod, string):
         """
```

This does require the example to be modified so that the data is already on the device:

```python
from numba import cuda
import numpy as np

N = 100000
closed_array = cuda.to_device(np.ones(N))

@cuda.jit(cache=True)
def kernel(r, x):
    r[0] = closed_array[x]

r = np.zeros(1)

kernel[1, 1](r, 2)
print(r[0])
```

And now works as expected:

```
$ python repro.py 
1.0
```

To complete the implementation, the following considerations need to be addressed:

- Caching needs to be disabled for kernels with references to globals and closure variables. The docstring for `BaseContext.add_dynamic_addr()` suggests that addition of a dynamic address will disable caching, but this does not seem to be the case for CUDA at least.
- Making copies of data to / from the device at launch time for global and closure variables on the host needs to be considered.
- CUDA documentation should clarify that const copies are never automatically made, and indicate the const array constructor for their explicit construction.
- Tests need to be added for both global and closure variable cases
- Any other memory management considerations as required (e.g. across multiple devices, avoidance of leaks when making implicit copies from the host, etc.)
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_9080: state: open
title: f-string serializes the wrong message if argument is a container
body: Reproducer
```python
from numba import njit
import numpy as np

@njit
def foo(a, b):
    print(f'message {a} - {b}')

a = (1, 2)
b = [1, 2]
foo(a, b)
# message <object type:UniTuple(int64 x 2)> - <object type:reflected list(int64)<iv=None>>
```

xref: https://github.com/numba/numba/pull/9076#discussion_r1265427591
user: guilhermeleobas
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_9076: state: open
title: Add shape context to slicing errors
body: Hi, just wanted this as I got these errors today and could not figure why this was the case.

Seeing also as this is not an error many people seem to encounter (see picture), I found help difficult to find.
![image](https://github.com/numba/numba/assets/25065744/95534268-d6fa-4893-ac56-ca34da4e942c)

If any unit tests are necessary, I would need some help
user: kklocker
labels: Effort - medium: Medium size effort needed
4 - Waiting on second reviewer: Patch needs a second reviewer.
issue_9064: state: open
title: Implement pointer casting intrinsic
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

It would be great to add an intrinsic for casting pointers into anything. The use case is e.g. implementing c-callbacks of the `...(..., *void)` variety, which is a very common pattern.

This function below is mentioned in the doc PR #8443 . I think similar implementations are also mentioned in the forum here an there.

```python
 from numba.extending import intrinsic
 from numba import types
 
 @intrinsic
 def cast_ptr(_typingctx, input_ptr, ptr_type):
     def impl(context, builder, _signature, args):
         llvm_type = context.get_value_type(target_type)
         val = builder.bitcast(args[0], llvm_type)
         return val
     if isinstance(ptr_type, types.TypeRef):
         target_type = ptr_type.instance_type
     else:
         target_type = ptr_type
     sig = target_type(input_ptr, ptr_type)
     return sig, impl
```
user: adam-urbanczyk
issue_9060: state: open
title: Convert Numba to use `pyproject.toml`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Convert Numba to use `pyproject.toml` instead of `setup.py`

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: esc
issue_9045: state: open
title: Docs should be updated for CUDA 12
body: The [current installation docs](https://numba.pydata.org/numba-doc/latest/cuda/overview.html#software) only mention `cudatoolkit` should be installed. However, CUDA 12 changes the way packages are organized and Numba should now require `cuda-nvcc=12.x` and I believe `cuda-version=12.x` too. Particularly, without `cuda-nvcc=12.x` installed, one might encounter errors such as:

```python
Traceback (most recent call last):
  File "<string>", line 7, in <module>
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/cuda/cudadrv/runtime.py", line 111, in get_version
    self.cudaRuntimeGetVersion(ctypes.byref(rtver))
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/cuda/cudadrv/runtime.py", line 65, in __getattr__
    self._initialize()
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/cuda/cudadrv/runtime.py", line 51, in _initialize
    self.lib = open_cudalib('cudart')
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/cuda/cudadrv/libs.py", line 63, in open_cudalib
    path = get_cudalib(lib)
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/cuda/cudadrv/libs.py", line 55, in get_cudalib
    libdir = get_cuda_paths()[dir_type].info
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/cuda/cuda_paths.py", line 223, in get_cuda_paths
    'nvvm': _get_nvvm_path(),
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/cuda/cuda_paths.py", line 201, in _get_nvvm_path
    candidates = find_lib('nvvm', path)
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/misc/findlib.py", line 44, in find_lib
    return find_file(regex, libdir)
  File "/opt/conda/envs/test/lib/python3.10/site-packages/numba/misc/findlib.py", line 56, in find_file
    entries = os.listdir(ldir)
FileNotFoundError: [Errno 2] No such file or directory: '/opt/conda/envs/test/nvvm/lib64'
```

cc @jakirkham @gmarkall 
user: pentschev
labels: CUDA: CUDA related issue/PR
issue_9042: state: open
title: Preserve class __module__ of a jitclass instance
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

I want to use a [custom Dask serializer/deserializer](https://distributed.dask.org/en/stable/serialization.html#dask-serialization-family) with jitclass, but at the moment it is not possible because the `type()` of jitclass instance returns a type object with `__module__` set to `numba.experimental.jitclass.boxing`. 

```python
from numba import float64
from numba.experimental import jitclass

@jitclass([("value", float64)])
class Example:
    def __init__(self, value):
        self.value = value

instance = Example(0)

print("Class type:", Example)
# Class type: <class '__main__.Example'>

print("Instance type:", type(instance))
# Instance type: <class 'numba.experimental.jitclass.boxing.Example'>
```

If I register serializer for the class type, as shown in documentation, Dask can not find it when serializing an instance and using an instance type:

```python
from distributed.protocol import dask_deserialize, dask_serialize, deserialize, serialize

@dask_serialize.register(Example)
def serialize_example(example: Example) -> tuple[dict, list[bytes]]:
    args = (example.value,)
    return serialize(args)


@dask_deserialize.register(Example)
def deserialize_example(header: dict, frames: list[bytes]) -> Example:
    args = deserialize(header, frames)
    return Example(*args)


instance = Example(0)
serialize(instance)
```

```
distributed.protocol.pickle - ERROR - Failed to serialize <numba.experimental.jitclass.boxing.Example object at 0x7fe4ed1cdcc0>.
Traceback (most recent call last):
  File "/home/egor/.cache/pypoetry/virtualenvs/forctool-5SrdLVXS-py3.10/lib/python3.10/site-packages/distributed/protocol/pickle.py", line 63, in dumps
    result = pickle.dumps(x, **dump_kwargs)
TypeError: cannot pickle 'Example' object
``` 

And if I register serializer for the instance type, Dask fails to pickle this type object because there is no such class in `numba.experimental.jitclass.boxing` module:

```
_pickle.PicklingError: Can't pickle <class 'numba.experimental.jitclass.boxing.Example'>: attribute lookup Example on numba.experimental.jitclass.boxing failed
```

## Workaround

I managed to get it working by manually injecting a class into `numba.experimental.jitclass.boxing` module and using a modification of `dask` serializer that recovers the original class type and allows Dask to dispatch correctly:
```python
import pickle
from importlib import import_module
from typing import Type

from dask.utils import has_keyword, typename
from distributed.protocol.serialize import dask_deserialize, dask_serialize, register_serialization_family
from numba.core import errors
from numba.extending import as_numba_type


def dask_dumps(x, context=None):
    """Serialize object using the class-based registry"""
    typ = type(x)
    if typ.__module__ == "numba.experimental.jitclass.boxing":
        typ = getattr(import_module(typ.__module__), typ.__name__)
    type_name = typename(typ)
    try:
        dumps = dask_serialize.dispatch(typ)
    except TypeError:
        raise NotImplementedError(type_name)
    if has_keyword(dumps, "context"):
        sub_header, frames = dumps(x, context=context)
    else:
        sub_header, frames = dumps(x)

    header = {
        "sub-header": sub_header,
        "type": type_name,
        "type-serialized": pickle.dumps(typ),
        "serializer": "dask",
    }
    return header, frames


def dask_loads(header, frames):
    typ = pickle.loads(header["type-serialized"])
    loads = dask_deserialize.dispatch(typ)
    return loads(header["sub-header"], frames)


register_serialization_family("dask", dask_dumps, dask_loads)


def check_dask_serializable(x):
    if type(x) in (list, set, tuple) and len(x):
        return check_dask_serializable(next(iter(x)))
    elif type(x) is dict and len(x):
        return check_dask_serializable(next(iter(x.items()))[1])
    else:
        try:
            typ = type(x)
            if typ.__module__ == "numba.experimental.jitclass.boxing":
                typ = getattr(import_module(typ.__module__), typ.__name__)
            dask_serialize.dispatch(typ)
            return True
        except TypeError:
            pass
    return False


setattr(import_module("distributed.protocol.serialize"), "check_dask_serializable", check_dask_serializable)


def fix_dask_serialization(cls: Type) -> Type:
    try:
        as_numba_type(cls)
    except errors.TypingError:
        raise ValueError(f"{cls} is not a Numba type")

    setattr(import_module("numba.experimental.jitclass.boxing"), cls.__name__, cls)

    return cls

```

Usage:

```python
from distributed.protocol.serialize import deserialize, serialize
from numba import float64
from numba.experimental import jitclass

@fix_dask_serialization
@jitclass([("value", float64)])
class Example:
    def __init__(self, value):
        self.value = value

instance = Example(0)

assert deserialize(*serialize(instance)).value == instance.value
```

But I think that it needs to be fixed in Numba by passing a real module path from a jitclass decorator to the instances.
user: egormkn
issue_9038: state: open
title: performance difference between `enumerate(arr)` and `for i in range(len(arr))`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
from numba import njit
import numpy as np

@njit
def dist_cityblock_1(x, y):
    out = np.empty((len(x), len(y)))
    for i, xi in enumerate(x):
        out_r = out[i]
        for j, yj in enumerate(y):
            out_r[j] = abs(xi - yj)
    return out


@njit
def dist_cityblock_2(x, y):
    n = len(x)
    m = len(y)
    out = np.empty((n, m))
    for i in range(n):
        out_r = out[i]
        xi = x[i]
        for j in range(m):
            out_r[j] = abs(xi - y[j])
    return out
```
Above I have 2 different implementations of cityblock distance. The first one uses `enumerate` while the other one uses `range(len(array))`. 

We can observe a 2~3x speed difference:
```python
x = np.random.randn(100)
y = np.random.randn(120)

%timeit dist_cityblock_1(x, y)
# 6.11 µs ± 95 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
%timeit dist_cityblock_2(x, y)
# 2.46 µs ± 43.9 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
```

A baseline version:
```python
@njit
def dist_cityblock_3(x, y):
    out = np.empty((len(x), len(y)))
    for i, xi in enumerate(x):
        for j, yj in enumerate(y):
            out[i, j] = abs(xi - yj)
    return out

%timeit dist_cityblock_3(x, y)
# 6.06 µs ± 53.7 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
# validate:
assert np.array_equal(dist_cityblock_1(x, y), dist_cityblock_2(x, y)) & np.array_equal(
    dist_cityblock_1(x, y), dist_cityblock_3(x, y)
)
```
possibly related? #7753

```python
import numba

numba.__version__
# '0.57.0'
```

user: auderson
labels: performance: performance related issue
issue_9027: state: open
title: Cannot get numba to work on Raspberry Pi 4
body: **Describe the bug**
I try the first snippet of code from this link: https://numba.readthedocs.io/en/stable/user/5minguide.html
But it results in this error:
`LLVM ERROR: Symbol not found: __aeabi_unwind_cpp_pr0`


**To Reproduce**
OS:
```
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
```
Python 3.9 (manual install)
llvm version 11.0.1
Install requirements (scipy is installed from source, v1.8.1):
```
sudo apt-get install llvm -y
LLVM_CONFIG=/usr/bin/llvm-config pip install llvmlite
pip install librosa numpy<1.24 numba==0.56.4 (versions align with llvm 11.0)
```

Then try to execute the code snippet

```
from numba import jit
import numpy as np

x = np.arange(100).reshape(10, 10)

@jit(nopython=True) # Set "nopython" mode for best performance, equivalent to @njit
def go_fast(a): # Function is compiled to machine code when called the first time
    trace = 0.0
    for i in range(a.shape[0]):   # Numba likes loops
        trace += np.tanh(a[i, i]) # Numba likes NumPy functions
    return a + trace              # Numba likes NumPy broadcasting

print(go_fast(x))
```

**Expected behavior**
No error at least

```
import platform; print(platform.platform())
import sys; print("Python", sys.version)
import numpy; print("NumPy", numpy.__version__)
import scipy; print("SciPy", scipy.__version__)
import numba; print("numba", numba.__version__)
```
Versions:
Linux-6.1.21-v8+-aarch64-with-glibc2.31
Python 3.9.7 (default, Mar  5 2022, 10:26:12) 
[GCC 10.2.1 20210110]
NumPy 1.23.5
SciPy 1.8.1
numba 0.56.4

Do note that it was working on the RPi until last week. I had to perform an apt upgrade in order to install `certbot`. I am not keen on downgrading again, I prefer fixing the problem but I am stuck on what the root cause actually is.

user: ZlaTanskY
issue_9020: state: open
title: Fix #9008: memory leak in dispatcher.
body: Fixes #9008.

Dispatcher holding references to types in direct call to `typeof_pyval` outside of `compile_for_args` is causing memory leak.

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: sklam
issue_9018: state: open
title: Segmentation fault with generator function
body: I'm trying to jit-ing a function in nopython environment.
Find below the function definition.
```
@jit('int64[:](int64, int64)', nopython=True)
def numba_set_partitions_helper(n, k):
    if k == 1:
        yield np.zeros(n, dtype = np.int_)
    elif n == k:
        yield np.arange(n, dtype = np.int_)
    else:
        for p in numba_set_partitions_helper(n - 1, k - 1):
            yield np.append(0, p + 1)
        for p in numba_set_partitions_helper(n - 1, k):
            for i in range(k):
                yield np.append(i, p)
    return np.array([0], dtype=np.int_)
```
The output is.
```
Fatal Python error: Segmentation fault
```
user: krono-i2
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_9014: state: open
title: Change a bunch of var names created during lowering to start with a period.
body: Numba is supposed to use a convention that vars introduced during Numba passes start with $ and LLVM vars introduced during lowering start with a period.  There were a bunch of cases where vars introduced during lowering don't start with a period.  PyOMP relies on this convention.
user: DrTodd13
labels: 4 - Waiting on second reviewer: Patch needs a second reviewer.
issue_9013: state: open
title: Split find_top_level_loops into two functions.
body: The current function gets all the loops in the cfg and then filter the nested ones.  In pyomp, we have the need to filter top level loops but not from all the loops in the function but a certain set.  So, to act better as a compiler toolkit, I propose splitting this function as in the PR.  Since this is just a refactor I didn't add any tests.
user: DrTodd13
issue_9010: state: open
title: CUDA: support array copy similar to `np.copy`
body: Creating a copy of a device array is not trivial, and should be. A couple of current workarounds are:

```python
# Variant 1
@numba.vectorize(['float32(float32)'], target='cuda')
def copy(x):
    return x

# Variant 2
def copy_devarray(arr):
    new_arr = cuda.device_array_like(arr)
    new_arr[:] = arr
    return new_arr
```

Providing an implementation of something like `np.copy()`  and/or `np.array(copy=True)` would be a nicer solution to this problem.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_9008: state: open
title: Memory leak when passing string literal as an argument to a jitted function
body: As title says, when passing a literal string as an argument to a jitted function, it leaks memory.  I'm using numba 0.56.4 and python 3.10.6

Here is a working example to reproduce it

```
#!/usr/bin/env python3
import numpy as np
from numba import njit,version_info
import psutil,os
print(version_info,end="\n\n")
pythonProcess = psutil.Process(os.getpid())
def printMem():
    print("mem: %.2fM"%(float(pythonProcess.memory_info().rss)/1e6))


@njit
def leakfunction(string):
  return string

for _ in range(10):
   for _ in range(100000):
       leakfunction("test")
   printMem()
```

which produces the output

```
version_info(major=0, minor=56, patch=4, short=(0, 56), full=(0, 56, 4), string='0.56.4', tuple=('0', '56', '4'), git_revision=None)

mem: 134.29M
mem: 135.94M
mem: 136.84M
mem: 137.65M
mem: 138.46M
mem: 139.22M
mem: 140.03M
mem: 140.84M
mem: 141.65M
mem: 142.46M
```

user: tegonzalo
labels: bug - memory leak: Memory leak
issue_9002: state: open
title: PyOMP and Numba
body: ## Feature request

Dear Numba team,
Thank you for the wonderful tool. I found PyOMP (https://github.com/Python-for-HPC/PyOMP) tool which is quite interesting as it enhances multithreading implementation of numba. Neverthless  I cannot find in documentation if this project was merged with numba offical implementation. Is there plan to implement such a approach in numba  ?



user: raviapatel
issue_9001: state: open
title: Linux AArch64 RuntimeDyld relocation overflows (#8567 specific to Linux only)
body: I'm breaking out this issue from #8567 to avoid spamming everyone who participated in that issue with notifications as I add notes and debugging info. In summary, on Linux AArch64,

<details>
<summary>test_standalone.py</summary>

```python
import numpy as np
from nvidia.dali import pipeline_def
import nvidia.dali as dali
import nvidia.dali.fn as fn
import nvidia.dali.types as dali_types
from nvidia.dali.plugin.numba.fn.experimental import numba_function


def set_all_values_to_255_batch(out0, in0):
    out0[0][:] = 255


def set_all_values_to_255_sample(out0, in0):
    out0[:] = 255


def set_all_values_to_float_batch(out0, in0):
    out0[0][:] = 0.5


def set_all_values_to_float_sample(out0, in0):
    out0[:] = 0.5


def setup_change_out_shape(out_shape, in_shape):
    out0_shape = out_shape[0]
    in0_shape = in_shape[0]
    perm = [1, 2, 0]
    for sample_idx in range(len(out0_shape)):
        for d in range(len(perm)):
            out0_shape[sample_idx][d] = in0_shape[sample_idx][perm[d]]


def change_out_shape_batch(out0, in0):
    for sample_id in range(len(out0)):
        out0[sample_id][:] = 42


def change_out_shape_sample(out0, in0):
    out0[:] = 42


def get_data(shapes, dtype):
    return [np.empty(shape, dtype=dtype) for shape in shapes]


def get_data_zeros(shapes, dtype):
    return [np.zeros(shape, dtype=dtype) for shape in shapes]

@pipeline_def
def numba_func_pipe(shapes, dtype, run_fn=None, out_types=None, in_types=None,
                    outs_ndim=None, ins_ndim=None, setup_fn=None, batch_processing=None):
    data = fn.external_source(lambda: get_data(shapes, dtype), batch=True, device="cpu")
    return numba_function(
        data, run_fn=run_fn, out_types=out_types, in_types=in_types,
        outs_ndim=outs_ndim, ins_ndim=ins_ndim, setup_fn=setup_fn,
        batch_processing=batch_processing)


def _testimpl_numba_func(shapes, dtype, run_fn, out_types, in_types,
                         outs_ndim, ins_ndim, setup_fn, batch_processing, expected_out):
    batch_size = len(shapes)
    pipe = numba_func_pipe(
        batch_size=batch_size, num_threads=1, device_id=0,
        shapes=shapes, dtype=dtype,
        run_fn=run_fn, setup_fn=setup_fn, out_types=out_types,
        in_types=in_types, outs_ndim=outs_ndim, ins_ndim=ins_ndim,
        batch_processing=batch_processing)
    pipe.build()
    for _ in range(3):
        outs = pipe.run()
        for i in range(batch_size):
            out_arr = np.array(outs[0][i])
            assert np.array_equal(out_arr, expected_out[i])

def test_numba_func():
    # shape, dtype, run_fn, out_types,
    # in_types, out_ndim, in_ndim, setup_fn, batch_processing,
    # expected_out
    args = [
        ([(10, 10, 10)], np.uint8, set_all_values_to_255_batch, [dali_types.UINT8],
         [dali_types.UINT8], [3], [3], None, True,
         [np.full((10, 10, 10), 255, dtype=np.uint8)]),
        ([(10, 10, 10)], np.uint8, set_all_values_to_255_sample, [dali_types.UINT8],
         [dali_types.UINT8], [3], [3], None, None,
         [np.full((10, 10, 10), 255, dtype=np.uint8)]),
        ([(10, 10, 10)], np.float32, set_all_values_to_float_batch, [dali_types.FLOAT],
         [dali_types.FLOAT], [3], [3], None, True,
         [np.full((10, 10, 10), 0.5, dtype=np.float32)]),
        ([(10, 10, 10)], np.float32, set_all_values_to_float_sample, [dali_types.FLOAT],
         [dali_types.FLOAT], [3], [3], None, None,
         [np.full((10, 10, 10), 0.5, dtype=np.float32)]),
        ([(10, 20, 30), (20, 10, 30)], np.int64, change_out_shape_batch, [dali_types.INT64],
         [dali_types.INT64], [3], [3], setup_change_out_shape, True,
         [np.full((20, 30, 10), 42, dtype=np.int32),
          np.full((10, 30, 20), 42, dtype=np.int32)]),
        ([(10, 20, 30), (20, 10, 30)], np.int64, change_out_shape_sample, [dali_types.INT64],
         [dali_types.INT64], [3], [3], setup_change_out_shape, None,
         [np.full((20, 30, 10), 42, dtype=np.int32),
          np.full((10, 30, 20), 42, dtype=np.int32)]),
    ]

    for shape, dtype, run_fn, out_types, in_types, outs_ndim, ins_ndim, \
            setup_fn, batch_processing, expected_out in args:
        _testimpl_numba_func(
            shape, dtype, run_fn, out_types, in_types, outs_ndim, ins_ndim, \
            setup_fn, batch_processing, expected_out
        )

test_numba_func()
```

</details>

results in:

```
$ python test_standalone.py 
python: /root/miniconda3/envs/buildenv/conda-bld/llvmdev_1680642098205/work/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:507: void llvm::RuntimeDyldELF::resolveAArch64Relocation(const llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t): Assertion `isInt<33>(Result) && "overflow check failed for relocation"' failed.
Aborted (core dumped)
```
user: gmarkall
issue_8989: state: open
title: Spurious deep copies in inlining
body: ## Reporting a bug

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I recently profiled the compilation of some code in an effort be better understand where time is spent inside Numba. For my specific use case, I saw that the majority of compilation time was spent inside `deepcopy`. After some investigation, I figured out that those deep copies are associated with inlining. The code which produces these copies is here: https://github.com/numba/numba/blob/0b85096be667ed817a52f5989bf252bda552b8f1/numba/core/inline_closurecall.py#L371-L381

The problem (perhaps a bug, although I may have missed some subtlety) is that the first `deepcopy` (line 375) is followed by immediately discarding the contents of the body (line 376) and then repopulating it with additional deep copies (lines 377-379). It is this second set of copies that I am struggling to explain - surely those elements would already have been copied in the original `deepcopy` call?

The reason I am raising this is because inlining (specifically these deep copies) is currently dominating my compilation times. As an experiment, I commented out lines 376-379 and saw roughly an x2.5 speedup in compilation with no decrease in performance of the compiled code. Note that disabling inlining completely (by removing inline='always' in my code) typically results in 40% slower code in my specific use case (which is somewhat unexpected, but clearly inlining into the Numba IR helps LLVM optimize the code in some way).

To summarize: inlining produces many expensive deep copy operations - are they all necessary?
user: JSKenyon
labels: performance - compile time: Performance issue occurring at compile time.
issue_8984: state: open
title: Support @gufunc inside @jit
body: Allow guvectorize functions to be called from `@jit` decorated ones:

```python
import numpy as np
from numba import guvectorize, int64, njit

@guvectorize([(int64[:], int64, int64[:])], '(n),()->(n)')
def g(x, y, res):
    for i in range(x.shape[0]):
        res[i] = x[i] + y

@njit
def f(x, y, res):
    g(x, y, res)

x = np.arange(40, dtype='i8').reshape(4, 2, 5)
y = 100
res = np.zeros_like(x)
f(x, y, res)
```

TODO:
- [x] Support for `@gufunc` inside `@jit`
- [x] Dynamic gufuncs
- [x] Cast arguments
- [ ] function attributes (nin, nout, ...)
- [ ] Object mode. It doesn't seem that even @vectorize supports object mode.
- [x] Test cases
- [x] Check if any change breaks CUDA (g)ufuncs. It doesn't crash, but it is not supported :/
- [x] Documentation

user: guilhermeleobas
labels: 4 - Waiting on author: Waiting for author to respond to review
issue_8981: state: open
title: Ahead Of Time default parameters and default keyword arguments- method doesn't work as expected
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.



**Issue:**
The numba Ahead Of Time compiled methods don't accept default parameters as arguments. Additionally, keyword arguments is also not accepted as the method parameter. Instead, when calling the method, it returns the error:
```method_name expected``` **___number___** ```arguments, got 0.```

**Numba version= 0.57.0
Python version=3.10.0**

**Sample code:** Filename: **aot.py**

```
from numba.pycc import CC

cc = CC("float_aot")

@cc.export("float_mult", "f8(f8, f8)")
def float_mult(a=0.5, b=0.7):
     return a*b

#@cc.export("float_mult_omitted", "f8(Omitted(f8), Omitted(f8))")
#def float_mult_omitted(a=0.5, b=0.7):
 #    return a*b

 @cc.export("float_mult_optional", "f8(optional(f8), optional(f8))")
def float_mult_optional(a=0.5, b=0.7):
    return a*b

if __name__ == "__main__":
     cc.compile()
```

**Errors and solutions attempted:**
1. When signatures are defined as it is in the actual method or method accepts keyword arguments--> @cc.export("float_mult", "f8(f8, f8)")
```
In [3]: float_aot.float_mult()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[3], line 1
----> 1 float_aot.float_mult()

TypeError: float_mult expected 2 arguments, got 0
```

2. When signatures types are defined as ommitted--> @cc.export("float_mult_omitted", "f8(Omitted(f8), Omitted(f8))")
This code is commented in the sample code given as it fails to compile. Please uncomment and compile to replicate the following error.

```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function mul>) found for signature:

 >>> mul(class(float64), class(float64))

There are 14 candidate implementations:
  - Of which 12 did not match due to:
  Overload of function 'mul': File: <numerous>: Line N/A.
    With argument(s): '(class(float64), class(float64))':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'mul': File: unknown: Line unknown.
    With argument(s): '(class(float64), class(float64))':
   No match for registered cases:
    * (int64, int64) -> int64
    * (int64, uint64) -> int64
    * (uint64, int64) -> int64
    * (uint64, uint64) -> uint64
    * (float32, float32) -> float32
    * (float64, float64) -> float64
    * (complex64, complex64) -> complex64
    * (complex128, complex128) -> complex128

During: typing of intrinsic-call at /Users/p/aot.py (15)

File "aot.py", line 15:
def float_mult_omitted(a=0.5, b=0.7):
    return a*b
    ^
```


3. When signatures types are defined as optional numba type-->  @cc.export("float_mult_optional", "f8(optional(f8), optional(f8))")
```
In [4]: float_aot.float_mult_optional()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[4], line 1
----> 1 float_aot.float_mult_optional()

TypeError: float_mult_optional expected 2 arguments, got 0
```

**Expected Output:**
The method returns results successfully when numba Just In Time(JIT) compiler or vanilla python file is used.
**jit_file.py**
```
from numba import njit

@njit
def float_mult(a=0.5, b=0.7):
     return a*b

@njit
#def float_mult_omitted(a=0.5, b=0.7):
 #    return a*b

@njit
def float_mult_optional(a=0.5, b=0.7):
    return a*b

if __name__ == "__main__":
     cc.compile()
```

  ```
In [2]: jit_file.float_mult()
  Out[2]: 0.35
  
  In [3]: jit_file.float_mult(a=5, b=7)
  Out[3]: 35
```
user: SheharazSheik
labels: AOT: ahead of time compilation issue
bug - failure to compile: Bugs: failed to compile valid code
issue_8975: state: open
title: Numba RandomState overload fails with empty size
body: ## Reporting a bug


- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
import numpy as np
import numba

@numba.njit
def uniform():
    return np.random.uniform(0, 1, size=())

uniform()  # numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
```

user: ricardoV94
labels: good first issue: A good issue for a first time contributor
bug - incorrect behavior: Bugs: incorrect behavior
issue_8971: state: open
title: 2023 Q2-Q4 roadmap gantt chart for major tasks.
body: The following gantt chart includes:

- release schedule of dependency
- release schedule of Numba
- major tasks
- release schedule of packages support future Numba (temporarily named as "Numba++")

Maintenance tasks and low risk tasks are not included.

```mermaid
gantt
    title Numba Roadmap 2023 Q2-Q4
    axisFormat %Y-%m

    section Deps
    Python-3.12        :py312, 2023-10, 1w
    LLVM-16            :llvm16, 2023-03, 1w
    NumPy-1.25         :npy125, 2023-06, 1w
    LLVM-17            :llvm17, 2023-09, 1w
    NumPy-2.00         :npy20, 2024-01, 1w
    #LLVM-18            :llvm18, 2024-03, 1w
    #NumPy-2.10         :npy21, 2024-06, 1w

    section Releases
    Numba_0.57         :crit, nb057, 2023-05, 1w
    Numba_0.58         :crit, nb058, 2023-08, 1w
    Numba_0.59         :crit, nb059, 2023-11, 1w
    Numba_0.60         :crit, nb060, 2024-02, 1w
        
    section Tasks
    RVSDG-0.1          :active, rvsdg01, 2023-05, 8w
    NB_RVSDG_integrate :active, 2023-05, 8w
    OrcJIT             :active, 2023-05, 8w
    PIXIE              :active, pixie, 2023-05, 4w
    %% Numba Py3.12 upgrade
    Numba_py312        :nbpy312, after rvsdg01, 6w
    %% Remove ObjMode fallback
    Numba_rmObjMode    :nbrmObjMode, after nbpy312, 6w
    %% Work to support Numpy2.0 
    NB_NPY20           :nbnpy20, 2023-12, 8w
    
    section Numba++ Rel
    PIXIE-0.1          :pixie01, 2023-11, 1w
    Numba++AOT         :crit, 2024-01, 1w
    NIL-0.1            :nil01, 2024-02, 1w
```

- `Numba_rmObjMode` is work to remove compiler objectmode fallback behavior.
- `NB_NPY20` is work to support Numpy2.0. Including differentiating NumPy and Python integer types.

The schedule presented here is not a guarantee. Actual timing will change and the content will be updated periodically.
user: sklam
issue_8970: state: open
title: CUDA: allow the user to specify that a kernel will have low occupancy in the `@cuda.jit` decorator
body: Some kernels will need to be called with low occupancy in the context of a workflow, and there isn't always a sensible way to avoid this. It would be nice if the occupancy warning could be disabled on a kernel-by-kernel basis, something like:

```python
@cuda.jit(occupancy_warnings=False)
def k(...):
    ...
```

This observation comes from the changes in https://github.com/rapidsai/cudf/pull/13337, where we're having to suppress the occupancy warning in many individual places to avoid disabling it entirely for uses of Numba outside cuDF. E.g this comment: https://github.com/rapidsai/cudf/pull/13337#discussion_r1193830237
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_8966: state: open
title: Create nightly wheel builds
body: ## Feature request

I have a tool that depends on numba and as part of my CI I have a job/environment where I install nightly-build wheels of some upstream packages and run my tests.

```
          python -m pip install \
          --index-url https://pypi.anaconda.org/scipy-wheels-nightly/simple/ \
          --trusted-host pypi.anaconda.org \
          --no-deps --pre --upgrade \
          matplotlib \
          numpy \
          pandas \
          scipy; \
```

I'm wondering if this would be something numba could do?

Right now this environment always fails due to the released numba incompatibility with numpy `main`. I don't expect numba main to always or even often be compatible with numpy `main` but based on #8008 maybe that won't be as big a pain for numba in the future. My hope is that if I install the unstable version of numba I'll have an environment that succeeds at least sometimes. Additionally it should allow me to identify bugs in my numpy and numba usage before releases and file bug reports where appropriate.

I could install the necessary dependencies myself and build numba from source, but the custom llvmlite dependency scared me a little bit.
user: djhoese
issue_8960: state: open
title: Jupyter/Ipython Magic tools for Numba
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request
Hi, I'm working with @gmarkall as an intern on the Numba team at NVIDIA this summer. As a part of my internship, I would like to build some jupyter magic tools for Numba. I'd like to use this issue for discussion and to track my progress.

1. The first, is a annotation command similar to what Cython does that could display different parts of Numba's compilation pipeline. For example, calling `%%numba --annotate` could default to providing the Numba IR. We could also display the LLVM, the control flow graph (CFG) and for the CUDA target, the PTX / SASS. There's already support for providing the LLVM in an html file, but I'd like to extend it in the way I've described. I also would like to change how it's displayed in Jupyter (some CSS stuff mostly).
2. In addition, I'd also like to provide Numba users more insight into the type inference process. I could imagine if they use the magic command `%%numba --annotate --cfg --debug`, it could print out the IR and inferred types at every step of the type inference process. Essentially providing the user a better way to visualize the output when `NUMBA_DEBUG_TYPEINFER` is set. For example, the user could see
- What got updated at each step. Let the user navigate between the steps using the CFG of the IR.
- Why certain variables take particular types - for example, signed + unsigned int64 operations can result in a float64 - being able to pinpoint the step at which this occurs can help the user understand what happened.
- Why a unification error occurs - what two branches produced the typings for a value that then needs to be unified but can't. 
3. I could also work on other Jupyter magic commands for Numba related the the compilation pipeline. How else could I extend this?

I hope this is the right place for this. If not I'm happy to move it. Thanks for any advice or discussion.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: Matt711
labels: discussion: An issue requiring discussion
issue_8957: state: open
title: Seed not working with np.random.randint only if parallel=True
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Versions
```
python==3.10.11
numba==0.57.0
numpy==1.24.1
```

When using `np.random.randint` the numba seed only works correctly when not using `parallel=True`.

This works as expected, both arrays are the same.
```
from numba import jit
import numpy as np

@jit(nopython=True)
def seed(a):
    np.random.seed(a)

@jit(nopython=True, parallel=False)
def f(n):
    '''Numpy randint
    '''
    return np.random.randint(0, 20, size = n)

seed(1)
print(f(5)) -> [ 5 11 12  8  9]
seed(1)
print(f(5)) -> [ 5 11 12  8  9]
```

Once we put `parallel=True` the seed no longer works.
```
from numba import jit
import numpy as np

@jit(nopython=True)
def seed(a):
    np.random.seed(a)

@jit(nopython=True, parallel=True)
def f(n):
    '''Numpy randint
    '''
    return np.random.randint(0, 20, size = n)

seed(1)
print(f(5)) -> [ 5 11 14 18  9] # these numbers might differ since seed is not working
seed(1)
print(f(5)) -> [ 5 11  6  3 13] # these numbers might differ since seed is not working
```

**Expected behaviour:** both arrays should be the same.

user: marcpaga
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8954: state: open
title: Migrate gpuCI to RAPIDS Ops Github Actions + self-hosted runners
body: gpuCI is being retired in favour of self-hosted runners with Github Actions. This mean the CUDA CI needs to be migrated over to use it. A rough checklist of steps:

- [x] Present how the new system works and address any queries with Numba maintainers.
- [x] Add the rapids-runners and rapids-bot apps to the Numba organization:
  - https://github.com/apps/rapids-runners
  - https://github.com/apps/rapids-bot
- [ ] Create new Github Actions jobs to run on the RAPIDS self-hosted runners, make a PR and get it merged.
- [ ] Create another PR to remove the gpuCI config.

Other notes:

- RAPIDS Github Actions docs, for reference: https://docs.rapids.ai/resources/github-actions/
- We should the `linux-amd64-gpu-v100-latest-1` runners because they're the most commonly available to us.
- Using a mix of jobs with CUDA 11 and 12 images will be possible, so we'll be able to expand the versions we test with following the migration.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_8952: state: open
title: Support for PEP 585 and PEP 604
body: [PEP 585](https://peps.python.org/pep-0585/) allows subscribting standard collection types (e.g., tuple, list) rather than having to use the attributes in the typing module. Unfortunately numba's *as_numba_type* doesn't understand this.

    from typing import Tuple
    numba.extending.as_numba_type(Tuple[int, int])  # OK
    numba.extending.as_numba_type(tuple[int, int])  # Not OK (Python 3.9 required)

[PEP 604](https://peps.python.org/pep-0604/) allows using the pipe operator for union types. Same story however.

    from typing import Union
    numba.extending.as_numba_type(Union[int, None])  # OK
    numba.extending.as_numba_type(int | None)        # Not OK (Python 3.10 required)
user: TheBB
issue_8950: state: open
title: Type signature spelling for arguments with default values
body: Detail described in this disourse post: https://numba.discourse.group/t/how-to-spell-type-signatures-for-default-argument/1922?u=sklam

Proposal:

Non-None default arguments should use the expected type. 

```python
@njit("int16(int16, int16, optional(int16))")
def foo(x, y=2, z=None):
    ...
```
`y` is expected to be a `int16` in this case.

It's Numba internal details to generate the needed `omitted` types.

This spelling is preferred because it matches Python's typing annotation.

user: sklam
issue_8945: state: open
title: Support numpy.frombuffer keyword arguments: count and offset 
body: ## Feature request

I am attempting to speed up binary file handling code with numba which makes extensive use of the `numpy.frombuffer` function. The function inside numba doesn't match the function inside numpy as numpy allows for the keyword arguments `offset`, specifying a starting byte in the buffer, and `count` the number of objects to pull out of the buffer. 

Doc reference: https://numpy.org/doc/stable/reference/generated/numpy.frombuffer.html
user: gregoryfdel
labels: good second issue: A good issue for second time contributors
issue_8943: state: open
title: zip(..., strict=True) not supported yet
body: ## Feature request
The new zip(..., strict=True) feature of Python 3.10 is very convenient to improve the robustness of loops:
https://peps.python.org/pep-0618/

It is not implemented yet in Numba:
https://github.com/numba/numba/blob/08a514b128132a53f99ad104a03a9ce331e97588/numba/core/typing/builtins.py#L1061
user: dmoklaf
issue_8942: state: open
title: Support set(<type>) in numba typed dictionaries?
body: Hi! I am playing around with getting dask to scale to a large number of input partitions (>200k) on large task graphs (> 5k layers).
I've almost got it but the missing piece is being able to return a dict that has values which are sets.

Right now part of the solution looks like:
```python3
import numba as nb

_coords_kernel_input_type = nb.types.Set(nb.types.UniTuple(nb.types.int64, 1), reflected=True)
_coords_kernel_keyval_type = nb.types.Tuple([nb.types.unicode_type, nb.types.int64])
_coords_kernel_return_type = nb.types.DictType(
    _coords_kernel_keyval_type,
    _coords_kernel_keyval_type,
)

@nb.jit(_coords_kernel_return_type(_coords_kernel_input_type, nb.types.unicode_type, nb.types.unicode_type), nopython=True)
def _coords_single_input_kernel(output_blocks, output_key, index_key):
    output = nb.typed.Dict.empty(
        _coords_kernel_keyval_type,
        _coords_kernel_keyval_type,
    )
    for out_coord in output_blocks:
        output[(output_key, out_coord[0])] = (index_key, out_coord[0])
    return output
```

The real solution would look like:
```python3
import numba as nb

_coords_kernel_input_type = nb.types.Set(nb.types.UniTuple(nb.types.int64, 1), reflected=True)
_coords_kernel_keyval_type = nb.types.Tuple([nb.types.unicode_type, nb.types.int64])
_coords_kernel_return_type = nb.types.DictType(
    _coords_kernel_keyval_type,
    nb.types.Set(_coords_kernel_keyval_type),
)

@nb.jit(_coords_kernel_return_type(_coords_kernel_input_type, nb.types.unicode_type, nb.types.unicode_type), nopython=True)
def _coords_single_input_kernel(output_blocks, output_key, index_key):
    output = nb.typed.Dict.empty(
        _coords_kernel_keyval_type,
        nb.types.Set(_coords_kernel_keyval_type),
    )
    for out_coord in output_blocks:
        output[(output_key, out_coord[0])] = {(index_key, out_coord[0])}
    return output
```

But right now that raises an exception because sets and lists are not allow within dicts due to this sentry: https://github.com/numba/numba/blob/main/numba/core/types/containers.py#L719
user: lgray
issue_8941: state: open
title: Checklist of deferred items from Advanced Indexing PRs
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

As titled, 

This PR highlights items that were discovered during the PR review process of #8491 but were deferred to subsequent PRs because their scope exceeds a single PR:

- [ ] Testing/investigating indexing failures in cases where NRT is not available in context (for instance CUDA) (See https://github.com/numba/numba/pull/8491#discussion_r1185176323)
- [ ] Investigate in what cases, in practice, do Numba array constructs share memory and how does it affect Advanced Indexing (See https://github.com/numba/numba/pull/8491#discussion_r1185184606)
- [ ] The functions `flat_imp_copy` and `flat_imp_nocopy` being used in Advanced Indexing implementations need to moved to a global level  to avoid recompilation every time advanced indexing is invoked.  (See https://github.com/numba/numba/pull/8491#discussion_r1181704457)
- [ ] During testing of Advanced Indexing, the arrays that are differently ordered in NumPy won't necessarily be classified as the same order in Numba, so that needs an appropriate fix to make sure we're testing for differently ordered arrays as required. (See https://github.com/numba/numba/pull/8491#discussion_r1185200793) 

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: kc611
issue_8934: state: open
title: jitclass reflected dunder methods do not work in a njit function
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
This was tested on 0.57.0rc1 with PR #8906 applied locally.

The reflected dunder methods are not considered when compiling a function that uses a jitclass object. They are used when a jitclass method is called via the interpreter. 

```
import numba

@numba.experimental.jitclass([("value", numba.types.float64),])
class ValueHolder:
    def __init__(self, v):
        self. Value = v
   
    def __radd__(self, lhs):
        return ValueHolder(lhs + self. Value)
    
def on_the_right():
    v = ValueHolder(1.0)
    return 1.0 + v


on_the_right().value  # == 2.0

numba.njit(on_the_right)().value   # fail!
```
```
Traceback (most recent call last):
  File "C:\Users\nate\OneDrive\Documents\numba_issue.py", line 18, in <module>
    numba.njit(on_the_right)().value   # fail!
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\nate\miniconda3\envs\numbarc\Lib\site-packages\numba\core\dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\nate\miniconda3\envs\numbarc\Lib\site-packages\numba\core\dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function add>) found for signature:

 >>> add(float64, instance.jitclass.ValueHolder#183f93a2450<value:float64>)

There are 20 candidate implementations:
  - Of which 18 did not match due to:
  Overload of function 'add': File: <numerous>: Line N/A.
    With argument(s): '(float64, instance.jitclass.ValueHolder#183f93a2450<value:float64>)':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'add': File: unknown: Line unknown.
    With argument(s): '(float64, instance.jitclass.ValueHolder#183f93a2450<value:float64>)':
   No match for registered cases:
    * (int64, int64) -> int64
    * (int64, uint64) -> int64
    * (uint64, int64) -> int64
    * (uint64, uint64) -> uint64
    * (float32, float32) -> float32
    * (float64, float64) -> float64
    * (complex64, complex64) -> complex64
    * (complex128, complex128) -> complex128

During: typing of intrinsic-call at C:\Users\nate\OneDrive\Documents\numba_issue.py (13)

File "numba_issue.py", line 13:
def on_the_right():
    <source elided>
    v = ValueHolder(1.0)
    return 1.0 + v
```

This can be worked around by implementing operator.add for the jitclass.
```
@numba.extending.overload(operator.add)
def _fix_radd(lhs, rhs):
    if isinstance(lhs, (numba.types.Integer, numba.types.Float)) and rhs == numba.extending.as_numba_type(ValueHolder):
        return lambda lhs, rhs: rhs.__radd__(lhs)
```
user: nathanmoore
issue_8920: state: open
title: Migrate code base towards objmode fallback removal
body: As title. This tracks migration of the test suite (and Numba) towards the point where use of `@jit` without specifying `nopython=True` and "object mode fallback" are removed. Current notes on this from a maintainers' meeting:
* No new tests using `@jit` or relying on/testing object mode fallback are permitted. Use `@njit`.
* Need to write some tests/do some exploration around how to directly "spell" into `@jit` kwargs various scenarios that can happen with objmode fallback.
user: stuartarchibald
issue_8913: state: open
title: test failed
body: Hi, I installed numba and ran some tests and test_parallel_backend.py throws a lot of assertion errors

```
============================================================================================= short test summary info =============================================================================================
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_guvectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_guvectorize_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_jit_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_jit_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_mix_use_masks_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_mix_use_masks_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_mix_use_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_mix_use_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_vectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_fork_concurrent_vectorize_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_guvectorize_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_guvectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_guvectorize_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_jit_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_jit_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_jit_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_mix_use_masks_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_mix_use_masks_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_mix_use_masks_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_mix_use_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_mix_use_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_mix_use_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_vectorize_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_vectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_forkserver_concurrent_vectorize_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_guvectorize_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_guvectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_guvectorize_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_jit_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_jit_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_jit_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_mix_use_masks_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_mix_use_masks_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_mix_use_masks_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_mix_use_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_mix_use_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_mix_use_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_vectorize_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_vectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_multiprocessing_spawn_concurrent_vectorize_workqueue - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_random_concurrent_guvectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_random_concurrent_jit_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_random_concurrent_mix_use_masks_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_random_concurrent_mix_use_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_random_concurrent_vectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_guvectorize_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_guvectorize_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_jit_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_jit_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_mix_use_masks_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_mix_use_masks_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_mix_use_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_mix_use_tbb - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_vectorize_omp - AssertionError: process failed with code 1: stderr follows
FAILED numba/tests/test_parallel_backend.py::TestSpecificBackend::test_threading_concurrent_vectorize_tbb - AssertionError: process failed with code 1: stderr follows
======================================================================== 55 failed, 23 passed, 26 skipped, 2 warnings in 101.67s (0:01:41) ========================================================================
```
More detailed logs are atatched
[test.log](https://github.com/numba/numba/files/11305992/test.log)

I installed numba from pip, and took the "tests" folder from the source tar ball, placed it in a directory ~/numba/numba and ran the test from the ~/numba folder with
```
pytest -v numba/tests/test_parallel_backend.py

```
Running the tests this way most other tests I have tried passed.


numba 0.56.4, numpy 1.23.5, python 3.10.9, OS is Ubuntu 22.04
user: beew
labels: no action required: No action was needed to resolve.
installation: issue with installation
issue_8904: state: open
title: IndexError and TypeError when overloading a function with keyword-only arguments
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

(Sorry for my bad english. I also never wrote any github bug report so I'm gonna be trying to be as descriptive and precise as I can)
For a project, I had to overload a function taking a keyword-only argument and couldn't get it to work. I therefore decided to do some basic testing and discovered that overloading a function taking one(or more) keyword-only argument(s) seems to always raise an IndexError or a TypeError depending on the context.

Here's an exemple of code raising an IndexError:
```python
from numba.extending import overload
from numba import types
import numba

def f(a, *, b):
    return a + b

@overload(f)
def f_overload(a, *, b):
    def _f(a, *, b):
        return a + b
    return _f

@numba.jit(nopython=True)
def use_f():
    return f(3, b=5)

use_f()
```
This program raises the following error : 
```
Traceback (most recent call last):
  File "..\file.py", line 75, in <module>
    use_f()
  File "..\venv\lib\site-packages\numba\core\dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C..\venv\lib\site-packages\numba\core\dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function f at 0x000002728B1BECB0>) found for signature:
 
 >>> f(Literal[int](3), b=Literal[int](5))
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'f_overload': File: ..\..\..\file.py: Line 8.
    With argument(s): '(int64, b=int64)':
   Rejected as the implementation raised a specific error:
     IndexError: tuple index out of range
  raised from ..\venv\lib\site-packages\numba\core\typing\templates.py:218
```

The error comes from the `fold_arguments` function (in [templates.py](https://github.com/numba/numba/blob/be990a818c377408a1f41c37c7720bc2ba0fb89a/numba/core/typing/templates.py#L189)).
The line causing the error is the following :
```bind_kws[n] = args[len(kwonly) + idx]```
`args` is the tuple of positional arguments(`(Literal[int](3),)`) and `kwonly` is the dictionnary of keyword-only arguments (`{'b': Literal[int](5)}`)

I don't know much about numba internals (and I don't really know what this function does) but to me problem seems to be that numba thinks `args` contains the `kwonly` values and try to access them. As they aren't in `args`, numba is trying to access values outside of the tuple and python raises an IndexError.


This error disapears if there are enough positional arguments compared to the keyword-only arguments because every index it tries to access exists (my instinct is telling me that might cause some bugs but I'm not sure if that's the function's intended behaviour or not).
An exemple of such a code is
```python
from numba.extending import overload
from numba import types
import numba

def f(a, b, *, c):
    return a + b + c

@overload(f)
def f_overload(a, b, *, c):
    def _f(a, b, *, c):
        return a + b + c
    return _f

@numba.jit(nopython=True)
def use_f():
    return f(3, 2, c=7)

use_f()
``` 

But here is the second problem : this program raises a TypeError
(I think the first one would also raise this error if the IndexError wasn't raised before)
```
Traceback (most recent call last):
  File "..\..\..\file.py", line 78, in <module>
    use_f()
  File "..\..\..\venv\lib\site-packages\numba\core\dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "..\..\..\venv\lib\site-packages\numba\core\dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function f at 0x000001C0837AECB0>) found for signature:
 
 >>> f(Literal[int](3), Literal[int](2), c=Literal[int](7))
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'f_overload': File: ..\..\..\file.py: Line 65.
    With argument(s): '(int64, int64, c=int64)':
   Rejected as the implementation raised a specific error:
     TypeError: missing a required argument: 'b'
  raised from ..\..\..\AppData\Local\Programs\Python\Python310\lib\inspect.py:3100
```

I couldn't find out why this error was raised through debugging and reading code. 

user: rotaroced
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8901: state: open
title: IntEnum get item by value
body: Python: 3.9.11
Numba: 0.56.4


``` python
from enum import IntEnum

class Position(IntEnum):
    NORTH, EAST, SOUTH, WEST = range(4)


def test_enum():
    print(Position(2))

test_enum()
```

``` console
>>> Position.SOUTH
``` 

But the njit decorated version errors out with:
``` console

Invalid use of IntEnum class<int64>(Position) with parameters (Literal[int](2))
No type info available for IntEnum class<int64>(Position) as a callable.
During: resolving callee type: IntEnum class<int64>(Position)
During: typing of call at [...]
``` 


As per the [manual,](https://numba.pydata.org/numba-doc/dev/reference/pysupported.html) `Both enum.Enum and enum.IntEnum subclasses are supported.` and ` IntEnum.__call__`  is the way to get an item by value.

If this feature is not implemented, what would be the best workaround ?

Thanks!


user: theoallouche
issue_8889: state: open
title: complex divide raises unexpected ZeroDivisionError
body: - [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

dividing by a complex `np.nan` raises a `ZeroDivisionError` and is not affected by the use of `error_model='numpy'` only when using `fastmath=True`, 

```
import numpy as np
from numba import njit

@njit('c16[::1](c16[::1])', error_model='numpy', fastmath=True)
def tf2(a_arr):
    output = np.empty_like(a_arr, dtype=np.complex128)
    for i in range(len(output)):
        a = a_arr[i]
        output[i] = 1/a
    return output

if __name__ == "__main__":
    a = 1j * np.random.random(10) * np.nan
    np.seterr(all='ignore')
    res = tf2(a,)
```
if you set `fastmath=False` this error goes away, and when using only floats instead of complex this error also goes away, also wrapping it in a try/except block catches this error, but all those workarounds have downsides.

tested on python 3.10.8 running numba 0.56.4 (latest on pypi at the time of writing this issue).
the bug also happens on older version of python and numba down to python 3.7 and numba 0.50 that i could test.
the bug happens on windows, not sure if it happens on other operating systems or not.

i have worked around this by using `fastmath=False`, but it would be nice if it got fixed in the future.
user: ahmed-AEK
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8886: state: open
title: JIT-decorated functions raise error when setting NUMBA_DISABLE_JIT=1
body: ## Describe the bug 🐛

A function that is JIT-decorated and contains, e.g., `numpy.var()` raises an error when JIT compilation is disabled.

Minimal example:

```python
import os
import numba
import numpy as np


@numba.njit
def compute_var(x: np.ndarray) -> float:
    return float(np.var(x))


np.random.seed(42)

x = np.random.normal(0, 1, 10)

os.environ["NUMBA_DISABLE_JIT"] = "1"
print(compute_var(x))
```

This produces:

```
Traceback (most recent call last):
  File "/Users/timothy/Library/Application Support/JetBrains/PyCharmCE2023.1/scratches/scratch_6.py", line 16, in <module>
    print(compute_var(x))
  File "/usr/local/anaconda3/envs/demo-project/lib/python3.10/site-packages/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/usr/local/anaconda3/envs/demo-project/lib/python3.10/site-packages/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: native lowering)
Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function real at 0x7f8ba8460040>) found for signature:
 
 >>> real(float64)
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'np_real': File: numba/np/arraymath.py: Line 3583.
    With argument(s): '(float64)':
   Rejected as the implementation raised a specific error:
     AttributeError: 'function' object has no attribute 'get_call_template'
  raised from /usr/local/anaconda3/envs/demo-project/lib/python3.10/site-packages/numba/core/types/functions.py:541

During: resolving callee type: Function(<function real at 0x7f8ba8460040>)
During: typing of call at /usr/local/anaconda3/envs/demo-project/lib/python3.10/site-packages/numba/np/arraymath.py (437)


File "../../../../../../../usr/local/anaconda3/envs/demo-project/lib/python3.10/site-packages/numba/np/arraymath.py", line 437:
    def array_var_impl(arr):
        <source elided>
            val = (v.item() - m)
            ssd += np.real(val * np.conj(val))
            ^

During: lowering "$10call_method.4 = call $6load_method.2(x, func=$6load_method.2, args=[Var(x, scratch_6.py:8)], kws=(), vararg=None, varkwarg=None, target=None)" at /Users/timothy/Library/Application Support/JetBrains/PyCharmCE2023.1/scratches/scratch_6.py (8)
```

The problem disappears if I remove the decorator _or_ do not set `NUMBA_DISABLE_JIT` to true.

The problem is also present for other numpy functions, e.g., when using `np.median()` instead of `np.var()`. Other aggregation functions—e.g., `np.sum()` or `np.mean()`—seem to work fine.


## Versions:

```
Python: 3.10.10
numba: 0.56.4
numpy: 1.23.5
OS: macOS 13.2.1 (22D68) running on a 2019 MBP (Intel Core i7)
```
user: timothygebhard
issue_8882: state: open
title: Issue with implicit casts to complex in recursive calls
body: The following code reproduces the issue:
```
from numba import njit


@njit
def test(arg):
    ans = test2(arg - 1)
    print(ans)
    return ans


@njit
def test2(arg):
    if arg == 0:
        return 1  # complex(1) works
    else:
        return 1j * test(arg)


test2(1)
```
Expected output: 1
Actual output: 4607182418800017408

If `return 1` is replaced with `return complex(1)`, then the code works as expected.

Numba version: 0.56.4
Numpy version: 1.23.5
Python version: 3.10
OS: Windows 10
user: GaidaiIgor
labels: bug - miscompile: Bugs: miscompile
issue_8878: state: open
title: Empty list of lists crashes at runtime with njit
body: The following code reproduces the issue:

```
from numba import njit
import numpy as np


@njit
def test():
    a = [[0, 1]]
    a.clear()
    b = np.array(a)


test()
```

This code crashes with the following error message:

> IndexError: getitem out of range

Without `@njit` this code finishes successfully.

Numba version: 0.56.4
Numpy version: 1.23.5
Python version: 3.10
OS: Windows 10
user: GaidaiIgor
labels: bug - incorrect behavior: Bugs: incorrect behavior
bug - typing: Bugs: occuring at typing time
issue_8877: state: open
title: Add support for keyword and default arguments during closure inlining.
body: Currently, numba has only partial support for keyword and default arguments in closures. Specifically, when the closure object is a `make_function` op in the IR, the keyword arguments are silently ignored, and default arguments are appended to the argument list even when values for those arguments were actually provided. This can produce incorrect and surprising behavior when writing code that uses closures with keyword or default arguments.

This change reworks the `_get_callee_args` function to build a full Python signature for closures, and then use `fold_arguments` to handle them in the same way that arguments are handled for other Python functions.

To avoid reimplementing the existing `inspect` logic for determining the signature of a Python callable, this change constructs a new `_FakeFunction` object that has all the fields of a normal Python callable and then fetches the signature of that object. (It's not possible to directly construct the Python callable that the closure corresponds to, because we do not have concrete values for any closed-over variables yet.)

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: danieldjohnson
issue_8874: state: open
title: Bug (Doc) sessionization example has sync() inside if block
body: https://numba.readthedocs.io/en/stable/cuda/examples.html#dividing-click-data-into-sessions

Has example containing:
```py
# Determine session labels
if is_sess_boundary:
    # This thread marks the start of a session
    results[gid] = gid
    # Make sure all session boundaries are written
    # before populating the session id
    grid = cuda.cg.this_grid()
    grid.sync()

    # more code here ....
```
However, this will only sync for some threads. Presumably the example could be changed to:
```py
# Determine session labels
if is_sess_boundary:
    # This thread marks the start of a session
    results[gid] = gid

# Make sure all session boundaries are written
# before populating the session id
grid = cuda.cg.this_grid()
grid.sync()

if is_sess_boundary:
    # more code here ....
```

user: shaunc
labels: CUDA: CUDA related issue/PR
issue_8865: state: open
title: `nopython` rewrites don't account for variables that should raise "NameError"
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit

@njit('void(float64[::1],)')
def foo(out):
    for i in range(missing_definition1):
        while missing_definition2:
            out[i]
```
produces:
```
RuntimeError: liveness info missing for vars: {'i'}
```
from the `nopython rewrites` pass. The exception comes from here:
https://github.com/numba/numba/blob/e7a1e8315d74b0f92ba8b26a40bbb1f28db94ba2/numba/core/analysis.py#L173-L180
It looks like that there's something wrong is identified, it's just that a more ICE-like error is raised than a `NameError` that would be expected by a user.
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8860: state: open
title: `np.allclose` implementation does not handle default arguments correctly.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

The `np.allclose` implementation does not handle default arguments correctly.

MWR:
```python
from numba import njit
import numpy as np

@njit
def foo(a, b):
    np.allclose(a, b)

foo(1., 1.)
```
The implementation section here:
https://github.com/numba/numba/blob/9878790437b16718ac18cb38e9ee1a711b8a9017/numba/np/arraymath.py#L842-L858
Should:
1. Only be raising exceptions that derive from `numba.core.errors.NumbaError`, i.e. `TypingError`.
2. Accommodate both the Numba type system type and the Python type when checking the argument types. i.e. should be at least `if not isinstance(rtol, (float, types.Float)):`
user: stuartarchibald
labels: good second issue: A good issue for second time contributors
bug - typing: Bugs: occuring at typing time
issue_8847: state: open
title: Updating mk_alloc to support Numba-Dpex compute follows data
body: 
## Feature request

To implement compute follows data(CFD), Numba-Dpex made some changes to mk_alloc in ir_utils.py, as seen from the link below. Currently, it is done as a patch in dpex, it will be nice to have it in Numba without patch.  Please let me know if there is any question. Thanks.

[https://github.com/IntelPython/numba-dpex/blob/9d3d50733ddf9266f93da2348ae328e95e214900/numba_dpex/_patches.py#L71](url)
user: mingjie-intel
issue_8845: state: open
title: Python 3.11 failure when raising an exception
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```python
from numba import njit

@njit
def foo():
    try:
        raise TypeError(2)
    except Exception:
        raise ValueError(1)

foo()
```

```
Traceback (most recent call last):
  File "/Users/guilhermeleobas/git/numba/a.py", line 34, in <module>
    foo()
  File "/Users/guilhermeleobas/git/numba/a.py", line 31, in foo
    except Exception:

AssertionError: Unreachable condition reached (op code RERAISE executed)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.57.0dev0+1468.g2829f1f10.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new?template=bug_report.md

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```
user: guilhermeleobas
labels: bug - ice: Bugs: internal compiler error
Python 3.11: All issues related to Python 3.11 support
issue_8840: state: open
title: Odd Win64 LLVM Symbol not found error for recursion test symbols
body: Error and traceback:
```
LLVM ERROR: Symbol not found: .numba.unresolved$_ZN5numba5tests18recursion_usecases12make_mutual212_3clocals_3e3fooB4v217B38c8tJTIcFKzyF2ILShI4CrgQElQb6HczSBAA_3dEx

Current thread 0x00001ac4 (most recent call first):
  File "C:\Miniconda\envs\testenv\Lib\site-packages\llvmlite\binding\ffi.py", line 152 in __call__
  File "C:\Miniconda\envs\testenv\Lib\site-packages\llvmlite\binding\executionengine.py", line 92 in finalize_object
  ...
  File "D:\a\1\s\numba\tests\test_sort.py", line 860 in check_sort_copy
  File "D:\a\1\s\numba\tests\test_sort.py", line 897 in test_np_sort_int
  ...
```

See details in AzureCI [log](https://dev.azure.com/numba/numba/_build/results?buildId=14694&view=logs&j=7d649285-8174-5268-c3ef-8327fa1fe99e&s=96ac2280-8cb4-5df5-99de-dd2da759617d&t=8709f813-5880-5d9d-2364-2e8b2fc52924&l=52)

Oddities:
- LLVM complains about a unresolved symbol for https://github.com/numba/numba/blob/30df74943112acc2706a98630bba6ca1f310e0c8/numba/tests/recursion_usecases.py#L80-L85. However, the traceback seems to point to an unrelated test at: https://github.com/numba/numba/blob/96989df52cadc9b0e2cf15d08788907de141f36a/numba/tests/test_sort.py#L892-L897.
- Failed attempt uses llvmlite with GOT patch (https://github.com/numba/llvmlite/pull/926). Second attempt without the GOT patch passed. However, the problem haven't been successfully replicated manually. 
user: sklam
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_8838: state: open
title: The "parallel"/multiprocessing based test runner does not respect `setUpClass`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

As discovered in #8836. Use of the `multiprocessing` based test runner via e.g.
```
./runtests.py -m
```
will result in `setUpClass` `@classmethod`s on test classes not being invoked (same applies to `tearDownClass`). This patch "fixed" it https://github.com/numba/numba/pull/8836#issuecomment-1479598247 but is not necessarily how to fix it (the semantics of making that call need checking to make sure it adheres to the expectations around `setUpClass`).
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
test suite: problem in the test suite/test case itself
issue_8830: state: open
title: float128 support
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.


-->

LLVM has supported __float128 for at least 7 years and it would be really helpful to be able to use a real 128 bit type. numpy.float128 is sadly still not 128 bit.


user: lesshaste
issue_8821: state: open
title: CUDA: Support NVRTC when using the ctypes binding
body: The NVIDIA CUDA Python bindings are required to link C/C++ code with Numba kernels, because it compiles them with NVRTC. This means that full `float16` support also needs those bindings. If we supported NVRTC with the ctypes bindings, then `float16` support would always be available.

Previously this was not implemented because it might have been tricky to locate NVRTC, as it wasn't present in `cudatoolkit` conda packages. However, from CUDA 12 onwards, the `cudatoolkit` (or `cuda-toolkit`?) packages on conda-forge will have it available, so locating it should be less of an issue.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_8818: state: open
title: Looplifting transform fails with nested loops containing exception.
body: Hi guys, encountered an odd issue. Expected either a different error message or a refusal to compile here (or nothing at all ;)  )

Minimal example:

```shell
python3 -m venv venv
source venv/bin/activate
pip install numpy numba
```

```python
from numba import jit
from typing import List
import numpy as np

@jit
def _binary_matrix_load(lines: List[str]) -> np.ndarray:
    lines = [line.rstrip("\r\n") for line in lines]
    rows = len(lines)

    if rows == 0:
        raise Exception("No rows")

    cols = len(lines[0])

    if any((len(line) != cols for line in lines)):
        raise Exception(
                "One or more rows have different column count"
                )

    bin_matrix = np.zeros((rows, cols), dtype="uint8")

    for row, line in enumerate(lines):
        for col, value in enumerate(line):
            if value != "1" and value != "0":
                raise Exception(
                        f"{value} is not a valid binary matrix value"
                        )
            bin_matrix[row, col] = "1" == value

    return bin_matrix


if __name__ == "__main__":
    print(_binary_matrix_load(["01", "10"]))
```

Stack trace:
```python
REDACTED/lib/python3.9/site-packages/numba/core/dispatcher.py:487: in _compile_for_args
    raise e
REDACTED/lib/python3.9/site-packages/numba/core/dispatcher.py:420: in _compile_for_args
    return_val = self.compile(tuple(argtypes))
REDACTED/lib/python3.9/site-packages/numba/core/dispatcher.py:965: in compile
    cres = self._compiler.compile(args, return_type)
REDACTED/lib/python3.9/site-packages/numba/core/dispatcher.py:125: in compile
    status, retval = self._compile_cached(args, return_type)
REDACTED/lib/python3.9/site-packages/numba/core/dispatcher.py:139: in _compile_cached
    retval = self._compile_core(args, return_type)
REDACTED/lib/python3.9/site-packages/numba/core/dispatcher.py:152: in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
REDACTED/lib/python3.9/site-packages/numba/core/compiler.py:716: in compile_extra
    return pipeline.compile_extra(func)
REDACTED/lib/python3.9/site-packages/numba/core/compiler.py:452: in compile_extra
    return self._compile_bytecode()
REDACTED/lib/python3.9/site-packages/numba/core/compiler.py:520: in _compile_bytecode
    return self._compile_core()
REDACTED/lib/python3.9/site-packages/numba/core/compiler.py:499: in _compile_core
    raise e
REDACTED/lib/python3.9/site-packages/numba/core/compiler.py:486: in _compile_core
    pm.run(self.state)
REDACTED/lib/python3.9/site-packages/numba/core/compiler_machinery.py:368: in run
    raise patched_exception
REDACTED/lib/python3.9/site-packages/numba/core/compiler_machinery.py:356: in run
    self._runPass(idx, pass_inst, state)
REDACTED/lib/python3.9/site-packages/numba/core/compiler_lock.py:35: in _acquire_compile_lock
    return func(*args, **kwargs)
REDACTED/lib/python3.9/site-packages/numba/core/compiler_machinery.py:311: in _runPass
    mutated |= check(pss.run_pass, internal_state)
REDACTED/lib/python3.9/site-packages/numba/core/compiler_machinery.py:273: in check
    mangled = func(compiler_state)
REDACTED/lib/python3.9/site-packages/numba/core/object_mode_passes.py:53: in run_pass
    cres = self._frontend_looplift(state)
REDACTED/lib/python3.9/site-packages/numba/core/object_mode_passes.py:29: in _frontend_looplift
    main, loops = transforms.loop_lifting(state.func_ir,
REDACTED/lib/python3.9/site-packages/numba/core/transforms.py:263: in loop_lifting
    func_ir = _pre_looplift_transform(func_ir)
REDACTED/lib/python3.9/site-packages/numba/core/transforms.py:247: in _pre_looplift_transform
    func_ir, _common_key = _fix_multi_exit_blocks(
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

func_ir = <numba.core.ir.FunctionIR object at 0x7fb275e0d100>
exit_nodes = {148, 185}

    def _fix_multi_exit_blocks(func_ir, exit_nodes, *, split_condition=None):
        """Modify the FunctionIR to create a single common exit node given the
        original exit nodes.
    
        Parameters
        ----------
        func_ir :
            The FunctionIR. Mutated inplace.
        exit_nodes :
            The original exit nodes. A sequence of block keys.
        split_condition : callable or None
            If not None, it is a callable with the signature
            `split_condition(statement)` that determines if the `statement` is the
            splitting point (e.g. `POP_BLOCK`) in an exit node.
            If it's None, the exit node is not split.
        """
    
        # Convert the following:
        #
        #     |           |
        # +-------+   +-------+
        # | exit0 |   | exit1 |
        # +-------+   +-------+
        #     |           |
        # +-------+   +-------+
        # | after0|   | after1|
        # +-------+   +-------+
        #     |           |
        #
        # To roughly:
        #
        #     |           |
        # +-------+   +-------+
        # | exit0 |   | exit1 |
        # +-------+   +-------+
        #     |           |
        #     +-----+-----+
        #           |
        #      +---------+
        #      | common  |
        #      +---------+
        #           |
        #       +-------+
        #       | post  |
        #       +-------+
        #           |
        #     +-----+-----+
        #     |           |
        # +-------+   +-------+
        # | after0|   | after1|
        # +-------+   +-------+
    
        blocks = func_ir.blocks
        # Getting the scope
        any_blk = min(func_ir.blocks.values())
        scope = any_blk.scope
        # Getting the maximum block label
        max_label = max(func_ir.blocks) + 1
        # Define the new common block for the new exit.
        common_block = ir.Block(any_blk.scope, loc=ir.unknown_loc)
        common_label = max_label
        max_label += 1
        blocks[common_label] = common_block
        # Define the new block after the exit.
        post_block = ir.Block(any_blk.scope, loc=ir.unknown_loc)
        post_label = max_label
        max_label += 1
        blocks[post_label] = post_block
    
        # Adjust each exit node
        remainings = []
        for i, k in enumerate(exit_nodes):
            blk = blocks[k]
    
            # split the block if needed
            if split_condition is not None:
                for pt, stmt in enumerate(blk.body):
                    if split_condition(stmt):
                        break
            else:
                # no splitting
                pt = -1
    
            before = blk.body[:pt]
            after = blk.body[pt:]
            remainings.append(after)
    
            # Add control-point variable to mark which exit block this is.
            blk.body = before
            loc = blk.loc
            blk.body.append(
                ir.Assign(value=ir.Const(i, loc=loc),
                          target=scope.get_or_define("$cp", loc=loc),
                          loc=loc)
            )
            # Replace terminator with a jump to the common block
            assert not blk.is_terminated
            blk.body.append(ir.Jump(common_label, loc=ir.unknown_loc))
    
        if split_condition is not None:
            # Move the splitting statement to the common block
            common_block.body.append(remainings[0][0])
        assert not common_block.is_terminated
        # Append jump from common block to post block
        common_block.body.append(ir.Jump(post_label, loc=loc))
    
        # Make if-else tree to jump to target
        remain_blocks = []
        for remain in remainings:
            remain_blocks.append(max_label)
            max_label += 1
    
        switch_block = post_block
        loc = ir.unknown_loc
        for i, remain in enumerate(remainings):
            match_expr = scope.redefine("$cp_check", loc=loc)
            match_rhs = scope.redefine("$cp_rhs", loc=loc)
    
            # Do comparison to match control-point variable to the exit block
            switch_block.body.append(
                ir.Assign(
                    value=ir.Const(i, loc=loc),
                    target=match_rhs,
                    loc=loc
                ),
            )
    
            # Add assignment for the comparison
            switch_block.body.append(
                ir.Assign(
                    value=ir.Expr.binop(
                        fn=operator.eq, lhs=scope.get("$cp"), rhs=match_rhs,
                        loc=loc,
                    ),
                    target=match_expr,
                    loc=loc
                ),
            )
    
            # Insert jump to the next case
>           [jump_target] = remain[-1].get_targets()
E           ValueError: Failed in object mode pipeline (step: object mode frontend)
E           not enough values to unpack (expected 1, got 0)

REDACTED/lib/python3.9/site-packages/numba/core/transforms.py:908: ValueError
```
<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: SamuelYvon
labels: objectmode: object mode related issue
bug - failure to compile: Bugs: failed to compile valid code
issue_8812: state: open
title: <intrinsic to_fixed_tuple> is not usable in pure-python
body: I was trying to use pure python function by disabling JIT and came across the following bug:

```
File "/Users/thebigbool/repos/aesara/b.py", line 9, in some_func
    numba.np.unsafe.ndarray.to_fixed_tuple(shape, ndim),
  File "/Users/thebigbool/opt/anaconda3/envs/aesara-dev-1/lib/python3.10/site-packages/numba/core/extending.py", line 364, in __call__
    raise NotImplementedError(msg)
NotImplementedError: <intrinsic to_fixed_tuple> is not usable in pure-python
```

It can be reproduced by using the following snippet:

<details>
<summary> Reproduce the bug </summary>
<p>

```py
import numba
import numpy as np
import time

ndim = 3
def some_func(x, shape):
    return np.reshape(
        np.ascontiguousarray(np.asarray(x)),
        numba.np.unsafe.ndarray.to_fixed_tuple(shape, ndim),
    )

arr = np.random.rand(2, 2, 2)
a = time.time()
f = numba.njit(some_func)
print(type(f))
tmp = f(arr, np.array((2, 2, 2)))
b = time.time()
print("Time 1:", b-a)

numba.config.DISABLE_JIT = 1

arr = np.random.rand(2, 2, 2)
a = time.time()
f = numba.njit(some_func)
print(type(f))
tmp = f(arr, np.array((2, 2, 2)))
b = time.time()
print("Time 2:", b - a)

numba.config.DISABLE_JIT = 0
```

</p>
</details>

The same error goes with: `<intrinsic direct_cast>`
Is there a way to disable the JIT and use the same function in pure python?
user: Smit-create
issue_8801: state: open
title: CUDA: Error when linking C/C++ sources when Minor Version Compatibility is enabled
body: Noticed whilst reviewing #8744. The following, which turns on MVC then forces a CUDA C++ file to be linked with a `float16` divide (the implementation comes from a CUDA header):

```python
import os

os.environ['NUMBA_CUDA_ENABLE_MINOR_VERSION_COMPATIBILITY'] = '1'

from numba import cuda  # noqa: E402
from numba.types import float16  # noqa: E402


@cuda.jit('void()')
def f():
    float16(1) / float16(2)
```

results in:

```
$ python repro.py 
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/mvc-cu-link/repro.py", line 11, in <module>
    def f():
  File "/home/gmarkall/numbadev/numba/numba/cuda/decorators.py", line 126, in _jit
    disp.compile(argtypes)
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 921, in compile
    kernel.bind()
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 201, in bind
    self._codelibrary.get_cufunc()
  File "/home/gmarkall/numbadev/numba/numba/cuda/codegen.py", line 201, in get_cufunc
    cubin = self.get_cubin(cc=device.compute_capability)
  File "/home/gmarkall/numbadev/numba/numba/cuda/codegen.py", line 180, in get_cubin
    linker.add_file_guess_ext(path)
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 2641, in add_file_guess_ext
    self.add_cu_file(path)
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 2633, in add_cu_file
    self.add_cu(cu, os.path.basename(path))
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 2719, in add_cu
    program = NvrtcProgram(cu, name)
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 2844, in __init__
    err, program = nvrtc.nvrtcCreateProgram(src, name.encode(), 0, [], [])
NameError: name 'nvrtc' is not defined
Exception ignored in: <function NvrtcProgram.__del__ at 0x7f82b030b2e0>
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 2899, in __del__
    if self._program:
AttributeError: 'NvrtcProgram' object has no attribute '_program'
```
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_8800: state: open
title: double free malloc error in generator returning reference
body: ## Reporting a bug

I'm trying to make a generator that returns a reference to the same array, stored in the generator (i.e. not a copy):

```python
from numba import njit
import numpy as np

@njit
def generator():
    z = np.zeros(shape=(3,), dtype=np.int32)
    for i in range(3):    # bug hits on i=2
        z[i] = 1
        yield z    # no bug if return z.copy()

for g in generator():
    print(g)
```

The bug does not happen if I return a copy. Also it occurs at the 3rd iteration, which maybe implies that something related to `malloc` is happening at each loop?


EDIT:
Perhaps some useful clues:
```python
from numba import njit
import numpy as np

@njit
def generator():
    z = np.zeros(shape=(4,), dtype=np.int32)
    z[0] = 1
    yield z
    z[0] = 0
    yield z

for g in generator():
    print(g)

# [1 0 0 0]
# [-555819298 -555819298 -555819298 -555819298]


from numba import njit
import numpy as np

@njit
def generator_bug(x):
    for i in range(3):
        x[i] = 1
        yield x

@njit
def generator_no_bug(x):
    x[0] = 1
    yield x
    x[1] = 1
    yield x
    x[2] = 1
    yield x

z = np.zeros(shape=(3,), dtype=np.int32)


for g in generator_no_bug(z):
    print(g)
    
# [1 0 0]
# [1 1 0]
# [1 1 1]


for g in generator_bug(z):
    print(g)
 
# [1 0 0]
# [1 1 0]
# python(60553,0x2087fc100) malloc: Double free of object 0x1187f3aa0
# python(60553,0x2087fc100) malloc: *** set a breakpoint in malloc_error_break to debug
# Abort trap: 6
user: ziofil
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
bug - memory leak: Memory leak
issue_8797: state: open
title: Allow typed containers to be pickled
body: ## Feature request

From https://github.com/numba/numba/issues/8791#issuecomment-1452124423:

> A full fix would be to implement __getstate__ and __setstate__ for typed.Dict that converted to/from a regular Python dictionary during pickling (or possibly a dictionary and Numba types for the key and value to ensure the inferred type didn't change at the other end).

related https://github.com/numba/numba/issues/8791
user: sklam
issue_8794: state: open
title: Replace internal `StateDict` with `types.SimpleNamespace`
body: The class `StateDict` here:
https://github.com/numba/numba/blob/0c0f2b57c730899254f1300e06ba2436f60a29f4/numba/core/compiler.py#L362-L375
can be replaced with a `types.SimpleNamespace`.
user: stuartarchibald
issue_8785: state: open
title: array setitem failed with heterogeneous tuple
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
@njit
def success():
    a = np.zeros(2)
    a[:] = (1.0, 2.0)
    a[:] = (1, 2)
    return a

success()
```
```
array([1., 2.])
```
```python
@njit
def fail():
    a = np.zeros(2)
    a[:] = (1.0, 2)
    return a

fail()
```
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Cell In[113], line 7
      4     a[:] = (1.0, 2)
      5     return a
----> 7 fail()

File ~/miniconda3/envs/py3.10/lib/python3.10/site-packages/numba/core/dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 468     error_rewrite(e, 'typing')
    469 except errors.UnsupportedError as e:
    470     # Something unsupported is present in the user code, add help info
    471     error_rewrite(e, 'unsupported_error')

File ~/miniconda3/envs/py3.10/lib/python3.10/site-packages/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function setitem>) found for signature:
 
 >>> setitem(array(float64, 1d, C), slice<a:b>, Tuple(float64, Literal[int](2)))
 
There are 16 candidate implementations:
      - Of which 16 did not match due to:
      Overload of function 'setitem': File: <numerous>: Line N/A.
        With argument(s): '(array(float64, 1d, C), slice<a:b>, Tuple(float64, int64))':
       No match.

During: typing of staticsetitem at /tmp/ipykernel_2375565/1412383927.py (4)

File "../../../../../../tmp/ipykernel_2375565/1412383927.py", line 4:
<source missing, REPL/exec in use?>
```

numba version 0.56.4
user: auderson
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8783: state: open
title: Add support for NamedTuple casting and constructor default arguments
body: This PR adds support for some additional features for named tuples.

### Casting

Enables casts between NamedTuple types with the same instance class and compatible element types, similar to how regular tuples can be cast if they have compatible element types. Casting is supported for both NamedTuple and NamedUniTuple. Casts remain unsupported between tuples of different instance classes (i.e. with different Python types).

This makes it possible to use namedtuples in place of regular tuples in more situations. For instance, we can pass a namedtuple containing ints to a function that expects floats, or a namedtuple containing None to a function expecting that element to be optional. Before this change, both of those resulted in an error unless each element was cast manually.

### Constructor default arguments

NamedTuple classes can have default arguments in Python 3.7 and later. This is especially convenient when defining a NamedTuple class by subclassing `typing.NamedTuple`.

However, Numba does not currently process the default arguments in the correct way. This appears to be due to the use of `make_callable_template` to build the callable template for the constructor, which inspects the signature of the `typer` function itself and then ["hacks omitted parameters out"](https://github.com/numba/numba/blob/4535cb650da992a4c06bd252f94ee50095795f46/numba/core/typing/templates.py#L448-L454). In this case the lowering function for namedtuples expects to receive values for these parameters, and in some cases this can lead to trying to access memory out of the allocated bounds, e.g. if we define
```
class Foo(typing.NamedTuple):
    foo: int
    bar: int = 0
```
then construct `foo = Foo(1)` and try to access `foo.bar` inside `nopython` jit code.

This change modifies the call template for the namedtuple class object to infer default arguments from the python signature, by using `fold_arguments` and `generic` to build an explicit template instead of deferring to `make_callable_template`.

user: danieldjohnson
labels: Effort - medium: Medium size effort needed
issue_8779: state: open
title: Refactored Numpy documentation to follow numpy user reference
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

This PR is first of a series of PRs aimed towards improving Numba's documentation of it's NumPy support capabilities. 

It makes the current Numba documentation for NumPy support to follow the format of NumPy User Reference Guide (http://www.numpy.org/1.23/reference/index.html)

Note to reviewer: This PR doesn't change the existing contents by a significant degree and is more concerned with rearrangement of existing contents into proper sections. The actual content changes will be made section-by-section in following PRs to keep it easier for review.
user: kc611
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
skip_release_notes: Skip towncrier requirement
issue_8773: state: open
title: CUDA: Refactor handling of target options
body: The broad aim of this PR is to handle target options in CUDA more closely to how they are handled by the CPU target, with the longer-term aim of fixing the inheritance of options (for example, so that a device function could inherit `lineinfo=True` if its caller had `lineinfo=True`), and also to minimise the differences between the way decorators work in the CPU and CUDA targets. This PR doesn't reach the point where the decorator implementations are quite ready to unify, but it does move in the right direction.

I checked the generated code from this branch compared with `main`, and no difference is made to code generation.

This work was originally done with a view towards integrating it into #8594 so that the inheritance of lineinfo could be rectified there, but it has turned out to be too large a chunk of work to dump on top of an already-reviewed PR.

Individual commit messages provide more details, and the patches should be reviewable individually (this may be an easier way of reading them than as a whole).
user: gmarkall
labels: CUDA: CUDA related issue/PR
Effort - medium: Medium size effort needed
issue_8772: state: open
title: reshape bug in parallel mode
body: This bug appeared in version 0.56.4 (This bug was absent in version 0.55.1).

In parallel mode, executing the function below raise a bug "Failed in nopython mode pipeline (step: native lowering) No definition for lowering UniTuple(int64 x 3).shape".
It works in regular njit mode.

-->
- [ x] I have tried using the latest released version of Numba
- [x ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.
<!--

-->
````
@njit(parallel=True)
def foo():
    a = np.random.rand(2,3)
    b = np.random.rand(2,3)
    return a.reshape((1,*a.shape))*b.reshape((1,*b.shape))
````

user: lanougue
labels: bug - ice: Bugs: internal compiler error
issue_8770: state: open
title: Issue with np.random.normal method
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

Hello, 

First of all, thank you for this great project. It has been very useful to me.

I'm  having a strange Typing error with this simple code:

```python
import numpy as np
from numba import njit

@njit()                                                                                                                                                                    
def test():
    return np.random.normal(np.array([0.1,0.24], dtype=np.float64), 0.2, 2)

print(test())
``` 
The exact error is:

```
No implementation of function Function(<built-in method normal of numpy.random.mtrand.RandomState object at 0x101a9f740>) found for signature:
 
 >>> normal(array(float64, 1d, C), float64, Literal[int](2))
 
There are 4 candidate implementations:
  - Of which 4 did not match due to:
  Overload in function '_OverloadWrapper._build.<locals>.ol_generated': File: numba/core/overload_glue.py: Line 129.
    With argument(s): '(array(float64, 1d, C), float64, int64)':
   Rejected as the implementation raised a specific error:
     TypingError: No match
  raised from /Users/cruiz1/Projects/python/numpym1/lib/python3.9/site-packages/numba/core/overload_glue.py:162

During: resolving callee type: Function(<built-in method normal of numpy.random.mtrand.RandomState object at 0x101a9f740>)
During: typing of call at /Users/cruiz1/Downloads/numba_parallelism_issue/reproducer.py (6)


File "reproducer.py", line 6:
def test():
    return np.random.normal(np.array([0.1,0.24],dtype=np.float64), 0.2, 2)

```

I'm using version 0.56.0. 

If I use a single value for the first parameter in the normal method it works. The documentation from numpy says that we can use single values or an array.

Looking at the error, there seems to be a link to the class `numpy.random.mtrand.RandomState` where the method was implemented in older versions of numpy. Probably this method points to an older implementation?

Thank you for your attention.


user: camilo1729
labels: bug - documentation incorrect: documentation is incorrect or missing something important
issue_8769: state: open
title: Support for decimal.Decimal
body: <!--

Thanks for opening an issue! To help, the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

I'm currently looking at strategies for performance enhancements for [numpy-financial](https://github.com/numpy/numpy-financial). At this point, the only other dependency I have is NumPy. I was recommended to use Numba. Numba seems to be a great tool for what I want to do. The problem is that many financial calculations also need to support the `decimal.Decimal` type. Which, as I understand it, is not currently supported in `nopython` mode. Is that right?

Is this possible to implement in Numba? Are there some other workarounds to getting fast(er) Decimal maths?

Thanks for all the work done on Numba, it looks like a great project!
user: Kai-Striega
labels: discussion: An issue requiring discussion
issue_8759: state: open
title: `pndindex` not mentioned in docs
body: Need to add `pndindex` along with docs on `prange` in https://numba.readthedocs.io/en/stable/user/parallel.html#explicit-parallel-loops
user: sklam
issue_8758: state: open
title: RFC: Impact of stopping building packages for 32 bit windows
body: This is an RFC on whether the Numba project stopping building packages for 32 bit windows would impact users. 

Reasons for proposing the change:
* The conda package availability for 32 bit windows platforms is more sparse than for other platforms and becoming progressively more so. This impacts Numba's build and test tooling, it's not clear for how much longer these packages could be produced on the current tooling. 
* 32 bit platforms have had a somewhat degraded experience in Numba already (primarily due to no parallel target support).

Questions include:
* Are there users which rely on using 32 bit windows?
* What scenarios lead to this requirement?
* How many users are there in this group?

Anticipated time line for stopping producing 32 bit windows packages would be:
* 0.57 (upcoming release) would be the last release with any 32 bit windows packages produced, these would be best effort in terms of covering Python and NumPy versions.
* 0.58 no 32 bit windows packages available.

If this would impact your Numba use case or a project you know of please comment with respect to the above. Many thanks!

NOTE: This will also be discussed at the Numba public meeting on 2023-02-21 with any outcomes posted here.
user: stuartarchibald
labels: RFC: Request for Comments
issue_8755: state: open
title: ensure_cache_path() for Windows directory permission check may cause infinite loop
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
This problem only occurs in Windows. To reproduce this bug, a simple `bug.py` could be written like this:
```
from numba import njit
@njit(cache=True)
def f():
    pass
```
Running this alone is totally fine. But if you toggle the privileges of the `__pycache__` folder, this code will hang _almost_ forever.

[ensure_cache_path()](https://github.com/numba/numba/blob/b89199e9323f3f801c35fa0f20524833c18f46c4/numba/core/caching.py#L106#L107)  in numba/core/caching.py uses `tempfile.TemporaryFile()` to check if writable. However there is a long-time bug of the Python built-in package [tempfile](https://github.com/python/cpython/issues/66305). This Python's own bug haven't been solved for ten years and confused many([example](https://stackoverflow.com/questions/55109076/python-tempfile-temporaryfile-hangs-on-windows-when-no-write-privilege)). An alternative way should be taken to ensure cache writability.

For my case, I installed Python and its packages in `%ProgramFiles%`. My program uses another package that depends on numba njit cache. If I don't choose to run as Administrator, loading that package will make me wait forever.
user: nethe-GitHub
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_8753: state: open
title: Memory overwriting other memory issue?
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Take this piece of code:
```
import numba

@numba.njit
def foo():
  lst1 = [[1,2,3,4,5], [6,7,8,9,10]]

  for i in range(300):
    lst2 = []
    lst2.append(1)

    del lst1[1]
    del lst1[0]

    lst1.append([1,2,3,4,5])
    lst1.append([6,7,8,9,10])

    if len(lst2) > 1:
      print("This should never print!")
      print("Length of lst2(should not ever be greater than 1): ", len(lst2))

for i in range(200):
  foo()
```
If you run this, you will get that sometimes the prints happen even though they shouldn't. 'lst2' should never have length more than 1 since it only gets appended to once and then reset in each iteration. It seems that appending to lst1 is somehow "interfering" with lst2. My suspicion is some kind of memory problem where 'lst1' appending is overwriting other memory? But I am not sure.. When I run this, the length of lst2 somehow ends up being 5 sometimes which is super weird.. Thank you for the help!
user: mtalha123
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
bug - incorrect behavior: Bugs: incorrect behavior
issue_8747: state: open
title: np.roll not working in nopython model (CUDA)
body: Is `np.roll` currently supported within a cuda.jit function? I get the following error when I call: 
`np.roll(d, 1)` where d is a 1d numpy array. Looks like the overload of `np.empty` is failing here?

```
Failed in cuda mode pipeline (step: nopython frontend)
No implementation of function Function(<function roll at 0x7f657cbeeca0>) found for signature:
 
 >>> roll(array(float32, 1d, C), Literal[int](1))
 
There are 2 candidate implementations:
      - Of which 2 did not match due to:
      Overload in function 'np_roll': File: numba/np/arraymath.py: Line 2126.
        With argument(s): '(array(float32, 1d, C), int64)':
       Rejected as the implementation raised a specific error:
         TypingError: Failed in nopython mode pipeline (step: nopython frontend)
       No implementation of function Function(<built-in function empty>) found for signature:
        
        >>> empty(UniTuple(int64 x 1), dtype=dtype(float32))
        
       There are 4 candidate implementations:
             - Of which 4 did not match due to:
             Overload in function '_OverloadWrapper._build.<locals>.ol_generated': File: numba/core/overload_glue.py: Line 131.
               With argument(s): '(UniTuple(int64 x 1), dtype=dtype(float32))':
              Rejected as the implementation raised a specific error:
                NumbaTypeError: Failed in nopython mode pipeline (step: nopython frontend)
              Only accept returning of array passed into the function as argument
         raised from /home/co1/.conda/envs/superneuro/lib/python3.9/site-packages/numba/core/typed_passes.py:150
       
       During: resolving callee type: Function(<built-in function empty>)
       During: typing of call at /home/co1/.conda/envs/superneuro/lib/python3.9/site-packages/numba/np/arraymath.py (2133)
       
       
       File "../.conda/envs/superneuro/lib/python3.9/site-packages/numba/np/arraymath.py", line 2133:
           def np_roll_impl(a, shift):
               <source elided>
               arr = np.asarray(a)
               out = np.empty(arr.shape, dtype=arr.dtype)
               ^

  raised from /home/co1/.conda/envs/superneuro/lib/python3.9/site-packages/numba/core/typeinfer.py:1086

```
user: chathika
labels: CUDA: CUDA related issue/PR
issue_8743: state: open
title: Inconsistent error state with numpy for zero division
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

In numpy, the default error state for zero division is `warn` which will raise a warning instead of an error when zero division:
```python
>>> import numpy as np
>>> np.geterr()
{'divide': 'warn', 'over': 'warn', 'under': 'ignore', 'invalid': 'warn'}
>>> 1.0 / np.float64(0.0)

Warning (from warnings module):
  File "<pyshell#13>", line 1
RuntimeWarning: divide by zero encountered in double_scalars
inf
```
In numba, an error will be raised by default:
```python
>>> import numba
>>> @numba.njit
... def test_numba_zero_division():
...     print(1.0/np.float64(0.0))

>>> test_numba_zero_division()
Traceback (most recent call last):
  File "<pyshell#21>", line 1, in <module>
    test_numba_zero_division()
ZeroDivisionError: division by zero
```

Is it a bug?
user: haiiliin
labels: discussion: An issue requiring discussion
issue_8742: state: open
title: Inconsistent output for floor_divide / remainder / divmod
body: When working on some code that needs to find the nearest sample index and the distance from it, I came across some inconsistencies in the available floor division and remainder functions. The following function returns the floor division and remainder calculated in three ways: with standard // and % operators, with the `floor_divide` and `remainder` functions and with the `divmod` function:

```python
@numba.njit()
def fdiv(a, b):
    return (
        (a // b, a % b),
        (np.floor_divide(a, b), np.remainder(a, b)),
        np.divmod(a, b),
    )
```

When called with `a=0.5` and `b=0.05`, in an ideal world all the tuples would be (10, 0). With floating point, calling the original Python function (i.e., the NumPy implementations), we get 9 and something very close to 0.05:

```python
>>> fdiv.py_func(np.float_(0.5), np.float_(0.05))
((9.0, 0.049999999999999975),
 (9.0, 0.049999999999999975),
 (9.0, 0.049999999999999975))
```

However, the compiled version differs -- the operator result is the same, but the function results give 10 and something very close to 0.05:

```python
>>> fdiv(np.float_(0.5), np.float_(0.05))
((9.0, 0.049999999999999975),
 (10.0, 0.049999999999999975),
 (10.0, 0.049999999999999975))
```

This division result is off by one for the corresponding remainder. To put it another way, the reconstitution `a == b * (a // b) + (a % b)` within roundoff (as promised in the [floor_divide docstring](https://numpy.org/doc/stable/reference/generated/numpy.floor_divide.html)) does not happen:

```python
@numba.njit()
def fdiv_reconstitute(a, b):
    dm = np.divmod(a, b)
    return (
        (b * (a // b)) + (a % b),
        (b * np.floor_divide(a, b)) + np.remainder(a, b),
        (b * dm[0]) + dm[1],
    )
```
```python
>>> fdiv_reconstitute(0.5, 0.05)
(0.5, 0.5499999999999999, 0.5499999999999999)
```

I get this behaviour on both the latest Git versions of numba (28573bb985) and llvmite (numba/llvmlite@b40a72a), and with the latest releases (numba 0.56.4, llvmlite 0.39.1) installed as wheels from PyPI. This is using Python 3.10 on ArchLinux, Intel i9-9900K CPU, LLVM 11.
user: bcbnz
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8741: state: open
title: Added initial typed set implementation
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

As titled, this PR adds initial support for `typed.set`s.

The following set methods are currently supported:
- `len(set())`
- `set().add()`
- `set().discard()`
- `set().__contains__()`
- `set().__iter__()`

user: kc611
labels: Effort - long: Long size effort needed
issue_8737: state: open
title: Numba data model for `void` returns pointer to `i8`
body: Is this correct?

```python
>>> from numba.core import datamodel, types
>>> print(datamodel.default_manager[types.void].get_return_type())
i8*
```

I was expecting `types.void` to be converted to the LLVM void type
user: guilhermeleobas
issue_8734: state: open
title: Jitclass Infer Spec for Collections from Type Annotations
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Numba currently infers the types of jitclass attributes from type annotations, however, the attributes can not be collections, such as `numba.typedlist.List`. 

Consider the following code:
```py
import numba as nb
from numba.typed.typedlist import List
from numba.experimental import jitclass

@jitclass
class Item:
    a: nb.int64
    def __init__(self, a):
        self.a = a
```

Now this class definition works:
```py

@jitclass
class Container:
    data: Item

    def __init__(self):
        self.data = Item(10)
```

However, this does not:
```py

@jitclass
class CollectionContainer:
    data: List[Item]

    def __init__(self):
        # see https://github.com/numba/numba/issues/8733 for why this ugly code must be used
        data_tmp = List()
        data_tmp.append(Item(10))
        data_tmp.clear()

        self.data = data_tmp
```

Defining the class `CollectionContainer` results in the following error:
```
numba.core.errors.TypingError: Cannot infer numba type of python type numba.typed.typedlist.List[numba.experimental.jitclass.base.Item]
```

In other words, a jitclass can not infer spec for collections from type annotations.

### Workaround

The issue can be worked around for Lists by registering a custom `as_numba_type` function like this:
```py

import typing

import numba as nb
from numba.core.types import ListType
from numba.core.typing.asnumbatype import as_numba_type
from numba.experimental import jitclass
from numba.typed.typedlist import List

@as_numba_type.register
def numba_type_converter_typed_list(py_type):
    origin = typing.get_origin(py_type)

    try:
        if issubclass(origin, List):
            item_type = typing.get_args(py_type)[0]

            return ListType(as_numba_type.infer(item_type))

    except:
        return None
```

Similar code (the try except should probably be handled better) could be implemented into Numba to solve this issue. Furthermore, this code does probably not deal with nested collections.

## Related Issues

https://github.com/numba/numba/pull/5609 [MERGED] Jitclass Infer Spec from Type Annotations

https://github.com/numba/numba/issues/5218 [OPEN] Use __init__ type hints for jitclass spec? 


user: Acmion
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8733: state: open
title: Assigning a `jitclass` Attribute to `List.empty_list(Item)` in the Constructor Fails
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Assiging a jitclass attribute to `List.empty_list(Item)` in the constructor fails.

Consider the following code:
```py
@jitclass
class Item:
    a: nb.int64
    def __init__(self, a):
        self.a = a

l = List()
l.append(Item(1))
data_type = nb.typeof(l)

@jitclass([('data', data_type)])
class Container:
    def __init__(self):
        self.data = List.empty_list(Item)

@nb.njit
def f0():
    return List.empty_list(Item)

@nb.njit
def f1():
    return Container().data
```

Calling `f0()` works as expected and outputs:
```
[]
```

However, calling `f1()` does not work (even if the types logically match) and outputs:
```
Failed in nopython mode pipeline (step: native lowering)
Cannot cast ListType[jitclass.Item#18a626800d0<a:int64>] to ListType[instance.jitclass.Item#18a626800d0<a:int64>]: %"inserted.data.2" = insertvalue {i8*, i8*} %"inserted.meminfo.2", i8* %".150", 1
During: lowering "(self).data = y" at D:\dev.py (22)
During: resolving callee type: jitclass.Container#18a626bf1c0<data:ListType[instance.jitclass.Item#18a626800d0<a:int64>]>
During: typing of call at D:\Mega\Projects\aaa\dev.py (30)

During: resolving callee type: jitclass.Container#18a626bf1c0<data:ListType[instance.jitclass.Item#18a626800d0<a:int64>]>
During: typing of call at D:\dev.py (30)
```

In other words, assigning a jitclass attribute to `List.empty_list(Item)` will not work, while similar code in a `njit` will not fail. Furthermore, this code will also fail:

```py
@jitclass([('data', data_type)])
class Container:
    def __init__(self):
        data_tmp = List.empty_list(Item)
        self.data = data_tmp
```

The error is the same as previously.

### Workaround

The issue can in most cases be fixed like this:
```py
@jitclass([('data', data_type)])
class Container:
    def __init__(self):
        data_tmp = List()
        data_tmp.append(Item(10))
        data_tmp.clear()
        self.data = data_tmp
```

However, this requires one to instantiate one `Item`, which may not be trivial in all cases. Furthermore, the fix is quite ugly.

## Related Issues

https://github.com/numba/numba/issues/7291 [CLOSED] unable to use List.empty_list of type jitclass or deferred_type in jitclass.__init__

https://github.com/numba/numba/issues/5873 [OPEN] Implement type key-word-argument for numba.typed.List constructor 

## Considerations

This issue can probably be closed if https://github.com/numba/numba/issues/7291 is reopened, which was closed by the original author. Furthermore, the issue also discusses reference deferred types, which is not exactly what the core issue here is. 
user: Acmion
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8724: state: open
title: save and read numba.typed.Dict , with multiple workers
body: ## Feature request

To save and read numba.typed.Dict, as pickle or other file, with capability to read with multiple workers

Specific use case: reading large dictionary into a serverless app (using Cloud Function) and converting to a typed dict takes several minutes. This means a long wait for the user: to open the file as a typed.Dict, using all the workers the serverless host provides, would reduce the load time by an order of magnitude. 

I can't see a way to achieve this with the current numba library

user: adam-jb
issue_8719: state: open
title: CUDA simulator does not raise for more than one group in cooperative groups mode
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

According to https://numba.readthedocs.io/en/stable/cuda/cooperative_groups.html#numba.cuda.dispatcher._Kernel.max_cooperative_grid_blocks ("Exceeding the maximum number of blocks for the cooperative launch will result in a CUDA_ERROR_COOPERATIVE_LAUNCH_TOO_LARGE error") and https://numba.readthedocs.io/en/stable/cuda/simulator.html ("A cooperative kernel can be launched, but with only one block - the simulator always returns 1 from a kernel overload’s [max_cooperative_grid_blocks()](https://numba.readthedocs.io/en/stable/cuda/cooperative_groups.html#numba.cuda.dispatcher._Kernel.max_cooperative_grid_blocks) method") the simulator should raise an exception running this code:

```python
import os; os.environ["NUMBA_ENABLE_CUDASIM"] = "1"; os.environ["NUMBA_CUDA_DEBUGINFO"] = "1"
import numpy as np
from numba import cuda

@cuda.jit
def kernel(dest, n):
    g = cuda.cg.this_grid()
    g.sync()

def idiv_round_up(x, y):
    return (x + y - 1) // y

def run(x):
    n, = x.shape
    x_device = cuda.to_device(x)
    blocks = 2  # more than 1
    kernel[blocks, 32](x_device, n)

x = np.random.random(16)
run(x)
```

By the way, if I understand correctly, it shouldn't be too hard to support more cooperative groups (and it involves only writing a better `g.sync()` that isn't too different from `cuda.syncthreads()`). I'm willing to try if someone can mentor me through the process.
user: SonOfLilit
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_8712: state: open
title: `LoweringError` when using `is` with jitclass
body: (cc @al-zatv)

Reproducer:

```python
from numba.experimental import jitclass
from numba import njit

@jitclass
class Phrase:
    id: str

    def __init__(self):
        self.id = "x"

@njit
def test_jitclass_is():
    p1 = Phrase()
    p2 = Phrase()
    return p1 is p2

test_jitclass_is()
```

results in:

```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
no default `is` implementation
During: lowering "$18is_op.6 = p1 is p2" at /home/gmarkall/numbadev/issues/al-zatv/repro.py (17)
```

I don't yet know whether we should have a default `is` implementation for jitclasses (probably?) but I know we shouldn't have a `LoweringError` when trying to use it :slightly_smiling_face: 
user: gmarkall
issue_8709: state: open
title: numba stencil too slow
body: ## Feature request

Please add a `nopython` option to stencil. Using stencil alone has a huge (detrimental) performance impact. 

Comparing a stencil "function" against its python counterpart, the performance penalty by using only the stencil decorator is around two orders of magnitude, meaning the stencil version is around 100x slower than pure python loop implementation (which is slow already). 

I did a quick benchmark using a simple finite difference (derivative) example. It is available via this [google colab](https://colab.research.google.com/drive/1jR1WI8eNZSNcOs5Rwwots9l-w2e_0g-U?usp=sharing) link. It follows a minimal example below:

```python
import numba as nb
import numpy as np

# independent variable array
x = np.linspace(0, 1, 2**11+1)

# dependent variable array: y = f(x)
y = 0.5*x**2

# mesh step size
h = x[1] - x[0]

def derivative_lst(y):
    dy = []
    for i in range(2, len(y)-2):
        dy.append(0.5*(y[i+1] - y[i-1])/h)
    return dy

@nb.stencil
def derivative_stencil(y):
      return 0.5*(y[+1] - y[-1])/h

@nb.njit
def derivative_stencil_njit(y):
    @nb.stencil
    def kernel(y):
        return 0.5*(y[+1] - y[-1])/h
    return kernel(y)

# slow version
dydx = derivative_stencil(y)

# much better performance
dydx = derivative_stencil_njit(y)
```

It would be nice to have a `@numba.stencil(nopython=True)` version in order to produce a performance result similar to the `derivative_stencil_njit` above without all the hassle of having a kernel inner function.  Something simple as this: 

```python
# proposal
@nb.stencil(nopython=True)
def derivative_stencil(y):
      return 0.5*(y[+1] - y[-1])/h
```

I believe that without this, numba stencil usage becomes too slow or too intricate. What do you think?




user: bgeneto
labels: performance - run time: Performance issue occurring at run time.
stencil: Issue involving stencils
issue_8708: state: open
title: Raise a warning if fastmath options nnan/ninf are in use with `isnan` or `isinf`
body: Following on from #7701, it would be good to feed back to users e.g. via a warning that their program may not execute as expected if `fastmath` options `nnan` or `ninf` are in use with `isnan` or `isinf` functionality respectively.
user: stuartarchibald
issue_8705: state: open
title: `np.cos`, `np.sin`, `np.sqrt` returning incorrect values in very specific scenarios
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Consider this innocuous looking snippet:
```python
import numpy as np
import numba as nb

@nb.njit
def f(x):
    return np.array([
        x[0],
        np.cos(x[0]) * x[0],
        -np.cos(x[0]) * np.cos(x[1])
    ])

print(f(np.zeros(2))) # [ 0.         -0.         -0.99254141]
```

On Windows, Python 3.9.5 and Python 3.8.2, I confirm this starts producing incorrect results starting from `numba==0.54.0` and later, including `numba==0.56.4`. It does not occur on `numba==0.53.1` or earlier.
Doing a diff of the LLVM dump between passing and failing version seems to suggest it has something to do with the usage of the svml library, but I can't say for sure because any tiny change to the code can cause the issue to go away. For example, the following snippet has no issue:

```python
import numpy as np
import numba as nb

@nb.njit
def f(x):
    return np.array([
        x[1],
        np.cos(x[0]) * x[0],
        -np.cos(x[0]) * np.cos(x[1])
    ])

print(f(np.zeros(2))) # [ 0.  0. -1.]
```

Here is my environment:

<details>

```
--------------------------------------------------------------------------------
__Time Stamp__
Report started (local time)                   : ...
UTC start time                                : ...
Running time (s)                              : 1.805322

__Hardware Information__
Machine                                       : AMD64
CPU Name                                      : skylake
CPU Count                                     : 8
Number of accessible CPUs                     : 8
List of accessible CPUs cores                 : 0 1 2 3 4 5 6 7
CFS Restrictions (CPUs worth of runtime)      : None

CPU Features                                  : 64bit adx aes avx avx2 bmi bmi2  
                                                clflushopt cmov cx16 cx8 f16c fma
                                                fsgsbase fxsr invpcid lzcnt mmx  
                                                movbe pclmul popcnt prfchw rdrnd 
                                                rdseed rtm sahf sse sse2 sse3    
                                                sse4.1 sse4.2 ssse3 xsave xsavec 
                                                xsaveopt xsaves

Memory Total (MB)                             : 32708
Memory Available (MB)                         : 16987

__OS Information__
Platform Name                                 : Windows-10-10.0.19045-SP0        
Platform Release                              : 10
OS Name                                       : Windows
OS Version                                    : 10.0.19045
OS Specific Version                           : 10 10.0.19045 SP0 Multiprocessor Free
Libc Version                                  : ?

__Python Information__
Python Compiler                               : MSC v.1928 64 bit (AMD64)
Python Implementation                         : CPython
Python Version                                : 3.9.5
Python Locale                                 : ...

__Numba Toolchain Versions__
Numba Version                                 : 0.56.4
llvmlite Version                              : 0.39.1

__LLVM Information__
LLVM Version                                  : 11.1.0

__CUDA Information__
CUDA Device Initialized                       : True
CUDA Driver Version                           : 11.7
CUDA Runtime Version                          : 9.0
CUDA NVIDIA Bindings Available                : False
CUDA NVIDIA Bindings In Use                   : False
CUDA Detect Output:
Found 1 CUDA devices
id 0    b'NVIDIA GeForce GTX 1070'                              [SUPPORTED]
                      Compute Capability: 6.1
                           PCI Device ID: 0
                              PCI Bus ID: 1
                                    UUID: GPU-a52653e9-3c51-fa78-7d15-673f8058ea38
                                Watchdog: Enabled
                            Compute Mode: WDDM
             FP32/FP64 Performance Ratio: 32
Summary:
        1/1 devices are supported

CUDA Libraries Test Output:
Finding nvvm from CUDA_HOME
        named  nvvm64_32_0.dll
        trying to open library...       ok
Finding cudart from CUDA_HOME
        named  cudart64_90.dll
        trying to open library...       ok
Finding cudadevrt from CUDA_HOME
        named  cudadevrt.lib
        ERROR: failed to find cudadevrt:
cudadevrt.lib not found
Finding libdevice from CUDA_HOME
        trying to open library...       ok


__NumPy Information__
NumPy Version                                 : 1.20.3
NumPy Supported SIMD features                 : ('MMX', 'SSE', 'SSE2', 'SSE3', 'SSSE3', 'SSE41', 'POPCNT', 'SSE42', 'AVX', 'F16C', 'FMA3', 'AVX2')
NumPy Supported SIMD dispatch                 : ('SSSE3', 'SSE41', 'POPCNT', 'SSE42', 'AVX', 'F16C', 'FMA3', 'AVX2', 'AVX512F', 'AVX512CD', 'AVX512_SKX', 'AVX512_CLX', 'AVX512_CNL')
NumPy Supported SIMD baseline                 : ('SSE', 'SSE2', 'SSE3')
NumPy AVX512_SKX support detected             : False

__SVML Information__
SVML State, config.USING_SVML                 : True
SVML Library Loaded                           : True
llvmlite Using SVML Patched LLVM              : True
SVML Operational                              : True

__Threading Layer Information__
TBB Threading Layer Available                 : False
+--> Disabled due to Unknown import problem.
OpenMP Threading Layer Available              : True
+-->Vendor: MS
Workqueue Threading Layer Available           : True
+-->Workqueue imported successfully.

__Numba Environment Variable Information__
None found.

__Conda Information__
Conda not available.

__Installed Packages__
Package                        Version
------------------------------ --------------
llvmlite                       0.39.1
numba                          0.56.4
numpy                          1.20.3
scipy                          1.8.1
...

No errors reported.


__Warning log__
Warning: Conda not available.
 Error was [WinError 2] The system cannot find the file specified

--------------------------------------------------------------------------------
```

</details>
user: AndrewYY
labels: llvm: LLVM related issues
bug - miscompile: Bugs: miscompile
bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8704: state: open
title: Added traceback printing capability while NRT debugging
body: Resolves #8559

As titled, 
This PR adds traceback printing capability while NRT debugging is enabled. 

Also adds a flag that helps user configure the stack limit for traceback. This functionality can be disabled by setting the same stack limit to zero.

An example NRT Debug with stack limit as 3:

```python
import numpy as np
import numba

@numba.njit
def foo(x):
    return x + 5

x = np.array([0,1,0])
foo(x)
```

Outputs the follows:
```
*** NRT_Decref 1 [0x3245f80]
Traceback:  File "/home/kaustubh/Desktop/WorkSpaces/Numba Workspace/nrt_debug/numba/numba/core/callwrapper.py", line 180, in build_wrapper
    cleanup_manager.emit_cleanup()
  File "/home/kaustubh/Desktop/WorkSpaces/Numba Workspace/nrt_debug/numba/numba/core/callwrapper.py", line 71, in emit_cleanup
    dtor()
  File "/home/kaustubh/Desktop/WorkSpaces/Numba Workspace/nrt_debug/numba/numba/core/callwrapper.py", line 50, in cleanup_arg
    self.context.nrt.decref(self.builder, ty, native.value)

*** NRT_Decref 2 [0x326b5f0]
Traceback:  File "/home/kaustubh/Desktop/WorkSpaces/Numba Workspace/nrt_debug/numba/numba/core/pythonapi.py", line 1405, in from_native_return
    out = self.from_native_value(typ, val, env_manager)
  File "/home/kaustubh/Desktop/WorkSpaces/Numba Workspace/nrt_debug/numba/numba/core/pythonapi.py", line 1419, in from_native_value
    return impl(typ, val, c)
  File "/home/kaustubh/Desktop/WorkSpaces/Numba Workspace/nrt_debug/numba/numba/core/boxing.py", line 432, in box_array
    c.context.nrt.decref(c.builder, typ, val)
```
<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: kc611
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - medium: Medium size effort needed
issue_8703: state: open
title: Numba and Debian Bookworm
body: Hello! The Debian Bookworm release schedule is [entering a growing series of freezes](https://release.debian.org/testing/freeze_policy.html), and I've been trying to map what would be needed for numba to make it in time.

Currently, numba cannot build in Debian testing due to these toolchain dependencies:

* [ ] onetbb 2021.8.0 https://github.com/numba/numba/issues/8487 
* [ ] numpy 1.24 https://github.com/numba/numba/issues/8464
* [ ] python 3.11.1 https://github.com/numba/numba/issues/8304

I see that work is ongoing on most of those fronts, and I don't know how likely it is that a new release of numba can happen in time for the 2023-02-12 soft freeze.

I'm not using numba directly, but it's a dependency of a package I maintain in Debian. If there's hope and can be useful, I volunteer to test building release candidates, and let me know if there's anything else that I can do.
user: spanezz
labels: discussion: An issue requiring discussion
issue_8700: state: open
title: RFC: Separate NumPy and CPython implementions/functionality.
body: This is an RFC on altering Numba's fundamental numerical functionality to better reflect what is present in Python/NumPy. The intended impact of this is to:

* Ensure better reproducibility, i.e. Numba will more closely follow what would happen in the interpreter.
* Alter performance characteristics with an anticipated net performance gain.
* Create conceptually easier paths to follow to achieve higher performance.

**Current state:**

At present, the Numba code base implements a large number of the functions found in Python builtins, Python's `operator`, `math` and `cmath` modules, and NumPy. Due to historical reasons (largely from the way in which the compiler was bootstrapped) a lot of the implementations of the functions are reasonable approximations for "common" input values that are in use by most users, but they often fail to replicate functionality _exactly_.

This "reasonable approximation" has served Numba well, but the current state has a few fundamental problems:

1. The functions often call into each others' implementations, for example NumPy `ufuncs` that "borrow" implementation details from the `math` module. The performance characteristics can be somewhat unpredictable due to this as the implementations from Python modules often contain exception handling whereas NumPy does not. Exceptions lead to branches which lead to lost optimisation opportunities in e.g. vectorization.
2. The implementations are sufficiently acceptable along "common" paths, but are often not correctly implemented with respect to things like type promotion or error handling.
3. Whilst this is an implementation detail, due to the state of the current code base the reusability of the implementations across hardware targets involves a lot of boilerplate and copy-paste to fix things e.g. on CUDA swapping libm/intrinsic `cos` calls for CUDA libdevice `cos` calls.
4. Numba's type system aliases Python `int` with NumPy `intp`, `float` with NumPy `float64` and `complex` with NumPy `complex128`. This makes it hard to be specific about what the behaviour _should_ be when e.g. raw numerical values interact with e.g. NumPy functions.

**Some examples of the above issues:**

This example demonstrates the problems noted in 2. that for simple integer and float inputs to a "power"-like function quite a large spectrum of result values, result types and error handling behaviours are produced.

```python
import operator
import math
import numpy as np

def operator_pow(a, b):
    return operator.pow(a, b)

def math_pow(a, b):
    return math.pow(a, b)

def np_pow(a, b):
    return np.power(a, b)

for x, y in ((2, 2), (2.1, 2), (2.1, 1.3), (2.1, 0.3), (2, 0.3), (2.1, -1),
             (2, -1), (2.1, -1.2), (-2., -1), (-2, -2.1), (-2.1, -0.2)):

    buf = [f"x={x:<4}, y={y:<4}: "]
    for key, fn in (('o', operator_pow), ('m', math_pow), ('n', np_pow)):
        try:
            o = fn(x, y)
            if isinstance(o, (int, np.integer)):
                prec = '6'
            else:
                prec = '6.4'
            ofmt = f'{key}: {str(type(o)):<18}{o:<{prec}} '
        except Exception as e:
            ofmt = f'{key}: {e} '
        buf.append(ofmt)
    print(''.join(buf))
```
which produces:
```
x=2   , y=2   : o: <class 'int'>     4      m: <class 'float'>   4.0    n: <class 'numpy.int64'>4
x=2.1 , y=2   : o: <class 'float'>   4.41   m: <class 'float'>   4.41   n: <class 'numpy.float64'>4.41
x=2.1 , y=1.3 : o: <class 'float'>   2.624  m: <class 'float'>   2.624  n: <class 'numpy.float64'>2.624
x=2.1 , y=0.3 : o: <class 'float'>   1.249  m: <class 'float'>   1.249  n: <class 'numpy.float64'>1.249
x=2   , y=0.3 : o: <class 'float'>   1.231  m: <class 'float'>   1.231  n: <class 'numpy.float64'>1.231
x=2.1 , y=-1  : o: <class 'float'>   0.4762 m: <class 'float'>   0.4762 n: <class 'numpy.float64'>0.4762
x=2   , y=-1  : o: <class 'float'>   0.5    m: <class 'float'>   0.5    n: Integers to negative integer powers are not allowed.
x=2.1 , y=-1.2: o: <class 'float'>   0.4105 m: <class 'float'>   0.4105 n: <class 'numpy.float64'>0.4105
x=-2.0, y=-1  : o: <class 'float'>   -0.5   m: <class 'float'>   -0.5   n: <class 'numpy.float64'>-0.5
x=-2  , y=-2.1: o: <class 'complex'> (0.2218-0.07208j) m: math domain error n: <class 'numpy.float64'>nan
x=-2.1, y=-0.2: o: <class 'complex'> (0.6975-0.5067j) m: math domain error n: <class 'numpy.float64'>nan
```

Things to note:
1. The types of the outputs are not consistent across implementations (integer vs. floating point output type).
2. The behaviour with respect to the numerical "domains" is not consistent, some implementations raise, others do the "mathematically correct" thing, others return `nan`. That NumPy always returns a value without raising is good for performance as there will be no branches to check for exceptions, this leads to more vectorization opportunities.

This example shows that `math` functions call the `__float__` method on the type and actually operate in double precision, contrary to NumPy, which specialises:

```python
import numpy as np
import math
import ctypes
from ctypes.util import find_library
libm_name = find_library('m')
libm = ctypes.CDLL(libm_name)
libm.sin.argtypes=(ctypes.c_double,)
libm.sin.restype=ctypes.c_double

x = np.float16(1.2)

m = math.sin(x)
print(type(m), m)

n = np.sin(x)
print(type(n), n)

def fake_math(x):
    return libm.sin(x.__float__())

f = foo(x)
print(type(f), f)
```
which produces:
```
<class 'float'> 0.9321098411884629
<class 'numpy.float16'> 0.932
<class 'float'> 0.9321098411884629
```

Things to note:
1. That the `math` module converts input values to double precision via `__float__` and then runs double precision numerical functions on these values.
2. NumPy `ufuncs` specialise on the type of the `float`, this gives better performance.

**Thoughts on target specific behaviours:**

Numba currently supports CPU and CUDA targets. Due to recent work it's now possible to write `@overload`s of functions that are "generic" i.e. should work on any hardware, and also to specialised overloads so as to target specific hardware. Having started to use this functionality/API more, it's become clear that the point of abstraction where "target specific" implementations must exist is at the point where there is some fundamental difference in the actual target, e.g. something only exists on a particular target or there are some performance specialisations available for a particular target. The relevant point of abstraction for the implementation of mathematical functionality is at calls to the underlying maths library as this is something that is solely _called_ by Numba and differs specifically at the hardware target level.

**The proposal:**

Considering all of the above, it's proposed that Numba internals for Python numerical builtins, `operator`, `math`/`cmath` and `numpy` (particularly the ufuncs) are altered to reflect the actual behaviours present when executing in the Python interpreter. The impact is anticipated to be as follows:

1. The new behaviour would be more correct in its replication of execution in the Python interpreter, and predictably so. This may have an impact on users that are relying on the implementation details of current Numba implementations, it's expected that this is a small number of users.
2. The builtins, `operator` and `math`/`cmath` modules would all behave correctly with respect to numerical domains and raise exceptions appropriately. The performance impact of this is that use of these functions will make it much harder for the underlying optimisers. It's suggested that a `NumbaPerformanceWarning` encouraging the use of NumPy is issued if functions from these modules are used. The number of users impacted by this is not known, but is probably quite small as most will be using NumPy already. The outlier in this is users of the CUDA target for which there is no NumPy `ufunc` support at present, this is being implemented in #8294 to create an "upgrade" path.
3. The NumPy `ufuncs` would all be implemented in a largely exception-free manner as they are in NumPy, this better replicates NumPy and also has the advantage that optimisation passes which attempt vectorization will be able to do more as there are fewer branches. Further, encouraging users to use the overloaded NumPy functionality would also mean their code can be type specialised correctly, i.e. `float32` inputs will (typically) produce `float32` output. This makes it very easy to gain performance, simply "use NumPy".
4. Much of the new/updated numerical code can be implemented for the "generic" target. The only place where there needs to be a target specific abstraction is at the point of calling the underlying target's specific maths library. In the case of the CPU this is a mix of `llvm` intrinsics and `libm` calls, in the case of CUDA it's the use of `libdevice`. It should be possible to create a `math_h` module which contains overloadable stubs based on functions declared in `C`'s `math.h`. All the rest of the Python and NumPy functionality can be implemented based on this `math_h` module in a manner similar to how it is written in the existing original implementations. This provides maximum reuse of code and makes it very easy for "new" hardware targets to make use of this functionality, all that would be needed is to create the target specific overloads for the `math_h` stubs.


The above proposal intends to address items 1, 2 and 3 as listed in the "Current state" above. Item 4 will not be addressed, however, with this adjustment to the implementations it should be easier to make changes to the type system as the implementations of CPython and NumPy functions will be correctly separated such that types won't "leak" between implementations.

user: stuartarchibald
labels: RFC: Request for Comments
issue_8693: state: open
title: Access to outer variables in nested functions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I don't know if it is a bug. In the nested functions, variables defined before the function definition can be accessed in both python and nopython mode, and variables defined after the function definition can not be accessed in nopython mode but can be accessed in python mode. Examples are below:

```python
import numba


@numba.njit
def func1():
    msg = "func1() called"

    def wrapper():
        print(msg)

    wrapper()


@numba.njit
def func2():
    def wrapper():
        print(msg)

    msg = "func2() called"
    wrapper()


if __name__ == "__main__":
    print("\nPython mode\n")
    func1.py_func()  # works
    func2.py_func()  # works

    print("\nNumba mode\n")
    func1()  # works
    func2()  # fails
```

Here is the error message:
```
PS C:\Users\Hailin\OneDrive\Desktop\numba-test> python .\test.py

Python mode

func1() called
func2() called

Numba mode

func1() called
Traceback (most recent call last):
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\core\ir.py", line 267, in get
    return self._con[name]
KeyError: 'msg'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\core\ir.py", line 1124, in get_exact
    return self.localvars.get(name)
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\core\ir.py", line 269, in get
    raise NotDefinedError(name)
numba.core.errors.NotDefinedError: The compiler failed to analyze the bytecode. Variable 'msg' is not defined.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\core\ir.py", line 267, in get
    return self._con[name]
KeyError: 'msg'
```
user: haiiliin
labels: bug - ice: Bugs: internal compiler error
bug - failure to compile: Bugs: failed to compile valid code
issue_8682: state: open
title: Privatization of variables defined inside prange
body: My original question was whether or not a variable defined inside a `prange` is independent (privatized) across the loop, so that running it in parallel yields the expected result. For example, whether `axes_hits` is indeed branched between loops so that there are no cross-alterations.


```python
@njit(parallel = True)
def get_axis_filter(line_indexes, column_indexes):
    n_solutions = line_indexes.shape[0]
    filter_ = np.full(solutions.shape[0], True)

    for i in prange(line_indexes.shape[0]):
        axes_hits = [0]*10 
        for j in range(line_indexes.shape[1]):
            l_i = line_indexes[i,j]
            c_i = line_indexes[i,j]
            if l_i==c_i:
                axes_hits[l_i] +=  1
            else:
                axes_hits[l_i] += 1
                axes_hits[c_i] += 1
        if max(axes_hits) > 5:
            filter_[i] = False
    return filter_
```

My suggestion would be to make this more explicit in the docs. I suppose this might be implicit in the [here](https://numba.pydata.org/numba-doc/latest/user/parallel.html#supported-operations), but perhaps it could be beneficial to refer this privatization process more explicitly, as for me it was not super clear.


user: Astlaan
issue_8681: state: open
title: Numba crashes Python with simple function containing numpy.exp
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

This simple script, called with `python script.py`, crashes Python without printout or error message:

```python
from numba import jit
import numpy as np

@jit
def f(x):
  return np.exp(x)
 
x = np.array([1.3,2.6,3.9])
y = f(x)

print(y)
```

Setup:
- Python 3.10.9 (tags/v3.10.9:1dd9be6, Dec  6 2022, 20:01:21) [MSC v.1934 64 bit (AMD64)] on win32
- Minimal installation - output of ` pip list`:
  ```
  Package    Version
  ---------- -------
  llvmlite   0.39.1
  numba      0.56.4
  numpy      1.23.5
  pip        22.3.1
  setuptools 65.5.0
  ```

Further info:
- Using `np.sum`  in place of `np.exp` works and prints the result.
- Specifying the signature explicitly via `@jit("float64[:](float64[:])")` works.
- Replacing `@jit` by `@jit(debug=True)` gives the following output:
  ```
  C:\Python310\lib\site-packages\numba\core\lowering.py:107: NumbaDebugInfoWarning: Could not find source for function: 
  <function __numba_array_expr_0x1df764a3cd0 at 0x000001DF7649CD30>. Debug line information may be inaccurate.
    warnings.warn(NumbaDebugInfoWarning(msg))
  [ 3.66929667 13.46373804 49.40244911]
  ```






user: stestoll
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
svml: Issue involves SVML
issue_8679: state: open
title: njit(cache=True) is not idempotent  (with generators?)
body: I'm seeing that ```njit(cache=True)``` produces exceptions on its second run, where it succeeded in the first. It's not idempotent.

Run scratch.py. Success. Run again, long error.

The error goes away with this change:
```
#@numba.njit(nogil=True, cache=True)
@numba.njit(nogil=True, cache=False)
def posToRegion(x, y, w, h, size):...
```
(Run twice to be sure)

Possibly, calling a generator from numba causes the problem. I couldn't trigger the problem when calling the posToRegionPixelIndexes generator directly from python.

```
#File: scratch.py
import numpy as np
from scratch_b import *

import numba

w, h = 1920, 1080
apositions = np.array([[419, 848],
                       [419, 848],
                       [421, 851],
                       [621, 884]], dtype=np.int32)

@numba.njit(nogil=True, cache=False)
def _nearbyMatches(apos,
                   w, h,
                   ):
    for jpixIndex_ in posToRegionPixelIndexes(apos[0, 0], apos[0, 1], w, h):
        return


# No problem
# print(list(posToRegionPixelIndexes(apositions[0, 0], apositions[0, 1], w, h)))

print("_nearbyMatches")
# Fails
_nearbyMatches(apositions, 1920, 1080)
print("_nearbyMatches...")
```

```
#file: scratch_b.py
import numba

@numba.njit(nogil=True, cache=True)
def posToRegion(x, y, w, h, size):
    x0, x1 = x - size, x + size + 1
    y0, y1 = y - size, y + size + 1
    if x0 < 0: x0 = 0
    if y0 < 0: y0 = 0
    if x1 > w: x1 = w
    if y1 > h: y1 = h
    return (x0, x1), (y0, y1)

@numba.njit(nogil=True, cache=True)
def posToRegionPixelIndexes(x, y, w, h, size=2):
    (x0, x1), (y0, y1) = posToRegion(x, y, w, h, size)
    nrows, ncols = y1 - y0, x1 - x0
    rowstart = y0 * w + x0
    for _ in range(nrows):
        i = rowstart
        for _ in range(ncols):
            yield i
            i += 1
        rowstart += w

```

Numba: 0.56.4
Python 10

```
Traceback (most recent call last):
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/errors.py", line 823, in new_error_context
    yield
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 265, in lower_block
    self.lower_inst(inst)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 439, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 626, in lower_assign
    return self.lower_expr(ty, value)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 1186, in lower_expr
    res = impl(self.builder, (castval,))
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/base.py", line 1190, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/base.py", line 1220, in wrapper
    return fn(*args, **kwargs)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/imputils.py", line 336, in wrapper
    func(context, builder, sig, args,
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/cpython/iterators.py", line 128, in iternext_zip
    impl = context.get_generator_impl(genty)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/base.py", line 571, in get_generator_impl
    res = self._generators[genty][1]
KeyError: int64 generator(func=<function posToRegionPixelIndexes at 0x7faae1f49120>, args=(int32, int32, int64, int64, omitted(default=2)), has_finalizer=True)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/dispatcher.py", line 487, in _compile_for_args
    raise e
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/dispatcher.py", line 965, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/dispatcher.py", line 125, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/dispatcher.py", line 139, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/dispatcher.py", line 152, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler.py", line 716, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler.py", line 452, in compile_extra
    return self._compile_bytecode()
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler.py", line 520, in _compile_bytecode
    return self._compile_core()
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler.py", line 499, in _compile_core
    raise e
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler.py", line 486, in _compile_core
    pm.run(self.state)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 368, in run
    raise patched_exception
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 356, in run
    self._runPass(idx, pass_inst, state)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 311, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/compiler_machinery.py", line 273, in check
    mangled = func(compiler_state)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/typed_passes.py", line 394, in run_pass
    lower.lower()
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 168, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 222, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 251, in lower_function_body
    self.lower_block(block)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/lowering.py", line 263, in lower_block
    with new_error_context('lowering "{inst}" at {loc}', inst=inst,
  File "/usr/lib/python3.10/contextlib.py", line 153, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/home/sir/venv/p310_opencv/lib/python3.10/site-packages/numba/core/errors.py", line 837, in new_error_context
    raise newerr.with_traceback(tb)
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
int64 generator(func=<function posToRegionPixelIndexes at 0x7faae1f49120>, args=(int32, int32, int64, int64, omitted(default=2)), has_finalizer=True)

File "scratch.py", line 16:
def _nearbyMatches(apos,
    <source elided>
                   ):
    for jpixIndex_ in posToRegionPixelIndexes(apos[0, 0], apos[0, 1], w, h):
    ^

During: lowering "$24for_iter.1 = iternext(value=$phi24.0)" at .../scratch.py (16)
Exception ignored in: <module 'threading' from '/usr/lib/python3.10/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1567, in _shutdown
    lock.acquire()
KeyboardInterrupt: 
````
user: stuz5000
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_8678: state: open
title: Remaining py3.11 with-lifting failures
body: Details for some failures on https://github.com/numba/numba/issues/8304

Non-trivial with-lifting failures that is caused by py3.11 bytecode changes:

A) `numba.tests.test_try_except.TestTryExceptOtherControlFlow.test_objmode_output_type`
  
  The test checks with-lifting compatibility with try-except but it is broken for the following case due to changes in bytecode:

  ```python
  try:
      with ...:
          ...
  except:
      ...
  ```
B) `numba.tests.test_withlifting.TestLiftCall.test_liftcall5`
  
  The test checks with-lifting support but it is broken for the following case due to changes in bytecode:

  ```python
  for ...
    with ...
      break
```

C) `numba.tests.test_withlifting.TestLiftObj.test_case19_recursion`
  
  The test checks with-lifting support but it is broken for the following case due to changes in bytecode:

  ```python
  with ...
    return
  ```


user: sklam
labels: Python 3.11: All issues related to Python 3.11 support
issue_8676: state: open
title: numba dict converts between int types
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:


- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

-->

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I'm trying to make a dict of type `{(uint32, uint32): uint32}`.  However, numba seems to be converting back and forth between uint32 and int64 somewhere under the hood.

Code to reproduce:
```python
import numba as nb, numpy as np

key = (np.uint32(0), np.uint32(0))
value = np.uint32(0)

dct = nb.typed.Dict.empty(
  key_type = nb.typeof(key),
  value_type = nb.uint32,
)

dct.update({key: value})
print(dct)

for k, v in dct.items():
  print(k, v, nb.typeof(k), nb.typeof(v))
```

What I expect:
```
$ python bug.py
{(0, 0): 0}
(0, 0) 0 UniTuple(uint32 x 2) uint32
```

What I get (python 3.9.12, numpy 1.23.5, numba 0.56.4):
```
$ python bug.py
/.../python3.9/site-packages/numba/typed/typeddict.py:38: NumbaTypeSafetyWarning: unsafe cast from UniTuple(int64 x 2) to UniTuple(uint32 x 2). Precision may be lost.
  return d[key]
{(0, 0): 0}
(0, 0) 0 UniTuple(int64 x 2) int64
```
user: hroskes
labels: bug - typing: Bugs: occuring at typing time
issue_8674: state: open
title: Enforce that no warnings are raised on listing of tests.
body: As title. This is minor clean up to ensure that there are no warnings raised when the tests are listed e.g. via `./runtests.py -l`.

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: stuartarchibald
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - short: Short size effort needed
issue_8669: state: open
title: Convert static PyTypeObject structures to heap allocated types.
body: As title. From the suggestion here https://github.com/numba/numba/pull/8666#discussion_r1046501580, with view of making it such that it is no longer necessary to have to migrate the static `PyTypeObjects` (as undertaken in that PR).
user: stuartarchibald
issue_8665: state: open
title: Lowering Error
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x
![numba_error](https://user-images.githubusercontent.com/55020862/207049448-0ac1d88e-ef36-4d5c-8181-e998f329354b.jpg)
 ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: h4mmad
labels: CUDA: CUDA related issue/PR
bug - ice: Bugs: internal compiler error
issue_8664: state: open
title: Caching fails when default argument value is nan
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

File test.py:

```python
from numba import njit

@njit(cache=True)
def f_finite(x=0):
    pass

@njit(cache=True)
def f_nan(x=float("nan")):
    pass

@njit(cache=True)
def f_inf(x=float("inf")):
    pass
```

Running the functions for the _second_ time:

```python
import os
os.environ['NUMBA_DEBUG_CACHE'] = "1"

from test import f_finite, f_nan, f_inf

f_finite()
[cache] index loaded from '/.../test.f_finite-3.py39.nbi'
[cache] data loaded from '/.../test.f_finite-3.py39.1.nbc'

f_nan()
[cache] index loaded from '/.../test.f_nan-7.py39.nbi'
[cache] index loaded from '/.../test.f_nan-7.py39.nbi'
[cache] index saved to '/.../test.f_nan-7.py39.nbi'
[cache] data saved to '/.../test.f_nan-7.py39.2.nbc'

f_inf()
[cache] index loaded from '/.../test.f_inf-11.py39.nbi'
[cache] data loaded from '/.../test.f_inf-11.py39.1.nbc'
```

While I understand that it's all based on identity checks and nan != nan and one can use None as a substitution, every time the users passes `np.nan` (for example as a fill value for an array), the function will be needlessly re-cached.
user: polakowo
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_8663: state: open
title: Add `.tobytes()` method for Numpy arrays
body: This adds support for the `tobytes` method for NumPy arrays. This makes it easier to hash numpy arrays, so we can use short arrays as dictionary keys (which is useful for certain structured arrays).

I tried my best to figure out how everything fits together, but feel free to tell me if I did something incorrectly! In particular, I'm still confused about two things:
- the `array_tobytes` intrinsic seems unnecessary, but I couldn't figure out how to just call the casting code from the `@lower_cast` `array_to_bytes` in my overload. Is there some way to do that, or some other way I should structure the code?
- I'm a little concerned about the speed. In particular, for c-contiguous arrays, somehow I end up being 2-3 times slower than the Numpy's implementation, even for large arrays (e.g. `np.random.rand(50000, 2, 3)`). I can't see how to optimize it any further (presumably memcpy should be as fast as possible?), so not sure how where this slowdown occurs.

Closes #5149
user: alanhdu
labels: 4 - Waiting on author: Waiting for author to respond to review
Effort - short: Short size effort needed
issue_8658: state: open
title: [FEA] Add Support for linking C/C++ with `@numba.jit` functions
body: Hi, I think supporting for linking C/C++ with `@numba.jit` functions could be beneficial for some situations, for example, when we can't use Python / Numba / llvmlite interface to write certain kinds of functionality, especially if this functionality depends on some C/C++ libraries.

And without this feature, LLVM can't do many optimizations when calling from LLVM IR to the shared library including the related C/C++ code, which does hurt the performance, I guess.

Just as graham has already done in #7621, I think we need it also for CPU target in the future.
user: dlee992
issue_8654: state: open
title: literal_unroll with empty iterables
body: `literal_unroll` seems not to function if the iterable is empty. A working version of this would be useful for generic code where the container is empty in only some cases.

```python
from numba import literal_unroll, njit

values = ()

@njit
def foo(x):
    for i in literal_unroll(values):
        x = 2 * x
    return x

foo(1)
# TypingError
```

Error message:

<details>

```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Cell In[25], line 11
      8         x = 2 * x
      9     return x
---> 11 foo(1)

File ~/git/numba/numba/core/dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 468     error_rewrite(e, 'typing')
    469 except errors.UnsupportedError as e:
    470     # Something unsupported is present in the user code, add help info
    471     error_rewrite(e, 'unsupported_error')

File ~/git/numba/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of getiter with parameters (Tuple())

During: typing of intrinsic-call at /tmp/ipykernel_248127/3170280045.py (7)

File "../../../../tmp/ipykernel_248127/3170280045.py", line 7:
<source missing, REPL/exec in use?>
```

</details>

This is with the current numba main branch.
user: aseyboldt
labels: bug - typing: Bugs: occuring at typing time
issue_8653: state: open
title: Nested reflected list fails to type with inner lists of differing types.
body: The code below works:
```
import numpy as np
import numba as nb

@nb.njit()
def func():
    inp_arr = np.array([2, 3j], dtype =nb.complex128)
    return

func()
```
but if you make it a multidimensional array, such as in the code below, the code breaks:
```
import numpy as np
import numba as nb

@nb.njit()
def func():
    inp_arr = np.array([[1, 0],
                        [2, 3j]], dtype =nb.complex128)
    return

func()
```
This gives me the error:
```
Traceback (most recent call last):

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\spyder_kernels\py3compat.py", line 356, in compat_exec
    exec(code, globals, locals)

  File "c:\users\micha\onedrive\documenten\uni shit\thesis\pythonforthesis\untitled0.py", line 10, in <module>
    func()

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\dispatcher.py", line 487, in _compile_for_args
    raise e

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\dispatcher.py", line 965, in compile
    cres = self._compiler.compile(args, return_type)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\dispatcher.py", line 125, in compile
    status, retval = self._compile_cached(args, return_type)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\dispatcher.py", line 139, in _compile_cached
    retval = self._compile_core(args, return_type)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\dispatcher.py", line 152, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler.py", line 693, in compile_extra
    return pipeline.compile_extra(func)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler.py", line 429, in compile_extra
    return self._compile_bytecode()

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler.py", line 497, in _compile_bytecode
    return self._compile_core()

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler.py", line 476, in _compile_core
    raise e

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler.py", line 463, in _compile_core
    pm.run(self.state)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler_machinery.py", line 353, in run
    raise patched_exception

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler_machinery.py", line 341, in run
    self._runPass(idx, pass_inst, state)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler_machinery.py", line 296, in _runPass
    mutated |= check(pss.run_pass, internal_state)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\compiler_machinery.py", line 269, in check
    mangled = func(compiler_state)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\typed_passes.py", line 394, in run_pass
    lower.lower()

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 196, in lower
    self.lower_normal_function(self.fndesc)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 250, in lower_normal_function
    entry_block_tail = self.lower_function_body()

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 279, in lower_function_body
    self.lower_block(block)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 293, in lower_block
    self.lower_inst(inst)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 438, in lower_inst
    val = self.lower_assign(ty, inst)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 624, in lower_assign
    return self.lower_expr(ty, value)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 1319, in lower_expr
    castvals = [self.context.cast(self.builder, val, fromty,

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\lowering.py", line 1319, in <listcomp>
    castvals = [self.context.cast(self.builder, val, fromty,

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\core\base.py", line 713, in cast
    return impl(self, builder, fromty, toty, val)

  File "C:\Users\Micha\Downloads\Laptop-Python\ANACONDA\lib\site-packages\numba\cpython\listobj.py", line 1131, in list_to_list
    assert fromty.dtype == toty.dtype

AssertionError: Failed in nopython mode pipeline (step: native lowering)
```
user: Rafnus
labels: bug - typing: Bugs: occuring at typing time
issue_8652: state: open
title: Segfault in `@njit(parallel=True)`-decorated function
body: Hi!

I'm getting a segfault crash in my environment when running a function decorated with `@njit(parallel=True)`, as in the example below. The key feature triggering the problem is reading from different parts of input simultaneously. Since it's **reading** (rather than writing), I assume it should not be subject to race condition or anything.

```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def run(input):
    result = np.zeros(shape=input.shape, dtype=input.dtype)
    for i in prange(len(input)):
        result[i] = input[i] + input[-i]
    return result

if __name__ == "__main__":
    N = 1000000
    run(np.random.uniform(size=(N, 3)),)
    print("done")
```

I was not able to reproduce this on google colab.
My environment is the following:
Ubuntu 20.04.5 under WSL2
python 3.9.12 from miniconda
numba 0.56.4

I'm also getting the following output when jitting with `parallel=True` (not sure whether related):
```
OMP: Info #276: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
```


Here's also info from GDB and back trace:

```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffde103700 (LWP 6267)]
[New Thread 0x7fffdd902700 (LWP 6268)]
[New Thread 0x7fffd9101700 (LWP 6269)]
[New Thread 0x7fffd6900700 (LWP 6270)]
[New Thread 0x7fffd40ff700 (LWP 6271)]
[New Thread 0x7fffd18fe700 (LWP 6272)]
[New Thread 0x7fffcf0fd700 (LWP 6273)]
OMP: Info #276: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
[New Thread 0x7fffc950d780 (LWP 6281)]
[New Thread 0x7fffc8d0b800 (LWP 6282)]
[New Thread 0x7fffc3ffe880 (LWP 6283)]
[New Thread 0x7fffc37fc900 (LWP 6284)]
[New Thread 0x7fffc2ffa980 (LWP 6285)]
[New Thread 0x7fffc27f8a00 (LWP 6286)]
[New Thread 0x7fffc1ff6a80 (LWP 6287)]

Thread 11 "python" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc3ffe880 (LWP 6283)]
0x00007fffcb51635e in _3cdynamic_3e::__numba_parfor_gufunc_0x7fffcb753c40[abi:v11][abi:c8tJTC_2fWQAlbW1yBC0oR6GELEUMELYSPGrIQMVjAQniQcIXKQIMVwoOGKoQDDVQQR1NHAS2FQ9XgSs8waUSQ24JtBVpeBJHUBAA_3d](Array<unsigned long long, 1, C, mutable, aligned>, Array<double, 2, C, mutable, aligned>, Array<double, 2, C, mutable, aligned>) ()
(gdb) backtrace 
#0  0x00007fffcb51635e in _3cdynamic_3e::__numba_parfor_gufunc_0x7fffcb753c40[abi:v11][abi:c8tJTC_2fWQAlbW1yBC0oR6GELEUMELYSPGrIQMVjAQniQcIXKQIMVwoOGKoQDDVQQR1NHAS2FQ9XgSs8waUSQ24JtBVpeBJHUBAA_3d](Array<unsigned long long, 1, C, mutable, aligned>, Array<double, 2, C, mutable, aligned>, Array<double, 2, C, mutable, aligned>) ()
#1  0x00007fffcb5131fe in __gufunc__._ZN13_3cdynamic_3e36__numba_parfor_gufunc_0x7fffcb753c40B3v11B104c8tJTC_2fWQAlbW1yBC0oR6GELEUMELYSPGrIQMVjAQniQcIXKQIMVwoOGKoQDDVQQR1NHAS2FQ9XgSs8waUSQ24JtBVpeBJHUBAA_3dE5ArrayIyLi1E1C7mutable7alignedE5ArrayIdLi2E1C7mutable7alignedE5ArrayIdLi2E1C7mutable7alignedE ()
#2  0x00007fffcb527264 in parallel_for () at numba/np/ufunc/omppool.cpp:204
#3  0x00007ffff11ebffc in __kmp_GOMP_microtask_wrapper () from /home/USERNAME/miniconda3/lib/python3.9/site-packages/mkl/../../../libiomp5.so
#4  0x00007ffff1287053 in __kmp_invoke_microtask () from /home/USERNAME/miniconda3/lib/python3.9/site-packages/mkl/../../../libiomp5.so
#5  0x00007ffff1203353 in __kmp_invoke_task_func () from /home/USERNAME/miniconda3/lib/python3.9/site-packages/mkl/../../../libiomp5.so
#6  0x00007ffff1202362 in __kmp_launch_thread () from /home/USERNAME/miniconda3/lib/python3.9/site-packages/mkl/../../../libiomp5.so
#7  0x00007ffff1287cdc in _INTERNALdb99f3be::__kmp_launch_worker(void*) () from /home/USERNAME/miniconda3/lib/python3.9/site-packages/mkl/../../../libiomp5.so
#8  0x00007ffff7e43609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#9  0x00007ffff7d68133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```

user: SiLiKhon
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
bug - incorrect behavior: Bugs: incorrect behavior
bug - typing: Bugs: occuring at typing time
issue_8646: state: open
title: cannot infer type of empty numpy array in local scope of jitclass, although explicitly given.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Test

-->

I have code that I want to wrap as Jitclasses. When I try to run the following code:
```python
import numba as nb
import numpy as np
from numba.experimental import jitclass

spec = [("x", nb.float64[:])]

@jitclass(spec=spec)
class Works:
    def __init__(self, x=np.array([], dtype='float')):
        self.x = x

@jitclass(spec=spec)
class Workstoo:
    def __init__(self):
        self.x = np.array([1.0], dtype='float')

@jitclass(spec=spec)
class DoesntWork:
    def __init__(self):
        self.x = np.array([], dtype='float')

w = Works()
wt = Workstoo()
dw = DoesntWork()
```
creating `DoesntWork()` will cause python to crash with the following error:
```

Failed in nopython mode pipeline (step: nopython frontend)
Type of variable '$12call_function_kw.5' cannot be determined, operation: call $4load_attr.1($6build_list.2, func=$4load_attr.1, args=[Var($6build_list.2, jitclass_example.py:20)], kws=[('dtype', Var($const8.3, jitclass_example.py:20))], vararg=None, varkwarg=None, target=None), location: C:\Users\johnhelt\Documents\OneDrive - Teracloud AB\numerous-solver\jitclass_example.py (20)

File "jitclass_example.py", line 20:
    def __init__(self):
        self.x = np.array([], dtype='float')
        ^

During: resolving callee type: jitclass.DoesntWork#17d40107010<x:array(float64, 1d, A)>
During: typing of call at <string> (3)

During: resolving callee type: jitclass.DoesntWork#17d40107010<x:array(float64, 1d, A)>
During: typing of call at <string> (3)


File "<string>", line 3:
<source missing, REPL/exec in use?>
```
Although the code is the same really. It seems that numba cannot infer the type of the variable when it's an empty list AND inside the `__init__` scope of the class, but if it's externally defined, or non-empty, then there's no problem. This is inspite of me specifying the data type explicitly.
user: mrdobalina2k
labels: bug - typing: Bugs: occuring at typing time
issue_8643: state: open
title: py3.11 cleanup task: Make these register names match those that are generated for < 3.11.
body:         Note to self. Make these register names match those that are generated for < 3.11.

_Originally posted by @stuartarchibald in https://github.com/numba/numba/pull/8639#discussion_r1039601794_
      
user: sklam
labels: Python 3.11: All issues related to Python 3.11 support
issue_8642: state: open
title: `_jump_if_none` fix up in py3.11 branch
body:         `inst.next` is the fallthrough branch. `inst.get_jump_target()` is the take-the-jump branch. need to fix up the `truebr` `falsebr` variable naming.

_Originally posted by @sklam in https://github.com/numba/numba/pull/8639#discussion_r1039906574_
      
user: sklam
labels: Python 3.11: All issues related to Python 3.11 support
issue_8640: state: open
title: setattr on an optional type doesn't redirect to the inner type
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

This seems to be a regression of 
- https://github.com/numba/numba/issues/2606 
- originally fixed in  https://github.com/numba/numba/pull/2610

Also related:
- https://numba.discourse.group/t/cannot-remove-element-from-double-linked-list/1119

Here is a reproducer:

```python
import numba
from numba.experimental import jitclass
import numpy as np

node_type = numba.deferred_type()

@jitclass(spec=[
    ("value", numba.float64),
    ("left", numba.optional(node_type)),
    ("right", numba.optional(node_type)),
])
class Node:
    def __init__(self, value):
        self.value = value
        self.left = None
        self.right = None

node_type.define(Node.class_type.instance_type)

@numba.njit
def node_insert(node, value):
    if value <= node.value:
        if node.left is None:
            node.left = Node(value)
        else:
            node_insert(node.left, value)
    else:
        if node.right is None:
            node.right = Node(value)
        else:
            node_insert(node.right, value)

@numba.njit
def fn(a):
    assert len(a) > 0
    tree = Node(a[0])

    for value in a[1:]:
        node_insert(tree, value)

    return tree

if __name__ == "__main__":
    print(fn(np.arange(10)))
```

The traceback is as follows with `No definition for lowering DeferredType#140484577449904.left = OptionalType(DeferredType#140484577449904)` identifying the problem.

```traceback
Traceback (most recent call last):
  File "/home/simon/code/codex-africanus/essays/reproducer.py", line 46, in <module>
    print(fn(np.arange(10)))
  File "/home/simon/venv/afr/lib/python3.10/site-packages/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/simon/venv/afr/lib/python3.10/site-packages/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x7fc4f4766b30>.
Failed in nopython mode pipeline (step: native lowering)
No definition for lowering DeferredType#140484577449904.left = OptionalType(DeferredType#140484577449904)

File "reproducer.py", line 24:
def node_insert(node, value):
    <source elided>
        if node.left is None:
            node.left = Node(value)
            ^

During: lowering "(node).left = $26call_function.2" at /home/simon/code/codex-africanus/essays/reproducer.py (24)
During: resolving callee type: recursive(type(CPUDispatcher(<function node_insert at 0x7fc54cba7d90>)))
During: typing of call at /home/simon/code/codex-africanus/essays/reproducer.py (26)

Enable logging at debug level for details.

File "reproducer.py", line 26:
def node_insert(node, value):
    <source elided>
        else:
            node_insert(node.left, value)
            ^

During: resolving callee type: type(CPUDispatcher(<function node_insert at 0x7fc54cba7d90>))
During: typing of call at /home/simon/code/codex-africanus/essays/reproducer.py (40)

During: resolving callee type: type(CPUDispatcher(<function node_insert at 0x7fc54cba7d90>))
During: typing of call at /home/simon/code/codex-africanus/essays/reproducer.py (40)


File "reproducer.py", line 40:
def fn(a):
    <source elided>
    for value in a[1:]:
        node_insert(tree, value)
```

user: sjperkins
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8635: state: open
title: CUDA: `test_ptds` is prone to hanging on Windows
body: As observed on the buildfarm, `test_ptds` can hang on Windows. I can also reproduce the hang, if I increase `N_THREADS` to 100.

I note that one thread in the child process seems to be stuck in `cuProfilerStop`, for some reason.

More information will be added here as I investigate further.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_8631: state: open
title: Gitdiff testing does not include cuda tests
body: https://github.com/numba/numba/blob/1f37a563e514f04da06c587ebe0491dffa58b19a/numba/testing/main.py#L413


user: sklam
labels: CUDA: CUDA related issue/PR
issue_8618: state: open
title: Enhance ufunc loop order specialisation with ndim information
body: As noted here: https://github.com/numba/numba/pull/7622#discussion_r798812017 it should be possible to use the `ndim` information present in the array types to ensure that 0d arrays do not influence the loop order specialisation.
user: stuartarchibald
issue_8616: state: open
title: Meta Issue: Support for Advanced/Fancy Indexing in Numba
body: This issue page tracks the current progress of NumPy's Advanced / Fancy Indexing support and links all related PRs and Issues.

Tasks/PRs related to base Advanced Indexing support:

- [ ] Switching to a subspace-based logic at type level for NumPy array `getitem/setitem` methods. - https://github.com/numba/numba/pull/8238
- [ ] Add support for multidimensional indices. - https://github.com/numba/numba/pull/8491
- [ ] Add support for multiple array indices.

Tasks/PRs that will enhance and/or extend the above added functionality:
- [ ] Extend the Advanced Indexing support for Boolean Array Indexing.
- [ ] Allowing list as indices.(Needs checking-in with NumPy's behaviour with list indices and it's plans to deprecate the list-indexing behaviour)
user: kc611
issue_8613: state: open
title: Raise exception fails with whitespace after function def
body: I have found that numba fails when trying to raise an exception, if the function it is contained in is defined with a whitespace after its name. Here is a test snippet that reproduces the error

```
import numpy as np
import numba as nb

@nb.njit
def test (a,b):

    if a/2 <= b <= a:
        return a*b

    else:
        raise ValueError('eta must be comprised between 0 and pi.')

print(test(5, 3.14))
```

When ran like that it produces the following error

```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
'NoneType' object has no attribute 'groups'

File "test.py", line 13:
def test (a,b):
    <source elided>
    else:
        raise ValueError('eta must be comprised between 0 and pi.')
        ^

During: lowering "<static> raise <class 'ValueError'>('eta must be comprised between 0 and pi.')" at /home/tomas/Documents/PEANUTS/test.py (13)
```

But it runs fine when I delete the space before the brackets, i.e. `def test(a,b)`. I believe it must be a regex failure when locating the function name for the backtrace, as I found a similar (closed) issue where the definition was commented.

For reference I am using python 3.10.6 and numba 0.56.3
user: tegonzalo
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8610: state: open
title: Optional UniTuple gives error depending on the signature
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

When using numba with an optional `UniTuple` I have encountered different behaviors depending on the signature being used.

If we specify that each element of the UniTuple is optional, then the code compiles and works as expected:
```python
from numba import njit

@njit('i8(UniTuple(Optional(i8), 2))')
def foo(a):
    if (a[0] is None) or (a[1] is None):
        return -1
    else:
        return a[0]

# test.
a = (1, 2)
print(foo(a)) # 1
a = (1, None)
print(foo(a)) # -1
a = (None, None)
print(foo(a)) # -1
```

While if we specify the `UniTuple` itself as an optional parameter, numba throws the following error when compiling the function.
```python
@njit('i8(Optional(UniTuple(i8, 2)))')
def foo(a):
    if a is None:
        return -1
    else:
        return a[0]
```

```shell
LoweringError: 'NoneType' object has no attribute 'args'
```

At first I thought this was related to the recent #8603, in which it was already commented that numba does not prune branches whether an element is `None` or not. 

However, what makes me doubt is that if we use as input argument a `ndarray` instead of a `UniTuple` then, the function gets compiled and works correctly:
```python
import numpy as np
from numba import njit

@njit('i8(optional(i8[:]))')
def foo2(a):
    if a is None:
        return -1
    else:
        return a[0]
    
# test.
a = np.array([1, 2]).astype(np.int64)
print(foo2(a)) # prints 1
a = None
print(foo2(a)) # prints -1
```

Any help is highly appreciated.

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

numba version: `0.56.3`

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: javierttgg
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8609: state: open
title: CUDA: register an extension globally
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request
It would be nice to have a possibility to register an extension globally, so that it is implicitly present for all `@cuda.jit` functions.
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
For example, instead of passing the `extensions=[array_view_arg_handler]`:

```python
class ArrayViewArgHandler:
    def prepare_args(self, ty, val, stream, retr):
        if isinstance(val, ak.Array):
            # return boxed ak.Array and its type

array_view_arg_handler = ArrayViewArgHandler()

@cuda.jit(extensions=[array_view_arg_handler])
def multiply(array, out, n):
    for i in range(len(array)):
        out[i] = n * array[i]
```


user: ianna
labels: CUDA: CUDA related issue/PR
issue_8603: state: open
title: Branch pruning not recognizing fact that a type is never None (original: Input type None is not recognized)
body: Hello,

I want to write a function that is basically summing two arrays. One of them may be missing and is replaced by `None`. They cannot be both `None`. As far as I understand numba, 3 different functions should be compiled in the 3 different cases, as `None` is a different type from array. I also expect the compiler to remove the dead parts of the code depending on the input types. However I get an error with this function:

```python
import numpy as np
import numba

@numba.njit
def f(a, b): 
    if a is not None:
        c = np.zeros((1,), dtype=a.dtype)
        c += a   
    else:    
        c = np.zeros((1,), dtype=b.dtype)
    if b is not None:
        c += b   
    return c 

x = np.ones((1,))
y = np.ones((1,))
print(f(x, y))
print(f(None, y))
print(f(x, None))
```

```
[2.]
[1.]
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Input In [49], in <cell line: 19>()
     17 print(f(x, y))
     18 print(f(None, y))
---> 19 print(f(x, None))

File ~/miniconda3/lib/python3.9/site-packages/numba/core/dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 468     error_rewrite(e, 'typing')
    469 except errors.UnsupportedError as e:
    470     # Something unsupported is present in the user code, add help info
    471     error_rewrite(e, 'unsupported_error')

File ~/miniconda3/lib/python3.9/site-packages/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'dtype' of type none

File "<ipython-input-49-2844d1d2e619>", line 10:
def f(a, b): 
    <source elided>
    else:    
        c = np.zeros((1,), dtype=b.dtype)
        ^

During: typing of get attribute at <ipython-input-49-2844d1d2e619> (10)

File "<ipython-input-49-2844d1d2e619>", line 10:
def f(a, b): 
    <source elided>
    else:    
        c = np.zeros((1,), dtype=b.dtype)
        ^
```

The error is always for `f(x, None)`, even if I remove `f(x, y)` or `f(None, y)`. There is no error when I remove `@njit`.

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
numpy version `1.21.5`
numba version `0.55.1`

user: ogauthe
issue_8596: state: open
title: Classes with `__enter__` and `__exit__` methods, and `jitclass` decorator can't be used as context managers.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

Running:
```
import numba
from numba.experimental import jitclass


@jitclass
class Ctx:
    a: int

    def __init__(self):
        self.a = 1

    def __enter__(self):
        return self

    def __exit__(self, a, b, c):
        pass


print(numba.__version__)
print(f"__enter__ in Ctx: {'__enter__' in dir(Ctx)}")
print(f"__enter__ in Ctx(): {'__enter__' in dir(Ctx())}")
with Ctx() as something:
    pass
```

Outputs:

```
0.56.4
__enter__ in Ctx: True
__enter__ in Ctx(): False
Traceback (most recent call last):
  File "numba_context.py", line 22, in <module>
    with Ctx() as something:
AttributeError: __enter__
```

It looks like even though `__enter__` is defined in the class that's produced it's not defined on instances of it. 

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: mbirtwell
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8591: state: open
title: performance issue with F-order array
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
run once before the test to make sure it's compiled:

```python
@njit
def foo(a, b):
    return a * b

a = np.random.randn(8192, 2592)
b = np.copy(a)
```
```python
%%timeit -n 10
_ = foo(a, b)
# 83.7 ms ± 1.67 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
```
```python
%%timeit -n 10
_ = foo.py_func(a, b)
# 29.6 ms ± 558 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
```
```python
af, bf = map(np.asfortranarray, (a, b))
```
```python
%%time
_ = foo(af, bf)
# CPU times: user 1.75 s, sys: 54.6 ms, total: 1.8 s
# Wall time: 1.74 s
```
```python
%%timeit -n 10
_ = foo.py_func(af, bf)
# 30.8 ms ± 420 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

```

We can observe a significant slow down with F-order array compared to pure numpy codes. BTW, even original C-order version is slower too.



user: auderson
labels: performance - run time: Performance issue occurring at run time.
issue_8586: state: open
title: np.kron behaves differently when compiled with numba
body: np.kron of an int array with a float array will return an int array when compiled with numba, but a float when run in normal numpy:

```
def kron_result(size=3):
    a = np.sqrt(np.diag(np.arange(size), k=1))
    one = np.array([[1]])
    kron = np.kron(one, a)
    return kron
```

returns 
```
array([[0.        , 0.        , 0.        , 0.        ],
       [0.        , 0.        , 1.        , 0.        ],
       [0.        , 0.        , 0.        , 1.41421356],
       [0.        , 0.        , 0.        , 0.        ]])
```
in normal numpy, but 
```
array([[0, 0, 0, 0],
       [0, 0, 1, 0],
       [0, 0, 0, 1],
       [0, 0, 0, 0]])
```
when compiled with njit


I am working on a mac M1 processor
numpy: 1.23.4
numba: 0.56.3
scipy: 1.9.3

Conda list:

```
anyio                     3.6.2              pyhd8ed1ab_0    conda-forge
appnope                   0.1.3              pyhd8ed1ab_0    conda-forge
argon2-cffi               21.3.0             pyhd8ed1ab_0    conda-forge
argon2-cffi-bindings      21.2.0          py310h90acd4f_3    conda-forge
asttokens                 2.1.0              pyhd8ed1ab_0    conda-forge
attrs                     22.1.0             pyh71513ae_1    conda-forge
backcall                  0.2.0              pyh9f0ad1d_0    conda-forge
backports                 1.0                        py_2    conda-forge
backports.functools_lru_cache 1.6.4              pyhd8ed1ab_0    conda-forge
beautifulsoup4            4.11.1             pyha770c72_0    conda-forge
bleach                    5.0.1              pyhd8ed1ab_0    conda-forge
brotli                    1.0.9                hb7f2c08_8    conda-forge
brotli-bin                1.0.9                hb7f2c08_8    conda-forge
bzip2                     1.0.8                h0d85af4_4    conda-forge
ca-certificates           2022.9.24            h033912b_0    conda-forge
certifi                   2022.9.24          pyhd8ed1ab_0    conda-forge
cffi                      1.15.1          py310ha78151a_2    conda-forge
contourpy                 1.0.6           py310ha23aa8a_0    conda-forge
cycler                    0.11.0             pyhd8ed1ab_0    conda-forge
debugpy                   1.6.3           py310h7a76584_1    conda-forge
decorator                 5.1.1              pyhd8ed1ab_0    conda-forge
defusedxml                0.7.1              pyhd8ed1ab_0    conda-forge
entrypoints               0.4                pyhd8ed1ab_0    conda-forge
executing                 1.2.0              pyhd8ed1ab_0    conda-forge
flit-core                 3.8.0              pyhd8ed1ab_0    conda-forge
fonttools                 4.38.0          py310h90acd4f_1    conda-forge
freetype                  2.12.1               h3f81eb7_0    conda-forge
gettext                   0.21.1               h8a4c099_0    conda-forge
glib                      2.74.1               hbc0c0cd_1    conda-forge
glib-tools                2.74.1               hbc0c0cd_1    conda-forge
gst-plugins-base          1.21.1               h37e1711_1    conda-forge
gstreamer                 1.21.1               h1d18e73_1    conda-forge
icu                       70.1                 h96cf925_0    conda-forge
idna                      3.4                pyhd8ed1ab_0    conda-forge
importlib-metadata        5.0.0              pyha770c72_1    conda-forge
importlib_resources       5.10.0             pyhd8ed1ab_0    conda-forge
ipykernel                 6.17.0             pyh736e0ef_0    conda-forge
ipython                   8.6.0              pyhd1c38e8_1    conda-forge
ipython_genutils          0.2.0                      py_1    conda-forge
ipywidgets                8.0.2              pyhd8ed1ab_1    conda-forge
jedi                      0.18.1             pyhd8ed1ab_2    conda-forge
jinja2                    3.1.2              pyhd8ed1ab_1    conda-forge
jpeg                      9e                   hac89ed1_2    conda-forge
jsonschema                4.17.0             pyhd8ed1ab_0    conda-forge
jupyter                   1.0.0           py310h2ec42d9_7    conda-forge
jupyter_client            7.4.4              pyhd8ed1ab_0    conda-forge
jupyter_console           6.4.4              pyhd8ed1ab_0    conda-forge
jupyter_core              4.11.2          py310h2ec42d9_0    conda-forge
jupyter_server            1.23.0             pyhd8ed1ab_0    conda-forge
jupyterlab_pygments       0.2.2              pyhd8ed1ab_0    conda-forge
jupyterlab_widgets        3.0.3              pyhd8ed1ab_0    conda-forge
kiwisolver                1.4.4           py310ha23aa8a_1    conda-forge
krb5                      1.19.3               hb49756b_0    conda-forge
lcms2                     2.14                 h90f4b2a_0    conda-forge
lerc                      4.0.0                hb486fe8_0    conda-forge
libblas                   3.9.0           16_osx64_openblas    conda-forge
libbrotlicommon           1.0.9                hb7f2c08_8    conda-forge
libbrotlidec              1.0.9                hb7f2c08_8    conda-forge
libbrotlienc              1.0.9                hb7f2c08_8    conda-forge
libcblas                  3.9.0           16_osx64_openblas    conda-forge
libclang                  15.0.4          default_h20dc2f0_0    conda-forge
libclang13                15.0.4          default_hc4b5f92_0    conda-forge
libcxx                    14.0.6               hccf4f1f_0    conda-forge
libdeflate                1.14                 hb7f2c08_0    conda-forge
libedit                   3.1.20191231         h0678c8f_2    conda-forge
libffi                    3.4.2                h0d85af4_5    conda-forge
libgfortran               5.0.0           9_5_0_h97931a8_26    conda-forge
libgfortran5              11.3.0              h082f757_26    conda-forge
libglib                   2.74.1               h4c723e1_1    conda-forge
libiconv                  1.17                 hac89ed1_0    conda-forge
liblapack                 3.9.0           16_osx64_openblas    conda-forge
libllvm11                 11.1.0               h8fb7429_5    conda-forge
libllvm15                 15.0.4               h7001e86_0    conda-forge
libogg                    1.3.4                h35c211d_1    conda-forge
libopenblas               0.3.21          openmp_h429af6e_3    conda-forge
libopus                   1.3.1                hc929b4f_1    conda-forge
libpng                    1.6.38               ha978bb4_0    conda-forge
libpq                     14.5                 h50fae06_1    conda-forge
libsodium                 1.0.18               hbcb3906_1    conda-forge
libsqlite                 3.39.4               ha978bb4_0    conda-forge
libtiff                   4.4.0                hdb44e8a_4    conda-forge
libvorbis                 1.3.7                h046ec9c_0    conda-forge
libwebp-base              1.2.4                h775f41a_0    conda-forge
libxcb                    1.13              h0d85af4_1004    conda-forge
libxml2                   2.10.3               hb9e07b5_0    conda-forge
libzlib                   1.2.13               hfd90126_4    conda-forge
llvm-openmp               14.0.4               ha654fa7_0    conda-forge
llvmlite                  0.39.1          py310h2bfb868_1    conda-forge
markupsafe                2.1.1           py310h90acd4f_2    conda-forge
matplotlib                3.6.2           py310h2ec42d9_0    conda-forge
matplotlib-base           3.6.2           py310he725631_0    conda-forge
matplotlib-inline         0.1.6              pyhd8ed1ab_0    conda-forge
mistune                   2.0.4              pyhd8ed1ab_0    conda-forge
munkres                   1.1.4              pyh9f0ad1d_0    conda-forge
mysql-common              8.0.31               h7ebae80_0    conda-forge
mysql-libs                8.0.31               hc37e033_0    conda-forge
nbclassic                 0.4.8              pyhd8ed1ab_0    conda-forge
nbclient                  0.7.0              pyhd8ed1ab_0    conda-forge
nbconvert                 7.2.3              pyhd8ed1ab_0    conda-forge
nbconvert-core            7.2.3              pyhd8ed1ab_0    conda-forge
nbconvert-pandoc          7.2.3              pyhd8ed1ab_0    conda-forge
nbformat                  5.7.0              pyhd8ed1ab_0    conda-forge
ncurses                   6.3                  h96cf925_1    conda-forge
nest-asyncio              1.5.6              pyhd8ed1ab_0    conda-forge
networkx                  2.8.8              pyhd8ed1ab_0    conda-forge
notebook                  6.5.2              pyha770c72_1    conda-forge
notebook-shim             0.2.2              pyhd8ed1ab_0    conda-forge
nspr                      4.32                 hcd9eead_1    conda-forge
nss                       3.78                 ha8197d3_0    conda-forge
numba                     0.56.3          py310h62db5c2_0    conda-forge
numpy                     1.23.4          py310h1b7c290_1    conda-forge
openjpeg                  2.5.0                h5d0d7b0_1    conda-forge
openssl                   1.1.1s               hfd90126_0    conda-forge
packaging                 21.3               pyhd8ed1ab_0    conda-forge
pandoc                    2.19.2               h694c41f_1    conda-forge
pandocfilters             1.5.0              pyhd8ed1ab_0    conda-forge
parso                     0.8.3              pyhd8ed1ab_0    conda-forge
pcre2                     10.40                h1c4e4bc_0    conda-forge
pexpect                   4.8.0              pyh1a96a4e_2    conda-forge
pickleshare               0.7.5                   py_1003    conda-forge
pillow                    9.2.0           py310hffcf78b_3    conda-forge
pip                       22.3.1             pyhd8ed1ab_0    conda-forge
pkgutil-resolve-name      1.3.10             pyhd8ed1ab_0    conda-forge
ply                       3.11                       py_1    conda-forge
prometheus_client         0.15.0             pyhd8ed1ab_0    conda-forge
prompt-toolkit            3.0.32             pyha770c72_0    conda-forge
prompt_toolkit            3.0.32               hd8ed1ab_0    conda-forge
psutil                    5.9.4           py310h90acd4f_0    conda-forge
pthread-stubs             0.4               hc929b4f_1001    conda-forge
ptyprocess                0.7.0              pyhd3deb0d_0    conda-forge
pure_eval                 0.2.2              pyhd8ed1ab_0    conda-forge
pycparser                 2.21               pyhd8ed1ab_0    conda-forge
pygments                  2.13.0             pyhd8ed1ab_0    conda-forge
pyparsing                 3.0.9              pyhd8ed1ab_0    conda-forge
pyqt                      5.15.7          py310hdd03f62_2    conda-forge
pyqt5-sip                 12.11.0         py310h415000c_2    conda-forge
pyrsistent                0.19.2          py310h90acd4f_0    conda-forge
python                    3.10.6          ha7b0be1_0_cpython    conda-forge
python-dateutil           2.8.2              pyhd8ed1ab_0    conda-forge
python-fastjsonschema     2.16.2             pyhd8ed1ab_0    conda-forge
python_abi                3.10                    2_cp310    conda-forge
pyzmq                     24.0.1          py310hf615a82_1    conda-forge
qt-main                   5.15.6               he0d2461_1    conda-forge
qtconsole                 5.4.0              pyhd8ed1ab_0    conda-forge
qtconsole-base            5.4.0              pyha770c72_0    conda-forge
qtpy                      2.3.0              pyhd8ed1ab_0    conda-forge
readline                  8.1.2                h3899abd_0    conda-forge
scipy                     1.9.3           py310h240c617_1    conda-forge
send2trash                1.8.0              pyhd8ed1ab_0    conda-forge
setuptools                65.5.1             pyhd8ed1ab_0    conda-forge
sip                       6.7.4           py310h7a76584_0    conda-forge
six                       1.16.0             pyh6c4a22f_0    conda-forge
sniffio                   1.3.0              pyhd8ed1ab_0    conda-forge
soupsieve                 2.3.2.post1        pyhd8ed1ab_0    conda-forge
sqlite                    3.39.4               h9ae0607_0    conda-forge
stack_data                0.6.0              pyhd8ed1ab_0    conda-forge
terminado                 0.17.0             pyhd1c38e8_0    conda-forge
tinycss2                  1.2.1              pyhd8ed1ab_0    conda-forge
tk                        8.6.12               h5dbffcc_0    conda-forge
toml                      0.10.2             pyhd8ed1ab_0    conda-forge
tornado                   6.2             py310h90acd4f_1    conda-forge
traitlets                 5.5.0              pyhd8ed1ab_0    conda-forge
typing_extensions         4.4.0              pyha770c72_0    conda-forge
tzdata                    2022f                h191b570_0    conda-forge
unicodedata2              15.0.0          py310h90acd4f_0    conda-forge
wcwidth                   0.2.5              pyh9f0ad1d_2    conda-forge
webencodings              0.5.1                      py_1    conda-forge
websocket-client          1.4.2              pyhd8ed1ab_0    conda-forge
wheel                     0.38.3             pyhd8ed1ab_0    conda-forge
widgetsnbextension        4.0.3              pyhd8ed1ab_0    conda-forge
xorg-libxau               1.0.9                h35c211d_0    conda-forge
xorg-libxdmcp             1.1.3                h35c211d_0    conda-forge
xz                        5.2.6                h775f41a_0    conda-forge
zeromq                    4.3.4                he49afe7_1    conda-forge
zipp                      3.10.0             pyhd8ed1ab_0    conda-forge
zstd                      1.5.2                hfa58983_4    conda-forge
```
user: SnoodMcGuinness
labels: bug - regression: A regression against a previous version of Numba
issue_8578: state: open
title: Segfault when calling nested parallel function with caching
body: Hi everyone,

I've run into a segfault when calling nested jit functions, specifically if the inner function has parallel=True, and the outer does not. The fault occurs only when caching is enabled for the outer function, and only when running from the cache (not on the first call). 

Here is a minimal example which produces this behaviour (when calling `outer_fn()`):
```python
import numpy as np
import numba


# @numba.njit('f4[:](i8)', parallel=True)  # with specified signature it works
@numba.njit(parallel=True)  # without specified signature it segfaults
def inner_fn(n):
    return np.zeros(n, dtype=np.float32)


@numba.njit(parallel=False, cache=True)
def outer_fn():
    inner_fn(10)
```

The fault occurs only if the inner function has some parallelizable functionality - e.g. the `np.zeros(n)` used in the example produces the fault, but `np.empty(n)` does not.

Could anyone shed any light on why this is occurring?

I'm using
```
numba==0.56.3
numpy==1.23.4
llvmlite==0.39.1
```
in a clean virtualenv on Python 3.9.15 with Ubuntu 22.10.
I've attached the output of "numba -s" for additional context.

The example script produces the same fault on Centos 7 with Python 3.9.7 (same package versions).

Any help much appreciated!
Ben

Edit: add the example in-line.


[numba_diagnostic.txt](https://github.com/numba/numba/files/9929815/numba_diagnostic.txt)
[numba_segfault_minimal_example.py.txt](https://github.com/numba/numba/files/9929819/numba_segfault_minimal_example.py.txt)
user: bhbrunt
labels: caching: Issue involving caching
bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_8574: state: open
title: `np.fmod` doesn't work with negative inputs
body: The current implementation doesn't follow numpy's `fmod` implementation which states:

> The remainder has the same sign as the dividend x1

Ex:
```
>>> np.fmod(-4, 10)
-4
>>> numba.jit(lambda: np.fmod(-4, 10))()
2
```
user: benwilliamgraham
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8565: state: open
title: Autodiff support in Numba
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request
It would be great if Numba supported automatic differentiation. Maybe using  [Enzyme](https://github.com/EnzymeAD/Enzyme) would be the easiest way as it operates directly on the IR of LLVM. Another possible source of inspiration could be [Taichi](https://docs.taichi-lang.org/).

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: adam-urbanczyk
issue_8559: state: open
title: Add file and line number information in NRT Debug statements. 
body: Currently NRT Debugging mode outputs the memory addresses of pointers to the objects being `incref`-ed/`decref`-ed. 

https://github.com/numba/numba/blob/bdb238410946f5ef26c83629f36b5ec3cc6cf336/numba/core/runtime/nrtdynmod.py#L57-L58

A good idea for this feature would be to work out if we can somehow add file and line number information into these `incref`/`decref` calls in the NRT debug mode (or some other debug mode). This way we can get a "trace" of every time one was called and where it originated from the Numba source. 

cc @stuartarchibald 
user: kc611
issue_8551: state: open
title: Support for np.linalg.svd(X, compute_uv=False)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Numba does not currently support the compute_uv=False flag for np.linalg.svd(), which significantly improves runtime in situations where only the singular values are needed. The selection of whether to compute U and V shouldn't really depend on the data/runtime so this should be an implementable feature. 

For some timing comparisons, I found that an njit and parallel numba implementation was only slightly faster than pure numpy on multi-dimensional SVDs (makes sense due to primarily LAPACK calls). But, setting compute_uv=False allows numpy to speed up by ~3x in my comparisons for matrices [270, 32, 4] and [100, 270, 32, 4] dtype=complex128. 


user: Ryandry1st
issue_8546: state: open
title: Return the type(obj) in `numba.typeof` when `DISABLE_JIT` is enabled
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

I use the `numba.typeof` to infer the type of `jitclass`, when I want to debug the code by setting the environment variable `NUMBA_DISABLE_JIT` to `1`, `numba.typeof` raises a `ValueError`, for example:
```python
>>> import os
>>> os.environ['NUMBA_DISABLE_JIT'] = '1'
>>> import numba
>>> @numba.experimental.jitclass
>>> class MyClass:
>>>     def __init__(self):
>>>         pass
>>> MyClassType = numba.typeof(MyClass())
Traceback (most recent call last):
  File "<pyshell#10>", line 1, in <module>
    MyClassType = numba.typeof(MyClass())
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\core\typing\typeof.py", line 42, in typeof
    raise ValueError(msg)
ValueError: [1mCannot determine Numba type of <class '__main__.MyClass'>[0m
```

Is it possible to return `type(obj)` in `numba.typeof` when `DISABLE_JIT` is enabled, just like something in the `numba.typed.List.empty_list`:
https://github.com/numba/numba/blob/598aadf637cd5b7a168713e39ee6b4a1c9751806/numba/typed/typedlist.py#L213-L227

## Workaround

Currently, I am using the following code as a workaround:

```python
MyClassType = MyClass if numba.config.DISABLE_JIT else numba.typeof(MyClass())
```

user: haiiliin
issue_8543: state: open
title: Rearanging the order of axes in cuda jitted code
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Inside cuda jitted code, the functions np.transpose and np.swapaxes don't work. Yet, the attribute ndarray.T does work and correctly reverses the order of all axes, so it seems that it should not be too hard to also support np.transpose and np.swapaxes.

The current situation can be tested with this snippet:
```
import numpy as np
from numba import cuda

@cuda.jit
def test_kernel(vol):
    vol2 = np.transpose(vol, (2, 1, 0))
    print(vol2[0, 0, 1])

vol = np.zeros((3, 4, 5))
vol[1, 0, 0] = 2
test_kernel[1, 1](vol)
```
It produces the following error:
```
No implementation of function Function(<function transpose at 0x7f078a2a51b0>) found for signature:

 >>> transpose(array(float64, 3d, C), Tuple(Literal[int](2), Literal[int](1), Literal[int](0)))

There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'numpy_transpose': File: numba/np/arrayobj.py: Line 1743.
    With argument(s): '(array(float64, 3d, C), UniTuple(int64 x 3))':
   Rejected as the implementation raised a specific error:
     NumbaTypeError: Failed in nopython mode pipeline (step: nopython frontend)
   Only accept returning of array passed into the function as argument
```
Indeed, I expect this function to return an ndarray (`vol2`) which was not passed as an argument to the function. However, I did pass `vol` and they should have the same data. Therefore, this error seems to be a bit too strict.

In the mean while, if anyone has a workaround to swap axes 0 and 1 of a 3D array, please let me know!
user: RendersJens
labels: CUDA: CUDA related issue/PR
issue_8540: state: open
title: Consider adding URL to Issue 6482 in _guard_py_ver message
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

Hi. :wave: Thanks for `numba`. Recently @esc very kindly explained to me (https://github.com/poliastro/poliastro/pull/1590#issuecomment-1290476186) why if the `_guard_py_ver` and `RuntimeError` message added in PR #6487

https://github.com/numba/numba/blob/9d034e91f881f8ff1f2a9051a757421328f02625/setup.py#L22-L47

are encountered this is not a build failure/bug, but intentional guards to avoid backsolving that would also fail. I now understand this and appreciate that this is a very good and thoughtful approach. This should have been clear to me had I taken the time to read and think about what

```
RuntimeError: Cannot install on Python version 3.11.0; only versions >=3.7,<3.11 are supported.
```

really meant and how that was different from encountering an upper cap on `python_requires`. However, I don't seem to be the only person who doesn't immediately understand the benefit of this `RuntimeError` and the information it is conveying. Some other examples of people making my mistake or the `numba` team needing to explain this:

* I think @zingale was also [confused by the result for Python 3.11](https://twitter.com/Michael_Zingale/status/1584903570582896640?s=20&t=HYvalzJyeQSdSLsp169MbA)
* https://github.com/numba/llvmlite/pull/869#issuecomment-1256385878
* https://github.com/numba/numba/issues/8304
* https://twitter.com/numba_jit/status/1584883236119130113?s=20&t=HYvalzJyeQSdSLsp169MbA

Something that might help mitigate this is a slightly more informative `RuntimeError` message. If there was a URL to a relevant Issue (e.g. Issue #6482) along with the existing `RuntimeError` I think people would note that this is a different error than just an install failure and that this is very intentional.

Would the `numba` team be open to something like

```diff
--- a/setup.py
+++ b/setup.py
@@ -43,7 +43,8 @@ def _guard_py_ver():
 
     if not min_py <= cur_py < max_py:
         msg = ('Cannot install on Python version {}; only versions >={},<{} '
-               'are supported.')
+               'are supported.\n' +
+               'Please see https://github.com/numba/numba/issues/6482 for why.')
         raise RuntimeError(msg.format(cur_py, min_py, max_py))
```

?

I can also appreciate that there might be reasons why adding a URL isn't desirable.
user: matthewfeickert
issue_8538: state: open
title: Update ufunc loop signature resolution to use NumPy #22422
body: It is proposed that NumPy 1.24 will include a new experimental API to help with resolving ufunc loop signatures: https://github.com/numpy/numpy/pull/22422 . This issue is to track integration efforts made in Numba.

1. Build NumPy from source/obtain a nightly build that is built with https://github.com/numpy/numpy/pull/22422 present.
2. Update this code: https://github.com/numba/numba/blob/9d034e91f881f8ff1f2a9051a757421328f02625/numba/core/typing/npydecl.py#L98 to make use of the new API from the typing side.
3. Possibly update code to handle ufunc inner loops where there's a reliance on NumPy for that loop (do any of these exist any more?!).
user: stuartarchibald
issue_8533: state: open
title: Implementation of `__repr__` method within `jitclass`
body: Hello,

Numba 0.56.0 has introduced support for many `builtin`s for the `numba.experimental.jitclass` type.

Would it be possible to add `__repr__`, too?

I think it might be useful to increase the level of interaction with Jupyter Notebook.
user: pietrodantuono
issue_8528: state: open
title: CUDA target overloads not handling kwargs
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
import numpy as np
from numba.cuda import jit
from numba.extending import overload


def bar():
    pass


@overload(bar, target='cuda')
def ol_bar(x, kw1=None):

    def impl(x, kw1=None):
        return 123
    return impl


@jit
def foo(arr):
    arr[0] = bar(2)

tmp = np.zeros((1,))
foo[1, 1](tmp)
print(tmp)
```
Fails typing with `TypeError("Signature mismatch: 1 argument types given, but function takes 2 arguments")`.

user: stuartarchibald
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
bug - typing: Bugs: occuring at typing time
issue_8521: state: open
title: Stub handling for type check purposes
body: ## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
I'm following up on [this comment](https://github.com/microsoft/pylance-release/issues/3490#issuecomment-1282922365) from a member of the Pylance team. As you can see from the screenshot below, Pylance doesn't recognize the Numba List type because it it isn't re-exported from `numba.typed`. It would be nice if the Numba types were automatically recognized by a type checker, so I'm asking if the stubs could be written in a way to make this possible.

![image](https://user-images.githubusercontent.com/52188949/196539780-5ef9b68b-ffea-4069-95d1-0b04fc2cc5ef.png)

user: abianco88
issue_8519: state: open
title: Meta Issue: NumPy Random Generator Support
body: This issue page tracks the current progress of NumPy's random number generation support (the new `Generator` API) and links all related PRs and Issues. (This only links 'missing' features and not bug reports). 

Functionalities for core `Generator` support:
- [x] Core `Generator` boxing-unboxing.
- [ ] Constructors for `Generator` and `BitGenerator`
- [ ] Thread safety for `Generator` states.

Tasks within Numba for better support / efficiency of existing features:
- [ ] Re-iterate the Numba documentation for `Generator`s to explicitly mention what is supported and what isn't. 
- [x] Change the output shape iterator to a flattened iterator for every distribution. - https://github.com/numba/numba/pull/8619
- [ ] Fix for NumPy vs Numba output discrepancy due to `fmadd` instructions being generated in certain cases. - https://github.com/numpy/numpy/issues/22993
- [ ] Support for array arguments - https://github.com/numba/numba/issues/8770 

Generator methods: (Methods that can be implemented right away are marked feasible)
- [x] numpy.random.Generator.integers
- [x] numpy.random.Generator.random
- [ ] numpy.random.Generator.choice (Depends on support for Advanced Indexing)
- [ ] numpy.random.Generator.bytes (Feasible, but no definitive return type in Numba)
- [x] numpy.random.Generator.shuffle
- [x] numpy.random.Generator.permutation
- [ ] numpy.random.Generator.permuted (Feasible)
- [x] numpy.random.Generator.beta
- [ ] numpy.random.Generator.binomial - https://github.com/numba/numba/pull/8371
- [x] numpy.random.Generator.chisquare
- [ ] numpy.random.Generator.dirichlet (Feasible)
- [x] numpy.random.Generator.exponential
- [x] numpy.random.Generator.f
- [x] numpy.random.Generator.gamma
- [x] numpy.random.Generator.geometric
- [ ] numpy.random.Generator.gumbel - https://github.com/numba/numba/pull/8232
- [ ] numpy.random.Generator.hypergeometric (Feasible, but complex enough to require it's own PR)
- [x] numpy.random.Generator.laplace
- [x] numpy.random.Generator.logistic
- [x] numpy.random.Generator.lognormal
- [x] numpy.random.Generator.logseries
- [ ] numpy.random.Generator.multinomial (Depends on #8371)
- [ ] numpy.random.Generator.multivariate_hypergeometric (Feasible, but complex enough to require it's own PR)
- [ ] numpy.random.Generator.multivariate_normal (Feasible, but complex enough to require it's own PR)
- [x] numpy.random.Generator.negative_binomial
- [x] numpy.random.Generator.noncentral_chisquare
- [x] numpy.random.Generator.noncentral_f
- [x] numpy.random.Generator.normal
- [x] numpy.random.Generator.pareto
- [x] numpy.random.Generator.poisson
- [x] numpy.random.Generator.power
- [x] numpy.random.Generator.rayleigh
- [x] numpy.random.Generator.standard_cauchy
- [x] numpy.random.Generator.standard_exponential
- [x] numpy.random.Generator.standard_gamma
- [x] numpy.random.Generator.standard_normal
- [x] numpy.random.Generator.standard_t
- [x] numpy.random.Generator.triangular
- [x] numpy.random.Generator.uniform
- [ ] numpy.random.Generator.vonmises - https://github.com/numba/numba/pull/8232
- [x] numpy.random.Generator.wald
- [x] numpy.random.Generator.weibull
- [x] numpy.random.Generator.zipf




user: kc611
issue_8514: state: open
title: njit with np. histogram vs np.histogram, but get different output on an edge case
body: I have wrote my questions here. Let me repost here again
https://stackoverflow.com/questions/74077065/numba-histogram-vs-numpy-histogram

`@njit
def hist1d(x):
   return np.histogram(x)[0]


x = np.array([1/2,1/2,1/2,1/2])
print(hist1d(x),np.histogram(x)[0])`

output: array([0,0,0,0,0,0,0,0,0,0]),array([0,0,0,0,0,0,4,0,0,0])

The output of these functions are different. For the other case should be ok whenever the elements inside matrix are not the same. It seems that there are some bugs in numba on np.histogram.

Thanks~
user: wesley34
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8512: state: open
title: Support catching exceptions raised in njit code from within gdb
body: ## Feature request

In C++, exceptions can be thrown and gdb can catch this happening. Example:
```cxx
#include <exception>

void foo(){
    throw std::exception();
}

int main(void)
{
    foo();
    return 0;
}
```
Compile:
```bash
$ $CXX -g -O0 exception.cpp
```
Run:
```bash
$ ./a.out 
terminate called after throwing an instance of 'std::exception'
  what():  std::exception
Aborted
```
Run under gdb control (slightly edited output to remove superfluous information):
```bash
$ gdb -q -ex 'catch throw' -ex 'r' -ex 'bt' ./a.out
Reading symbols from ./a.out...
Catchpoint 1 (throw)
Starting program: a.out 

Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x55555556aca0, 
    tinfo=0x555555557dd0 <typeinfo for std::exception@@GLIBCXX_<VERSION>>, dest=0x7ffff7f304b2 <std::exception::~exception()>)
    at <path>/eh_throw.cc
#0  __cxxabiv1::__cxa_throw (obj=0x55555556aca0, tinfo=0x555555557dd0 <typeinfo for std::exception@@GLIBCXX_<VERSION>>, 
    dest=0x7ffff7f304b2 <std::exception::~exception()>)
    at at <path>/eh_throw.cc
#1  0x00005555555551b0 in foo () at exception.cpp:4
#2  0x00005555555551b9 in main () at exception.cpp:9
```

It might be possible and useful to augment Numba's exception generation mechanism to be able to do something similar, this to help with situations such as those described in #8510 and #8511 where an exception is raised but there's insufficient information in the traceback to work out where the exception came from. Further, if an exception has been raised, it might be useful to be able to intercept this and inspect the values/conditions present in the executing code that are associated with reaching the `raise`.
user: stuartarchibald
issue_8511: state: open
title: Exceptions raised in `@lower_builtin` implementations do not have an associated location.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

From @luk-f-a on gitter. This:
```python
from numba import njit
import numpy as np

@njit
def bar():
    return 1 / 0

@njit
def foo():
    return bar()

foo()
```
produces:
```
$ python divbyzero_issue.py 
Traceback (most recent call last):
  File "divbyzero_issue.py", line 12, in <module>
    foo()
ZeroDivisionError: division by zero
```
i.e. the zero division error is reported, but there's no information present about where it occurred. I think that even were this to be fixed (details on how below), there would still be an issue in that Numba would at best report the internal function/file/line at which the exception was raised due to the incomplete frame information in the traceback (xref: #8510 which tracks this). Essentially, fixing the lack of location in the call site of these exceptions does not solve the incomplete traceback problem.

The general "fix" for ensuring a location is present when raising an error in `@lower_builtin` is to convert the implementation to an `@overload` which handles this correctly. I don't think it's possible in the current `@lower_builtin` framework to accurately obtain the calling frame (`context.typing_context.callstack` seems to be inaccurate when directly lowering).
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8510: state: open
title: Tracebacks in compiled code don't include all frames
body: This is a feature request to fix this:
```python
from numba import njit
import numpy as np

@njit
def baz():
    raise ValueError()

@njit
def bar():
    baz()

@njit
def foo():
    bar()

foo()
```
produces:
```
$ python exception_example.py 
Traceback (most recent call last):
  File "exception_example.py", line 16, in <module>
    foo()
  File "exception_example.py", line 6, in baz
    raise ValueError()
ValueError
```
whereas in the interpreter it produces:
```
$ NUMBA_DISABLE_JIT=1 python exception_example.py 
Traceback (most recent call last):
  File "exception_example.py", line 16, in <module>
    foo()
  File "exception_example.py", line 14, in foo
    bar()
  File "exception_example.py", line 10, in bar
    baz()
  File "exception_example.py", line 6, in baz
    raise ValueError()
ValueError
```
Essentially, Numba's traceback only captures the entry point and the point at which the exception occurred.
user: stuartarchibald
issue_8509: state: open
title: Deprecate `numba.pycc`
body: Capturing the outcome of the discussion on deprecating `numba.pycc` from the public Numba meeting on 2022-10-04 (meeting notes are in the wiki, but copying the relevant bits here):

>    PYCC has multiple longstanding issues and upcoming problems with setuptools; it also has very limited feature
>    Target to deprecate in 0.57 release
>    No one in the meeting objected

Essentially, `numba.pycc` (and everything associated with it) will be deprecated in version 0.57. Further subsequent searches for active use of `numba.pycc` did not have a large number of hits. 

If this will impact a project you maintain or use please do comment on this issue. Many thanks!
user: stuartarchibald
issue_8507: state: open
title: CUDA: Warp-aggregated atomics example no longer works
body: My example of warp-aggregated atomics (from this gist: https://gist.github.com/gmarkall/79226342a330a06ce81fe1096318909c):

```python
from numba import cuda
import numpy as np


# From:
#
#     https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/

# __device__ int atomicAggInc(int *ctr) {
#   unsigned int active = __activemask();
#   int leader = __ffs(active) - 1;
#   int change = __popc(active);
#   unsigned int rank = __popc(active & __lanemask_lt());
#   int warp_res;
#   if(rank == 0)
#     warp_res = atomicAdd(ctr, change);
#   warp_res = __shfl_sync(active, warp_res, leader);
#   return warp_res + rank;
# }


@cuda.jit(device=True)
def atomicAggInc(ctr):
    active = cuda.activemask()
    leader = cuda.ffs(active) - 1
    change = cuda.popc(active)
    rank = cuda.popc(active & cuda.lanemask_lt())

    if rank == 0:
        warp_res = cuda.atomic.add(ctr, 0, change)
    else:
        warp_res = cuda.shfl_sync(active, warp_res, leader)

    return warp_res + rank


# There is a bug in the example C code, nres should be passed in:
#
# __global__ void filter_k(int *dst, const int *src, int n) {
#   int i = threadIdx.x + blockIdx.x * blockDim.x;
#   if(i >= n)
#     return;
#   if(src[i] > 0)
#     dst[atomicAggInc(nres)] = src[i];
# }

@cuda.jit
def filter_k(dst, nres, src):
    i = cuda.grid(1)

    if i >= len(src):
        return

    if src[i] > 0:
        dst[atomicAggInc(nres)] = src[i]


# Parameters for the run
N = 2 ** 24
zero_factor = 0.25

print(f'Running with {N} elements, of which approximately {zero_factor * 100}%'
      ' are zero\n')

# Seed the RNG for repeatability
np.random.seed(1)


# Create input data
inputs = np.random.random(N)
zeros = np.zeros(N)
factors = np.random.random(N)
values = np.where(factors > zero_factor, inputs, zeros)

# Quick summary of the data
value_count = np.sum(values > 0)
print(f'There are {value_count} nonzeroes in:')
print(values)
print()

# Create outputs for kernel
nres = np.zeros(1, dtype=np.uint32)
result = np.zeros_like(values)

# Compute grid dimensions and launch kernel
n_threads = 128
n_blocks = N // n_threads
filter_k[n_blocks, n_threads](result, nres, values)

# Summarize the kernel output
cuda_n = nres[0]
print(f'The kernel found {cuda_n} elements, resulting in the array:')
print(result)
print()

#breakpoint()

# Some sanity checking:

# Did we filter the expected number of values?
np.testing.assert_equal(value_count, nres[0])

# Are the first cuda_n elements all nonzero?
np.testing.assert_equal(np.ones(value_count, dtype=np.bool), result[:cuda_n] > 0)

# Were elements after the cuda_nth element left as zero?
np.testing.assert_equal(np.zeros(N - value_count), result[cuda_n:])

print('Sanity checks passed!')
```

doesn't work anymore:

```
numba.core.errors.TypingError: Failed in cuda mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function setitem>) found for signature:
 
 >>> setitem(array(float64, 1d, C), float64, float64)
 
There are 16 candidate implementations:
  - Of which 14 did not match due to:
  Overload of function 'setitem': File: <numerous>: Line N/A.
    With argument(s): '(array(float64, 1d, C), float64, float64)':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'SetItemBuffer.generic': File: numba/core/typing/arraydecl.py: Line 176.
    With argument(s): '(array(float64, 1d, C), float64, float64)':
   Rejected as the implementation raised a specific error:
     NumbaTypeError: unsupported array index type float64 in [float64]
       Traceback (most recent call last):
         File "/home/gmarkall/numbadev/numba/numba/core/types/functions.py", line 308, in get_call_type
           sig = temp.apply(nolitargs, nolitkws)
         File "/home/gmarkall/numbadev/numba/numba/core/typing/templates.py", line 351, in apply
           sig = generic(args, kws)
         File "/home/gmarkall/numbadev/numba/numba/core/typing/arraydecl.py", line 184, in generic
           out = get_array_index_type(ary, idx)
         File "/home/gmarkall/numbadev/numba/numba/core/typing/arraydecl.py", line 72, in get_array_index_type
           raise NumbaTypeError("unsupported array index type %s in %s"
       numba.core.errors.NumbaTypeError: unsupported array index type float64 in [float64]
  raised from /home/gmarkall/numbadev/numba/numba/core/typing/arraydecl.py:72

During: typing of setitem at /home/gmarkall/numbadev/issues/6911/repro.py (55)

File "repro.py", line 55:
def filter_k(dst, nres, src):
    <source elided>
    if src[i] > 0:
        dst[atomicAggInc(nres)] = src[i]
        ^
```

When the support for the required functions was added in #6911, there was a comment about, and subsequent change to, the signedness of `activemask` and `lanemask_lt`. I wonder whether this change in signedness has resulted in proneness to cast to a `float64` when using them to compute indices.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_8500: state: open
title: Add string comparison and information methods from the numpy.char module.
body: This update adds support for all string comparison and information methods:

#### Comparison operations:
https://numpy.org/doc/stable/reference/routines.char.html#comparison

- `char.equal`
- `char.not_equal`
- `char.greater_equal`
- `char.less_equal`
- `char.greater`
- `char.less`
- `char.compare_chararrays`

#### Occurrence and Property information:
https://numpy.org/doc/stable/reference/routines.char.html#string-information

- `char.count`
- `char.endswith`
- `char.startswith`
- `char.find`
- `char.rfind`
- `char.index`
- `char.rindex`
- `char.str_len`
- `char.isalpha`
- `char.isalnum`
- `char.isspace`
- `char.isdecimal`
- `char.isdigit`
- `char.isnumeric`
- `char.istitle`
- `char.isupper`
- `char.islower`

Included is support for UTF-32 strings and ASCII bytes on contiguous arrays of 1-dimension and scalars, a light framework for future supported string array functions, tests, and updated documentation.
user: nmehran
issue_8497: state: open
title: List is considered as array
body: Hello,
I encountered a bug with a list of arrays. The problem disappears if either `a_list` or `b_list` is removed. It also disappears when the last line is commented.

```python
import numpy as np
import numba

@numba.njit
def f():
    a_list = []
    b_list = []
    for i in range(2):
        b_list.append(1)
        a_list.append(np.ones((1,), dtype=np.int8))

    b_ar = np.array(b_list, dtype=np.int64)
    return 1

f()
```

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'append' of type array(int64, 1d, C)

File "<ipython-input-1-f02131a2ac67>", line 10:
def f():
    <source elided>
        b_list.append(1)
        a_list.append(np.ones((1,), dtype=np.int8))
        ^

During: typing of get attribute at <ipython-input-1-f02131a2ac67> (10)

File "<ipython-input-1-f02131a2ac67>", line 10:
def f():
    <source elided>
        b_list.append(1)
        a_list.append(np.ones((1,), dtype=np.int8))
```

numba version `0.55.1`
numpy version `1.21.5`
<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: ogauthe
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8492: state: open
title: scalar ufuncs that have equivalents in the math module are not supported, but docs claim they are.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I think the docs are not correct on [what numpy functions are supported in cuda](https://numba.readthedocs.io/en/latest/cuda/cudapysupported.html#numpy-support)

For example
```
import numpy as np
from numba import cuda


@cuda.jit
def kernel(x):
    np.sin(x[0])


x = np.zeros(1)
kernel[1,1](x)
```
gives this error:

```
Use of unsupported NumPy function 'numpy.sin' or unsupported use of the function
```
I'm using numba 0.56.2
user: RendersJens
issue_8488: state: open
title: Add advanced performance "tricks" page/notes to the docs or as a notebook
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
Following on from discussion at the Numba public meetings (this week, and last week), there seems to be support for collecting Numba "tricks" and tips, particularly with regards to performance. This issue is opened so as to start collecting such "tricks" and to promote discussion about how best to present them.

CC @luk-f-a @brandonwillard 
user: stuartarchibald
labels: performance - run time: Performance issue occurring at run time.
issue_8485: state: open
title: Feature Request: Support math.fsum
body: The function `math.fsum(seq, /)` is not supported, this is a request to add support for it.
user: stuartarchibald
issue_8483: state: open
title: CUDA: Tuples of CAI exporters that aren't Numba device arrays are not recognized by typing
body: For example:

```python
from numba import cuda
import cupy as cp

@cuda.jit
def f(tup):
    i = cuda.grid(1)
    tup[0][i] = tup[1][i]

N = 32
x = cp.zeros(N)
y = cp.arange(N)

f[1, N]((x, y))
```

results in a typing error:

```
/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py:502: NumbaPerformanceWarning: Grid size 1 will likely result in GPU under-utilization due to low occupancy.
  warn(NumbaPerformanceWarning(msg))
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/cuda_enthusiast/tuple_cupy.py", line 15, in <module>
    f[1, N]((x, y))
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 505, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 639, in call
    kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 646, in _compile_for_args
    argtypes = [self.typeof_pyval(a) for a in args]
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 646, in <listcomp>
    argtypes = [self.typeof_pyval(a) for a in args]
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 653, in typeof_pyval
    return typeof(val, Purpose.argument)
  File "/home/gmarkall/numbadev/numba/numba/core/typing/typeof.py", line 42, in typeof
    raise ValueError(msg)
ValueError: Cannot determine Numba type of <class 'tuple'>
```

whereas if `x` and `y` were Numba device arrays, the typing succeeds.

This means it's effectively not possible to use tuples of arrays that aren't device arrays.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_8479: state: open
title: Support type change across inplace operators
body: ```
import numpy as np
from numba import jit

@jit(nopython=True)
def PowerN(m,n):

    ans = 1.0
    for i in range(n):
        ans *= m

    return ans


m22 = np.random.randint(10,size=(300,3000)) * 1.0
PowerN.py_func(m22,5)  can give right answer


PowerN(m22,5)


TypingError: No implementation of function Function(<built-in function imul>) found for signature:
 
imul(float64, array(float64, 2d, C))
 
There are 8 candidate implementations:
      - Of which 6 did not match due to:
      Overload of function 'imul': File: <numerous>: Line N/A.
        With argument(s): '(float64, array(float64, 2d, C))':
       No match.
      - Of which 2 did not match due to:
      Operator Overload in function 'imul': File: unknown: Line unknown.
        With argument(s): '(float64, array(float64, 2d, C))':
       No match for registered cases:
        * (int64, int64) -> int64
        * (int64, uint64) -> int64
        * (uint64, int64) -> int64
        * (uint64, uint64) -> uint64
        * (float32, float32) -> float32
        * (float64, float64) -> float64
        * (complex64, complex64) -> complex64
        * (complex128, complex128) -> complex128

During: typing of intrinsic-call at C:\Users\isaac\AppData\Local\Temp/ipykernel_20876/566630640.py (6)

```

user: AIQuantRobot
issue_8478: state: open
title: fmin and fmax incorrect output dtype
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

`np.fmin` and `np.fmax` no longer match numpy on non-float types.  Here is an example:
```python
In [1]: import numpy as np

In [2]: import numba

In [3]: numba.__version__
Out[3]: '0.56.2'

In [4]: np.__version__
Out[4]: '1.23.3'

In [5]: np.fmax(1, 2)
Out[5]: 2

In [6]: numba.njit(lambda x, y: np.fmax(x, y))(1, 2)
Out[6]: 2.0
```
Previous numba versions (such as 0.55.2) _did_ match numpy output dtypes for `fmin` and `fmax`.
user: eriknw
labels: bug - typing: Bugs: occuring at typing time
issue_8472: state: open
title: The `.fill` on a record array results in a `KeyError`
body: Reproducer:

```python
from numba import njit
import numpy as np
dtype = np.dtype([("a", float), ("b", float)])
arr = np.ones((2,), dtype)
@njit
def f(arr):
    arr[1].fill(0)
 f(arr)
```

See #8456
user: apmasell
labels: bug - ice: Bugs: internal compiler error
bug - failure to compile: Bugs: failed to compile valid code
issue_8471: state: open
title: Lack of support for `setitem` simultaneously across all fields of record arrays
body: Assigning to a record array should simultaneously fill all fields in a record array so that a record array can be initialized with `= 0`.

See #8456
user: apmasell
issue_8470: state: open
title: Deconstructor support in jitclass
body: It would be useful if jitclass supported the deconstructor `__del__` method. Supporting `__del__` would permit more seemless numba interfaces to C/C++/Fortran codes which allocate heap memory or use classes. Without `__del__` memory leaks are extremely hard to avoid.

Example:

```python
import numba as nb

@nb.experimental.jitclass()
class Test():
    def __init__(self):
        pass
    def __del__(self):
        print('__del__ is being called')
        
@nb.njit()
def tester():
    T = Test()

tester()
```

This little script should print `__del__ is being called`.
user: Nicholaswogan
issue_8465: state: open
title: Tasks for deprecating/removing "fallback" compilation pipelines from the default `@jit` behaviour.
body: This is a tracking issue for confirming the deprecation/removal cycle for "object mode fallback" under the `@jit` decorator. The current behaviour is that Numba's `@jit` decorator will attempt up to 3 pipelines, falling back to the next, when trying to compile a function:
1. `nopython` mode.
2. object mode with `nopython` mode lifted loops.
3. full object mode.

This behaviour is incredibly hard to debug and maintain, and can lead to really strange performance characteristics, hence it being deprecated approaching 3 years ago (https://github.com/numba/numba/pull/4513, patch 3090fe73). https://github.com/numba/numba/blob/809a9c85656966332d611b4b0ac59d6afd6813bd/numba/core/object_mode_passes.py#L154-L162

This change is important from a maintenance perspective as it greatly simplifies the compiler itself through the reduction of "state". It also makes it easier for technology such as with-lifting and loop-lifting to be updated with respect to the churn in the Python bytecodes/bytecode generation patterns that occur across Python versions.

Proposed tasks:

For Numba 0.57:

0. [x] Check with the community over impact of this change. It's anticipated the overwhelming majority of users are using `njit` or `jit(nopython=True)`. (was discussed at public Numba meeting).
1. [ ] Update/write deprecation documentation with workarounds for providing direct access to the three modes noted above, through the use of `@jit` kwargs.
2. [ ] Update the deprecation documentation with a specific time line for removal. 0.57 full deprecation and last release to support this behaviour. 0.58 full removal.
3. [ ] Make "fall back" to "object mode with `nopython` mode lifted loops." raise a `NumbaDeprecationWarning` with reference to workaround documentation/deprecation notes.
4. [ ] Make the "fall back" to "object mode" reference the workaround documentation/deprecation notes.
5. [ ] Update unit tests etc. with respect to the above, write new unit tests to ensure deprecation warnings occur appropriately.
6. [ ] Maybe deprecate the use of multiple pipelines in the compiler class `numba.core.compiler.CompilerBase` itself (needs discussion).


For Numba 0.58:

1. [ ] Remove the "fallback" pipeline behaviour.
2. [ ] Update unit tests with respect to the above.
3. [ ] Update documentation with respect to the above.


user: stuartarchibald
issue_8463: state: open
title: Add more LLVM build info to numba -s
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
Recently there have been a number of issues reported in relation to the way in which LLVM is built/linked into the Numba toolchain. It might be useful to add the following to the `numba -s` output to help quickly diagnose whether a reported issue is essentially a known LLVM packaging problem/provide information to help with spotting patterns in issues.

1. Is it possible to test if _all_ of the patches that Numba requires have been applied to LLVM? Examples:
    1. The ARM consecutive registers patch, which manifests as a segfault if it is not applied (impacts ARM linux and ARM/M1 OSX systems).
    2. GlobalValue name size limit patch, this leads to issues with duplicate names in IR if not applied (impacts all builds).
2. Is it possible to show whether LLVM was built with/without assertions?
3. Is it possible to show whether llvmlite is dynamically or statically linked against LLVM?


user: stuartarchibald
issue_8461: state: open
title: Call to exp with float32 values using numba does not produce the same result as using numpy
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I encountered the following issue: If I am using numba compiled functions with call to `numpy.exp` where argument is array of `float32` numbers, I get different result than if use the same function without numba. Example that reproduces issue:
```
import numba
import numpy as np


def func(input):
    return np.exp(input)


jitted_func = numba.njit(
    locals={
        "input": numba.types.float32[::1],
    },
    parallel=False,
    fastmath=False,
)(func)


if __name__ == '__main__':
    input = np.array([-1.2254496, 1.], dtype=np.float32)

    result1 = func(input)
    result2 = jitted_func(input)

    print("Non jitted: ", result1)
    print("Jitted: ", result2)
    print("Are equal: ", np.array_equal(result1, result2))
```
On my ubuntu machine this prints:
```
Non jitted:  [0.29362568 2.718282  ]
Jitted:  [0.29362568 2.7182817 ]
Are equal:  False
```
On my windows machine (same processor, ubuntu is VM, windows is host):
```
Non jitted:  [0.29362568 2.718282  ]
Jitted:  [0.29362565 2.7182817 ]
Are equal:  False
```
It seems than one problem is that Euler's number is not rounded the same way in numpy and numba, though I am not sure what can be causing different result on different OSes.

Issue seems to only manifest if input is float32. Changing array to float64 works as expected.




user: nejcskofic
labels: ISA: X86: Issue related to X86 ISA
bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8459: state: open
title: Support averaging across axis in np.average
body: `np.average` ignores `axis` argument and always returns a single value. 
It would be nice to support this functionality, or at least place a warning as it's done in `np.mean`

Here is an example: 
```
from numba import jit
import numpy as np

@jit(nopython=True)
def some_fun():
    return np.average(np.ones((10,10)), axis=0)

print(some_fun())
```


user: divannyteoretik
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8458: state: open
title: Testhound/cuda array reshape 7528
body: This PR adds the ability to perform array reshaping in CUDA kernels and addresses issue 7528:

Fixes #7528.

user: testhound
labels: CUDA: CUDA related issue/PR
4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_8457: state: open
title: Heap corruption detected when using prange
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.



Hello!  Thanks for maintaining numba.  I've encountered a bug that causes a fatal error that looks like

`Python(51147,0x118940600) malloc: Heap corruption detected, free list is damaged at 0x6000017ab5c0
*** Incorrect guard value: 32131208623549
Python(51147,0x118940600) malloc: *** set a breakpoint in malloc_error_break to debug`

As a minimal working example I have the following code.  It seems like the error is due to `prange` as it goes away if I remove `prange` or set `parallel=False` (defined in the `sum_annotations_no_prange` and `sum_annotations_serial` functions respectively below).  I assume it's some kind of race condition as (at least on my machine) it sometimes produces the correct result, sometimes produces the wrong result but runs, and sometimes crashes with an error like the one above.

Here is the code:

```
from numba import njit, prange
import numpy as np


@njit('float64[:, :](float64[:, :], int64[:], int64)',
      parallel=True, cache=False)
def sum_annotations(deltas, annotations, num_annotations):
    to_return = np.zeros((num_annotations, deltas.shape[1]))
    for a in range(num_annotations):
        summand = np.zeros(deltas.shape[1], dtype=np.float64)
        for i in prange(annotations.shape[0]):
            if annotations[i] == a:
                summand += deltas[i]
        to_return[a] += summand
    return to_return


@njit('float64[:, :](float64[:, :], int64[:], int64)',
      parallel=False, cache=False)
def sum_annotations_serial(deltas, annotations, num_annotations):
    to_return = np.zeros((num_annotations, deltas.shape[1]))
    for a in range(num_annotations):
        summand = np.zeros(deltas.shape[1], dtype=np.float64)
        for i in prange(annotations.shape[0]):
            if annotations[i] == a:
                summand += deltas[i]
        to_return[a] += summand
    return to_return


@njit('float64[:, :](float64[:, :], int64[:], int64)',
      parallel=True, cache=False)
def sum_annotations_no_prange(deltas, annotations, num_annotations):
    to_return = np.zeros((num_annotations, deltas.shape[1]))
    for a in range(num_annotations):
        summand = np.zeros(deltas.shape[1], dtype=np.float64)
        for i in range(annotations.shape[0]):
            if annotations[i] == a:
                summand += deltas[i]
        to_return[a] += summand
    return to_return


deltas = np.random.random((100, 5))
annotations = np.copy(np.array([0]*50 + [1]*50))
truth = np.zeros((2, 5))
truth[0] = deltas[0:50].sum(axis=0)
truth[1] = deltas[50:100].sum(axis=0)

# serial version
serial_result = sum_annotations_serial(deltas, annotations, 2)
print('Serial Result is correct?', np.allclose(serial_result, truth))

# no prange version
no_prange_result = sum_annotations_no_prange(deltas, annotations, 2)
print('No prange Result is correct?', np.allclose(no_prange_result, truth))


# parallel version
# on my machine, with high probability  one of these will crash ungracefully
for i in range(10):
    parallel_result = sum_annotations(deltas, annotations, 2)
    print('Did not crash on iteration', i)
    print('Was the result correct?', np.allclose(parallel_result, truth))
```

and here is an example output (note that in this case it produced the correct result using prange the first time it was called, but fatally crashed the second time)

```
Serial Result is correct? True
No prange Result is correct? True
Did not crash on iteration 0
Was the result correct? True
Python(51301,0x1118fa600) malloc: Heap corruption detected, free list is damaged at 0x600002d3cdc0
*** Incorrect guard value: 94562201095614
Python(51301,0x1118fa600) malloc: *** set a breakpoint in malloc_error_break to debug
```




This crashes for me using `numba==0.56.2` (and version 0.56.0) but does not crash (and produces the correct results) with the following versions: 0.55.0, 0.55.1, and 0.55.2

I believe that this is an acceptable use of `prange` according to the documentation and given that it does not crash with the older versions of `numba`, I believe that this is a bug.

user: jeffspence
labels: llvm: LLVM related issues
bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_8451: state: open
title: `np.std` gives a different result in Numba when the input is an empty array
body: Original Comment: https://github.com/numba/numba/pull/8415#issuecomment-1250123916

MWR:
```python
from numba import njit

@njit
def foo(a):
    return np.std(a)

a = np.array([])
print(foo(a))  # raise => ZeroDivisionError: division by zero
print(foo.py_func(a))  => emit a warning and return nan
```
Implementing this would also mean we'll need proper testing for `np.std` (the tests as of now are a common example across all array reduction functions.) A better alternative as suggested in the original comment is to copy those tests from Numpy. (Links to original Numpy tests at: https://github.com/numba/numba/pull/8415#issuecomment-1250123916)
user: kc611
labels: good second issue: A good issue for second time contributors
issue_8444: state: open
title: Pybind11 extended functions and classes support in no python mode
body: ## Feature request
Pybind11 extended functions and classes support in no python mode,
these are either made into their own binaries (modules) by pybind or are included while emmbdeding (PYBIND11_EMBEDDED_MODULE).

Why use something like this ?
For using python as a scripting language in game engines. Python is super easy to use by anyone, but every one quickly learns about it being slower than compiled languages by orders of magnitudess. But what if someone is able to compile python while being able to use the sea of libraries (my main usecase is with machine learning libraries) that are easily accessible.

I am extremely sorry for not following the proper github issue template, this is my first issue ever.
Please tell me what all I should add to the issue for it to be considered valid issue, I have done a basic search of pybind11 in the issue search bar and didnt get any related result.




user: sivansh11
issue_8443: state: open
title: Additional examples and documentation for cfuncs
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->


I have added some proposed documentation updates for advanced techniques in writing cfuncs, including the use of function pointers in signatures. These are based on scenarios I've encountered in development. I'm not sure the cfunc documentation file is the best place for all of them, so I'm open to suggestions for where to move them or how to improve them. I hope these techniques and examples will prove useful.
user: bpdavis86
labels: Effort - medium: Medium size effort needed
issue_8436: state: open
title: Auto-generated testing for matching numpy API in `@overload`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Suggested by @stuartarchibald during discussion on https://github.com/numba/numba/pull/8250 in the developer meeting. 

The `@overload` API should allow us to auto-generate tests that checks if the Numba implementations of NumPy API match the original NumPy API.

- Check parameter names are consistent
- Check default argument values are consistent
- and maybe more 

user: sklam
issue_8430: state: open
title: Feature request: Expose optimisation configuration into user space.
body: Following on from numerous reports and at least two lengthy discussions at different times during the weekly Numba public meetings, this ticket is a meta-issue to promote and record discussion on the following:

1. The "default" optimisation level Numba should use for compilation.
2. How to expose more and more fine grained optimisation options into user space through
   the existing Numba APIs.

----------------------

At present 1. is implemented approximately as follows:

* Run a "cheap" optimisation pass with view of inlining as much as possible.
This is so as to expose as many Numba reference counting operations as
possible to Numba's custom reference count pruning pass. This currently
comprises:
  * Running something like `-O0` with "loop rotation", "loop invariant code
    motion" and "CFG simplification" passes added. It turns out in practice
    that these are commonly needed to help transform the LLVM IR that Numba
    generates into something that will perform well under the "expensive"
    optimisation pass, particularly with respect to vectorisation.
  * Running the aforementioned reference count pruning pass.

* Run an "expensive" optimisation pass, which is something like `-O3` cf.
`clang -O3`, with loop and SLP vectorisation enabled.

Historically (prior to Numba 0.55) what eventually became the "cheap" pass was running at `-O3` and there was a less sophisticated reference count pruner running (it could only analyse operations within a basic block). Essentially, Numba ran the `-O3` passes over the code twice!

The reason for the change between 0.54 and 0.55 was that a new Numba-reference-count operation pruning pass was developed. These reference counts a) impact runtime performance and b) prevent certain classes of optimisations), therefore a strategy to do as much as possible to remove Numba specific reference counting operations was employed as described above. Further, for a lot of code, it was observed that running `-O3` twice had little benefit, it can end up making negligible difference to performance but at a much increased compilation cost, this further informed the strategy above.

As has been noted in various open issues, there have been cases where a single `-O3` pass has missed optimisations which can be undertaken by running a subsequent `-O3` pass. See issues: #8398, #8172, #8314, #6547.

*Input on what a "better" default would be is welcomed!*

------------------------------
With regards to 2. a brief summary from prior discussions (this is from memory, so please do correct as needed).

Commonly described use cases:

1. Users who are perhaps not explicitly concerned about a certain performance characteristic, they want something that is "reasonable" in terms of compilation and execution time by default.
2. Users in HPC/high performance situations where any compilation cost is accepted if it reduces runtime. i.e. compilation time is dwarfed by the run time.
3. Users that are compilation time constrained and know which functions are worth optimising. e.g. dynamic code generation situations/"interactive" applications.
4. Users wanting to do incredibly fine grained tuning of optimisation pipelines for some purpose.
5. Users researching compilers wanting fine grained specification of the optimisation pipelines.

Previously discussed options (not mutually exclusive):

1. Expose pre-canned defaults like `O0/O1/O2/O3` etc.
2. Permit use of a custom optimisation pipeline spelled via the LLVM pass names.
3. Expose some more colloquial terms like "hot", "cold" etc to govern the amount
   of effort Numba should put in to compiling a given function.
4. Expose an option for "keep trying until the optimisation passes have no further meaningful effect".

Previously discussed method(s) of exposing the options (not mutually exclusive):

1. Setting a new global default.
2. Setting the option per-function as part of the `@njit` decoration options.

*Input is welcomed on use cases, optimisation options, and their method of exposure into user space.*
user: stuartarchibald
labels: discussion: An issue requiring discussion
issue_8417: state: open
title: Error flag NameError: global name 'length_of_iterator' is not defined with inline function
body: Hi! After a [brief disscussion](https://gitter.im/numba/numba?at=6311eeceaa09177429ede527) with @gmarkall, I could reproduce a (possibly) misleading error flag. It is due to an interaction with dictionaries, loops, and inline functions, caused by a `numba.ir.core.ir.Jump` instance in [_find_arraycall](https://github.com/numba/numba/blob/447fd9628c66ef18623fc5b65291a8845ed9841d/numba/core/inline_closurecall.py#L896). 

Although the error arised from a very naive first use of numba, it is always nice to have good error handling.

Script that reproduces the bug:

```python
from numba import jit
import numpy as np


class some_other_class():
    def __init__(self):
        pass

    @jit()
    def inline_function(self, vec):
        all(app is None for app in vec)


class some_class():
    def __init__(self, f):
        self.f = f
        self.p = {'apples': 1, 'bananas': 2, 'cherries': 3}

    @jit(nopython=False)
    def compute_Phi(self,
                    y0: dict,
                    vec):
        p = self.p
        y0_refv = np.array([p[i] for i in y0.keys()])
        n_param = len(y0)
        Phi_i = np.zeros(shape=(1, n_param))

        for j in range(n_param):
            deltah = 0.5*y0_refv[j]

            x_mas = self.f(vec)
            x_men = self.f(vec)

            Phi_i[:, j] = (x_mas - x_men)
        return Phi_i


m = some_other_class()


@jit()
def another_function(*args):
    return m.inline_function(*args)


y0 = {'apples': 1, 'bananas': 2, 'cherries': 3}


a = some_class(another_function)
b = a.compute_Phi(y0, [None, 1, 2, 3])
```

user: callejon97
labels: objectmode: object mode related issue
bug - failure to compile: Bugs: failed to compile valid code
issue_8405: state: open
title: Checks for function type casting erroneously assume compilation is always possible
body: Originally noted in https://numba.discourse.group/t/type-inference-for-dispatching-of-function-arguments-in-njit-with-multiple-signatures/1536/2

When function compilation is disabled (e.g. due to eager typing), checks whether one function typing can cast to another typing of the function cause the whole compilation to fail because it forces a compilation which is assumed to succeed, which then raises because compilation is disabled.

For example (slightly modified from the Discourse post):

```python
from numba import njit, float64, bool_
from numba.core.types import FunctionType, UniTuple, Tuple


@njit([float64(float64)])
def f(x):
    return x + 3


@njit([float64(float64, bool_)])
def g(x, b):
    return x if b else 0.0


@njit([float64(FunctionType(float64(float64)), float64, Tuple(())),
       float64(FunctionType(float64(float64, bool_)), bool_, UniTuple(bool_, 1))])
def h(fn, x, *args):
    return fn(x, *args)


h_g = h(g, 1.0, *(True,))
print(f"h_g = {h_g}")

h_f = h(f, 1.0, *())
print(f"h_f = {h_f}")
```

fails with:

```
$ python repro.py 
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/discourse-1536/repro.py", line 21, in <module>
    h_g = h(g, 1.0, *(True,))
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 716, in _search_new_conversions
    conv = self.typingctx.install_possible_conversions(args, sig.args)
  File "/home/gmarkall/numbadev/numba/numba/core/typing/context.py", line 585, in install_possible_conversions
    conv = self.can_convert(actual, formal)
  File "/home/gmarkall/numbadev/numba/numba/core/typing/context.py", line 533, in can_convert
    forward = fromty.can_convert_to(self, toty)
  File "/home/gmarkall/numbadev/numba/numba/core/types/functions.py", line 581, in can_convert_to
    if self.dispatcher.get_compile_result(other.signature):
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 981, in get_compile_result
    self.compile(atypes)
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 937, in compile
    raise RuntimeError("compilation disabled")
RuntimeError: compilation disabled
```

If I modify the Dispatcher type's `can_convert_to()` method so that it catches the `RuntimeError` caused because compilation is disabled:

```diff
diff --git a/numba/core/types/functions.py b/numba/core/types/functions.py
index f3b313e2c..33b939d54 100644
--- a/numba/core/types/functions.py
+++ b/numba/core/types/functions.py
@@ -578,8 +578,11 @@ class Dispatcher(WeakType, Callable, Dummy):
 
     def can_convert_to(self, typingctx, other):
         if isinstance(other, types.FunctionType):
-            if self.dispatcher.get_compile_result(other.signature):
-                return Conversion.safe
+            try:
+                if self.dispatcher.get_compile_result(other.signature):
+                    return Conversion.safe
+            except RuntimeError:
+                return None
 
 
```

then the example runs to completion:

```
$ python repro.py 
h_g = 1.0
h_f = 4.0
```
user: gmarkall
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8404: state: open
title: llvmlite assertion when using deferred type as typed dict values
body: From: https://numba.discourse.group/t/cannot-gettypeinfo-on-a-type-that-is-unsized-error-on-jitclass-with-typed-dict-variable-that-has-deferred-type-as-value-type/1191

```python
import numba as nb
from collections import OrderedDict
from numba import deferred_type, optional
from numba.experimental import jitclass
from numba import types

node_type = deferred_type()

@jitclass([
  ('parent', optional(node_type)),
  ('children', types.DictType(types.int32, node_type)),
])
class TreeNode(object):
    def __init__(self, parent=None):
        self.parent = parent
        self.children = nb.typed.Dict.empty(types.int32, node_type)

node_type.define(TreeNode.class_type.instance_type)

t = TreeNode()
t2 = TreeNode(t2)
```

produces:

```
$ python repro.py 
reducer_override for <class 'type'>
python: /opt/conda/conda-bld/llvmdev_1637166008009/work/lib/IR/DataLayout.cpp:713: llvm::Align llvm::DataLayout::getAlignment(llvm::Type*, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed.
Aborted (core dumped)
```

This may be an llvmlite bug or a combination of Numba doing something bad and llvmlite not catching / handling it very well, but I'm just opening the issue with the initial reproducer to start tracking it.

**Note:** Edits made to the the reproducer so it can run to completion once the Numba issue is resolved (the initial revision tried to pass `1` as `parent`, when it should have been a tree node type).

**To do:**

- [ ] Create an llvmlite reproducer / issue and investigate whether the assertion failure can easily be prevented.
user: gmarkall
labels: bug - ice: Bugs: internal compiler error
issue_8402: state: open
title: Pretty-printed type annotation is broken
body: The following:

```python
from numba import njit

@njit('int32(int32, int32)')
def f(x, y):
    return x + y

f.inspect_types()
f.inspect_types(pretty=True)
```

prints, in a terminal:

```
$ python repro.py 
reducer_override for <class 'type'>
f (int32, int32)
--------------------------------------------------------------------------------
# File: /home/gmarkall/numbadev/issues/pretty-broken/repro.py
# --- LINE 4 --- 

@njit('int32(int32, int32)')

# --- LINE 5 --- 

def f(x, y):

    # --- LINE 6 --- 
    # label 0
    #   x = arg(0, name=x)  :: int32
    #   y = arg(1, name=y)  :: int32
    #   $6binary_add.2 = x + y  :: int64
    #   del y
    #   del x
    #   $8return_value.3 = cast(value=$6binary_add.2)  :: int32
    #   del $6binary_add.2
    #   return $8return_value.3

    return x + y


================================================================================
/home/gmarkall/numbadev/numba/numba/core/annotations/pretty_annotate.py:7: FutureWarning: The pretty_annotate functionality is experimental and might change API
  warn("The pretty_annotate functionality is experimental and might change API",
```

i.e. the non-pretty version works as expected, and the pretty-printed version prints a warning about the experimental nature of the feature and then produces nothing. According to the [`inspect_types()` docs](https://numba.readthedocs.io/en/stable/reference/jit-compilation.html?highlight=inspect_types#Dispatcher.inspect_types), I should expect the same output again but colourised.
user: gmarkall
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8398: state: open
title: 50% performance drop from py3.8/numba 0.51.2 to py3.9/numba 0.55.1
body: I have noticed a very large performance drop when executing the same code on identical hardware under two versions of Numba. The meat of the code performs a modified version of a dot product (implemented via loops, not external functions) on subsets of a very large array.

Setup 1:
Anaconda 3.8.5
numba 0.51.2
numpy 1.19.2
llvmlite 0.34.0
mkl 2020.2
Runtime: 248 seconds

Setup 2:
Anaconda 3.9.12
numba 0.55.1
numpy 1.21.5
llvmlite 0.38.0
mkl 2021.4.0
Runtime: 361 seconds

I was very shocked to see such a large decrease in performance. The code is being executed on identical hardware across two systems. I verified performance using CPU-Z, which yielded almost identical benchmark results.

Is there a way to identify potential library conflicts, etc. which might be leading to such a big performance drop?
user: jordannickerson
labels: performance: performance related issue
performance - run time: Performance issue occurring at run time.
issue_8396: state: open
title: Extend cache invalidation to include changes in other files (take 2)
body: This PR extends the cache invalidation mechanism to detect changes in functions imported from other files and used in the main function. It does that by including the timestamp of the file where any called function resides.

This PR is still a draft.

This approach can deal with the problem described in https://github.com/numba/numba/pull/8375#issuecomment-1223751191
Implemented:
- [x] invalidation when a dispatcher calls another dispatcher, including tests
- [x] invalidation when a cfunc calls another dispatcher, including tests
- [x] invalidation when a ufunc call another ufunc, including tests
- [x] invalidation of user-defined overloads, including tests
- [x] user documentation
- [x] developer documentation

Notes for reviewer:
The key idea is to extend the mechanism that already exists to invalidate the cache when the file of the main function changes, to invalidate the cache the file of secondary functions change. For each file identified, the `FileStamp` will be saved in the cache. Those changes can be found in `caching.py` (methods `save`, `load` and related methods). 
Calculating the `FileStamp` is easy, the larger changes in this PR are related to figuring which functions (are therefore files) are dependencies of the main function. At the center of that task is the function `get_function_dependencies` in `caching.py`. This function uses the `typemap` information to identify which functions are called by the main function. After each secondary function is identified, then they are queried to retrieve those other functions on which the secondary functions might depend. This querying is done against a `cache_deps_info` method in the function-like object (dispatcher, cfunc, overload, etc).
The process is iterative, but it is cached to avoid recalculating the dependencies every time.
The above describes the "saving" part of the caching, but not the "loading" part of the caching. Since the saving part relies on typing information which is not available during loading, the loading part works exclusively with the `FileStamp`s which were stored in the cache. Each file identified as a dependency will be checked against the stored `FileStamp`. Any mismatch invalidates the cache.


Limitations (included in the documentation):
- functions overloaded without the `overload` decorator.
- numba-inlined functions 
- guvectorize, due to problems with JITLibrary
- parfors

Notes:
When cfunc calls another cfunc, or a dispatcher calls a cfunc, the cache does not work. Therefore it's not necessary to take into account in the invalidation.
Invalidation does not work with guvectorize, which uses JITLibrary, which do not have type_annotation information
parfors: functions like `'sum__parallel__impl____locals____sum__1__v2__val.2'` not found in `typemap`. There's a workaround to ignore those cases, but invalidation does not work.


user: luk-f-a
labels: Effort - long: Long size effort needed
4 - Waiting on second reviewer: Patch needs a second reviewer.
issue_8394: state: open
title: PEP684 Subinterpreter support
body: ## Feature request

[PEP684](https://peps.python.org/pep-0684/) will allow subinterpreters to be properly isolated (separate module state, separate GIL) in Python 3.11. However, extension modules will need to be modified properly support subinterpreters; e.g. C globals needs to be protected from multiple interpreters.

Numba needs to decide on how multi-interpreters are supported. 

Options:

0. Unsupported.
1. Complete isolation. Every interpreter is treated as if they are separate process. This will require extension modules to be isolated and LLVM JIT engine to be created per interpreter.
2. Shared LLVM JIT state. Avoid JITing the same function multiple times. Share JIT engine in the process.

Other things to consider:

- Managing JITed function lifetime. Interpreters can be created dynamically and destroyed throughout the process lifetime.
- GPU resources?
- Rethink all `atexit` use

### Additional reading:

Related discussion for NumPy: https://mail.python.org/archives/list/numpy-discussion@python.org/thread/A3CWGUGK23D33ECXCX6C7JN6OK273KAJ/
How to isolate extensions: https://peps.python.org/pep-0630/
user: sklam
labels: discussion: An issue requiring discussion
issue_8372: state: open
title: typed.List.append not validating incompatible types correctly
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the ~latest released~ mainline version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit, typed
import numpy as np

@njit
def foo(a):
    x = typed.List.empty_list(a.dtype)
    x.append('a')

foo(np.ones(1))
```
produces a (600+ lines) typing error containing a lowering error, which means something wasn't caught at typing time, the relevant bit is:
```
No implementation of function Function(<function impl_append at 0x7fef5ab84700>) found for signature:

 >>> impl_append(ListType[dtype(float64)], Literal[str](a))

There are 2 candidate implementations:
    - Of which 1 did not match due to:
    Overload in function 'impl_append': File: numba/typed/listobject.py: Line 592.
      With argument(s): '(ListType[dtype(float64)], unicode_type)':
     Rejected as the implementation raised a specific error:
       NumbaNotImplementedError: Failed in nopython mode pipeline (step: native lowering)
     Cannot cast unicode_type to dtype(float64): %"inserted.parent" = insertvalue {i8*, i64, i32, i32, i64, i8*, i8*} %"inserted.meminfo.1", i8* %"arg.item.6", 6
```
I'd guess that there's some validation missing in `typed.List.append` to ensure that the provided value is compatible with the list type.
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
bug - typing: Bugs: occuring at typing time
issue_8346: state: open
title: pycc compatibilty with versioneer
body: I notice that `CC.distutils_extension` monkey patches `distutils.command.build_ext.build_ext` with a modified subclass, this can lead to a bug when using with `versioneer`.

In versioneer.py:
```python
    if "build_ext" in cmds:
        _build_ext = cmds["build_ext"]
    elif "setuptools" in sys.modules:
        from setuptools.command.build_ext import build_ext as _build_ext
    else:
        from distutils.command.build_ext import build_ext as _build_ext

    class cmd_build_ext(_build_ext):
        def run(self):
            root = get_root()
            cfg = get_config_from_root(root)
            versions = get_versions()
            _build_ext.run(self)
            if self.inplace:
                # build_ext --inplace will only build extensions in
                # build/lib<..> dir with no _version.py to write to.
                # As in place builds will already have a _version.py
                # in the module dir, we do not need to write one.
                return
            # now locate _version.py in the new build/ directory and replace
            # it with an updated value
            target_versionfile = os.path.join(self.build_lib, cfg.versionfile_build)
            print("UPDATING %s" % target_versionfile)
            write_to_version_file(target_versionfile, versions)

    cmds["build_ext"] = cmd_build_ext
```
It also patches `build_ext` with its customized version of build_ext.
So the following will fail:
```python
setup(version=versioneer.get_version(),
      cmdclass=versioneer.get_cmdclass(),
      ext_modules=[cc.distutils_extension()])
```

```python
Traceback (most recent call last):
  File ".../setup_example/test.py", line 8, in <module>
    import src.aot as aot
ImportError: .../setup_example/src/aot.cpython-39-x86_64-linux-gnu.so: undefined symbol: nrt_atomic_sub
```

However if we just switch `cmdclass` & `ext_modules`:
```python
setup(version=versioneer.get_version(),
      ext_modules=[cc.distutils_extension(),
      cmdclass=versioneer.get_cmdclass()])
```
this will succeed. Because in the first case, the ultimate cmdclass will not use pycc's build_ext class (the cmdclass is created before pycc's money patch), but the second will.

I propose a simple fix here:
rather than patching the entire class, I patch only `build_extension` method:
```python
    @classmethod
    def monkey_patch_distutils(cls):
        """
        Monkey-patch distutils with our own build_ext class knowing
        about pycc-compiled extensions modules.
        """
        if cls._distutils_monkey_patched:
            return

        _orig_build_ext = build_ext.build_ext.build_extension

        def build_extension(self, ext):
            if isinstance(ext, _CCExtension):
                ext._prepare_object_files(self)

            _orig_build_ext(self, ext)

        build_ext.build_ext.build_extension = build_extension

        cls._distutils_monkey_patched = True

```
In this way it will not be influenced by the order of `get_cmdclass()` & `cc.distutils_extension()`

If you feel this is reasonable I'm willing to make a PR.
user: auderson
labels: AOT: ahead of time compilation issue
issue_8340: state: open
title: nan as dict key different behavior in py3.10
body: In Cpython, dict key lookup will first check `__hash__` then `__eq__`: https://github.com/python/cpython/blob/main/Objects/dictobject.c
This causes deviation from python dicts and numba dicts, if nan is used as dict keys. 
In certain cases, numba dict will produce some unexpected errors which I'll show below.

`np.nan` is a constant so they have the same hash:
```python
d = {}
d[np.nan] = 1
d[np.nan] = 2
print(d)
# {nan: 2}
```
`float('nan')` is not (but if stored as constant, then behave the same as `np.nan`)
 ```python
d = {}
d[float('nan')] = 1
d[float('nan')] = 2
print(d)
# {nan: 1, nan: 2}
```
~numba seems to use `==` only:~
```python
@njit
def test():
    d = {}
    d[np.nan] = 1
    d[np.nan] = 2
    return d

d = test()
```
now this will produce error:
```python
print(d)  # d.keys(), d.values(), d.items()
```
```
Traceback (most recent call last):
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/IPython/core/formatters.py", line 222, in catch_format_error
    r = method(self, *args, **kwargs)
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/IPython/core/formatters.py", line 707, in __call__
    printer.pretty(obj)
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/IPython/lib/pretty.py", line 410, in pretty
    return _repr_pprint(obj, self, cycle)
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/IPython/lib/pretty.py", line 778, in _repr_pprint
    output = repr(obj)
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/numba/typed/typeddict.py", line 187, in __repr__
    body = str(self)
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/numba/typed/typeddict.py", line 182, in __str__
    for k, v in self.items():
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/_collections_abc.py", line 906, in __iter__
    yield (key, self._mapping[key])
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/numba/typed/typeddict.py", line 150, in __getitem__
    return _getitem(self, key)
  File "/home/auderson/miniconda3/envs/py3.10/lib/python3.10/site-packages/numba/typed/dictobject.py", line 739, in impl
    raise KeyError()
KeyError
```
~This is a KeyError so I guess it's from `nan != nan`.~
Besides:
```python
len(d)
# 2
```
Then the actual content of this numba dict is most likely `{nan: 1, nan: 2}`.

Maybe I don't think this can be called a bug. But it does make numba behave differently from numpy codes. What do you think?

user: auderson
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8328: state: open
title: Support creating a dictionary from a zipped value
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

In regular Python you can zip together two sequences and created a dictionary using dict`. We should support the same in JIT (excluding heterogeneous sequences like tuples with mixed types). Here is a reproducer:

```python3
import numpy as np
import numba

@numba.njit
def f(arr1, arr2):
    return dict(zip(arr1, arr2))

arr1 = np.arange(4)
arr2 = np.arange(4, 8)


print(f(arr1, arr2))
```

Outputs: `numba.core.errors.TypingError: Unsupported use of 'dict()' with positional or keyword argument(s). The only supported use is 'dict()'.` 
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: njriasan
issue_8327: state: open
title: Support List as a value type in njit dictionaries
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->
It doesn't appear to be possible to pass a list as a value inside a dictionary. Here is a simple reproducer.

```python3
import numba

@numba.njit
def f():
    d = {}
    for i in range(10):
        d[str(i)] = [i]
    return d

print(f())
```

Produces: `numba.core.errors.TypingError: list(int64)<iv=None> as value is forbidden`

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: njriasan
issue_8316: state: open
title: Fix error handling in float unboxing
body: This is split from #5113.

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: eric-wieser
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_8307: state: open
title: Ambiguous overloads are allowed for calls to jitted functions inside other jitted functions
body: For example:

```python
from numba import njit

@njit(['(float32, float64)', '(float64, float32)'])
def add(x, y):
    return x + y

# (float64, float64) is an equal match for the (float32, float64) and (float64, float32) compiled versions
try:
    add(1.0, 2.0)
except TypeError as te:
    print(f"Got TypeError as expected: {str(te)}")

# Also an equal match for the compiled versions of add, but is allowed to compile
@njit('(float64, float64)')
def add_caller(x, y):
    return add(x, y)

print(add_caller(1.0, 2.0))
```

```
Got TypeError as expected: Ambiguous overloading for <function add at 0x7fa5c51b9cf0> (float64, float64):
(float32, float64) -> float64
(float64, float32) -> float64
3.0
```

So the dispatcher disallows dispatch of ambiguous overloads, but the compiler permits compilation with them. Is this intended?

Why do ambiguous overloads even matter? Could we just pick the first one instead of giving an error?
user: gmarkall
labels: discussion: An issue requiring discussion
bug - miscompile: Bugs: miscompile
issue_8305: state: open
title: Len of two concatenated Bytes objects is 0
body: 
```python
import numba
import numpy as np


@numba.njit
def addbytes_len_usecase(a, b):
    output = len(b''.join([a, b]))
    return output

b_val = b"abcd"
addbytes_len_ans = addbytes_len_usecase(b_val, b_val) 
print(f"addbytes_len_ans: {addbytes_len_ans}")

```

Returns 0.


<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: allai5
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8301: state: open
title: Worst case performance of njitted any vs. plain numpy any
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

Timing a numba jitted function that uses `np.any` I noticed very bad worst case performance compared to numpy any.

Simple example:

```

In [1]: import numpy as np

In [2]: a = np.zeros(1000000, dtype=bool)

In [3]: %timeit np.any(a)
45.4 µs ± 1.43 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In [4]: import numba

In [5]: from numba import njit

In [6]: @numba.njit()
   ...: def any_njit(a):
   ...:     return np.any(a)

In [7]: any_njit(a)
Out[7]: False

In [8]: %timeit any_njit(a)
888 µs ± 2.2 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

```

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: maxnoe
labels: performance - run time: Performance issue occurring at run time.
issue_8298: state: open
title: Function compilation not being updated for specific types on 32-bit systems
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Note: This is only observed in 32-bit systems and not 64-bit ones.

```python
import numba
import numpy as np

@numba.njit
def foo(x):
    print("from within: ",x)
    return x

foo(0)
print( foo( np.iinfo(np.int32).max + 1) )
# Returns a negative integer (overflow), the function signature stays as `int32` argument instead of an `int64`/`uint32`
```

First encountered in #8041
user: kc611
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8296: state: open
title: Add citation support
body: Github supports `CITATION.cff`. See https://github.blog/2021-08-19-enhanced-support-citations-github/.
We should add it to help folks cite Numba. 
user: sklam
issue_8286: state: open
title: `Bytes` type fails `len` when parallel
body: ```python
import numba

@numba.njit(parallel=True)
def f(x):
    return len(x)

print(f(b"abcd"))
```

Bytes type fails in array analysis when in parallel with the following error. It appears to do so because it inherits from `ArrayCompatible`. Here is the resulting error:

```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
No definition for lowering readonly bytes(uint8, 1d, C).shape

File "test.py", line 6:
def f(x):
    return len(x)
    ^
During: lowering "x_shape.0 = getattr(value=x, attr=shape)" at /tmp/test.py (6)
```
user: benwilliamgraham
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8285: state: open
title: Slice of byte string has an incorrect result with boxing
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Slicing a byte string results in an implementation that is not compatible with boxing. This occurs because the byte string is reusing the array implementation of a no copy slice, creating a view that iterates over the byte string. However, the boxing code that's written just takes a data pointer and a length, making it unable to properly construct the new string.

Here is a reproducer:
```python3
import numba
@numba.njit
def reverse(val):
    return val[::-1]

print(reverse(b'12345'))
```

Results in:
```shell
zsh: segmentation fault  python bytes_ex.py
```

In other runs I have seen the output start at the last value and then access outside the buffer.
user: njriasan
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_8284: state: open
title: Support set_parallel_chunksize in the OpenMP threading layer
body: Numba 0.56.0 has chunking capabilities which work great using the default `tbb` threading layer. The new feature `set_parallel_chunksize` is beneficial for some work loads allowing better CPU utilization on many-core systems.

This is a feature request to support `set_parallel_chunksize` for the `omp` threading layer.
user: marioroy
issue_8282: state: open
title: Numba Wrapper Address Protocol (WAP) is broken
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Reproducer is from [Numba docs](https://numba.pydata.org/numba-doc/latest/reference/types.html#wrapper-address-protocol-wap):

```python
import numba, ctypes, ctypes.util, math

libm = ctypes.cdll.LoadLibrary(ctypes.util.find_library('m'))

class LibMCos(numba.types.WrapperAddressProtocol):
    def __wrapper_address__(self):
        return ctypes.cast(libm.cos, ctypes.c_voidp).value
    def signature(self):
        return numba.float64(numba.float64)

cos = LibMCos()

@numba.njit
def foo(f, x):
    return f(x)

print(foo(cos, 0.0))
```

```
$ python repro.py
Traceback (most recent call last):
  File "/home/guilhermeleobas/git/numba/repro.py", line 17, in <module>
    print(foo(cos, 0.0))
  File "/home/guilhermeleobas/git/numba/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/guilhermeleobas/git/numba/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type pyobject
During: typing of argument at /home/guilhermeleobas/git/numba/repro.py (15)

File "repro.py", line 15:
def foo(f, x):
    return f(x)
```
user: guilhermeleobas
labels: bug - regression: A regression against a previous version of Numba
bug - typing: Bugs: occuring at typing time
issue_8270: state: open
title: Support `np.any` for scalar input
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Not sure if this is a bug or just missing, but numba does not support calling `np.any` on a single boolean, which numpy does:



```

In [1]: import numpy as np

In [2]: np.any(True)
Out[2]: True

In [3]: np.any(False)
Out[3]: False

In [4]: import numba

In [5]: @numba.njit
   ...: def numba_any(vals):
   ...:     return np.any(vals)

In [6]: numba_any(True)
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Input In [6], in <module>
----> 1 numba_any(True)

File ~/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/numba/core/dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 468     error_rewrite(e, 'typing')
    469 except errors.UnsupportedError as e:
    470     # Something unsupported is present in the user code, add help info
    471     error_rewrite(e, 'unsupported_error')

File ~/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function any at 0x7ff4004f5820>) found for signature:
 
 >>> any(bool)
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'np_any': File: numba/np/arraymath.py: Line 869.
    With argument(s): '(bool)':
   Rejected as the implementation raised a specific error:
     LoweringError: Failed in nopython mode pipeline (step: native lowering)
   Invalid store of i1* to i8* in <numba.core.datamodel.models.NdIter object at 0x7ff3b2bd29a0> (trying to write member #4)
   
   File "../../.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/numba/np/arraymath.py", line 873:
       def flat_any(a):
           for v in np.nditer(a):
           ^
   
   During: lowering "$8call_method.3 = call $4load_method.1(a, func=$4load_method.1, args=[Var(a, arraymath.py:873)], kws=(), vararg=None, target=None)" at /home/maxnoe/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/numba/np/arraymath.py (873)
  raised from /home/maxnoe/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/numba/core/errors.py:837

During: resolving callee type: Function(<function any at 0x7ff4004f5820>)
During: typing of call at <ipython-input-5-1baff706b788> (3)


File "<ipython-input-5-1baff706b788>", line 3:
def numba_any(vals):
    return np.any(vals)
    ^
```
user: maxnoe
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8268: state: open
title: Use of uninitialized values for empty loops
body: Surprisingly, this returns zero in numba
```python
@numba.njit
def foo(vals):
    for x in vals:
        pass
    return x

foo(np.zeros(0))
```
I think this is because it declares the loop variable before the loop without initializing it, and then returns the value.

We can turn this into segfaults eg by iterating over objects instead of plain values:

```python
from numba.typed import List

list_inner = List([0])
object_list = List([list_inner])
object_list.pop()  # it is an empty typed list of objects now

foo(object_list)  # -> segfault
```

This is on numba HEAD, commit 34ec4ef21f
user: aseyboldt
labels: discussion: An issue requiring discussion
bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_8262: state: open
title: msan support
body: ## Feature request

Add LLVM [MSan](https://github.com/google/sanitizers/wiki/MemorySanitizer) support for JIT code.

In builds that enable MSan for building numba and Python, AOT compiled code is instrumented to add memory sanitization checks. In contrast the JIT code generated by numba is not instrumented, and when calling into the numba or Python runtimes it often passes memory that the instrumented code does not believe has been initialized.

This leads to unavoidable uninitialized-memory-read false positives.

user: folded
issue_8246: state: open
title: Exception in first-class function called through typed list swallows exceptions
body: As discussed in [gitter](https://gitter.im/numba/numba?at=62c7e37e22c53438bc403737)

numba=0.55.1
python=3.7.1
windows10

Calling the first-class function from a jitted function causes the exception to be swallowed.

The exception terminates the program as expected when called from plain python.

```python
import numba
import sys

@numba.njit('int64(int64, int64)')
def raise_err(a, b):
    raise RuntimeError('yo')

def make_typed_list(pylist):
    lst_type = pylist[0].nopython_signatures[0].as_type()
    lst = numba.typed.List.empty_list(lst_type)
    [lst.append(x) for x in pylist]
    return lst

py_list = [raise_err]
lst = make_typed_list(py_list)

@numba.njit
def docall(fns, a, b):
    fns[0](a, b)

print('calling from jit func', file=sys.stderr)
docall(lst, 3, 7)

print('\ncalling from plain python', file=sys.stderr)
lst[0](3, 7)
```

user: nelson2005
issue_8230: state: open
title: Refactor tasks: remove `mk_unique_var`
body: Reason: `mk_unique_var` uses global state that lives outside of the `Scope` object. `Scope.redefine` can be used instead. `Scope.redefine` provides a better way to manage variable names.

**NOTE**: The list below is left for historical reasons, but the plan is now to move `mk_unique_var()` out of `ir_utils` and into somewhere in parfors - see https://github.com/numba/numba/issues/8230#issuecomment-1478330246 - (edit by @gmarkall).

Files that references `mk_unique_var`:

- [x] `numba/core/inline_closurecall.py` (patch https://github.com/numba/numba/pull/8229)
- [x] `numba/core/untyped_passes.py`
- [x] `numba/parfors/array_analysis.py`
- [ ] `numba/parfors/parfor_lowering_utils.py`
- [ ] `numba/parfors/parfor_lowering.py`
- [ ] `numba/parfors/parfor.py`
- [x] `numba/stencils/stencil.py`
- [ ] `numba/stencils/stencilparfors.py`

Finally, remove the definition:

- [ ] `numba/core/ir_utils.py`
user: sklam
issue_8218: state: open
title: CUDA: Numerical differences between CPython / CPU target and the CUDA target in `math.pow`
body: Originally noticed [on Discourse](https://numba.discourse.group/t/some-trouble-of-using-cuda-kernel-function-to-calculate-heap-sort/1421).

The following:

```python
from numba import cuda, njit
import numpy as np
import math


def inner(x, y):
    return int(math.pow(x, y))


cpu_jitted = njit(inner)


def cuda_jitted(x, y):
    inner_device = cuda.jit(device=True)(inner)

    @cuda.jit
    def outer(r, x, y):
        r[()] = inner_device(x[()], y[()])

    r_arr = np.array(0, dtype=np.int64)
    x_arr = np.array(0, dtype=np.int64)
    y_arr = np.array(0, dtype=np.int64)
    x_arr[()] = x
    y_arr[()] = y
    outer[1, 1](r_arr, x_arr, y_arr)

    return r_arr[()]


x = 3
y = 1

print(inner(x, y))
print(cpu_jitted(x, y))
print(cuda_jitted(x, y))
```

prints

```
3
3
2
```

This can cause some surprise.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8213: state: open
title: Numba changes behavior of np.flip when assigning flipped output back into input array
body: ## Reporting a bug

While debugging a problem with a larger computation, I traced the issue to a change in behavior of **numpy.flip** once the **@numba.njit()** decorator is added.

Here is the reproducible code:

    import numpy as np, numba as nb
    
    print('NUMBA VERSION: {}'.format(nb.__version__))
    print('NUMPY VERSION: {}'.format(np.__version__))
    
    @nb.njit()
    def fnNumba2d(numy, offsetx):
        x = np.arange(numy, dtype=np.int64).reshape((1, numy))
        print('INTERMEDIATE RESULT FOR 2D NP.FLIP AT OFFSET ', offsetx, '    (NUMBA): ', np.flip(x[0, offsetx:(offsetx+2)]))
        x[0, offsetx:(offsetx+2)] = np.flip(x[0, offsetx:(offsetx+2)])
        print('FINAL        RESULT FOR 2D NP.FLIP AT OFFSET ', offsetx, '    (NUMBA): ', x[0, offsetx:(offsetx+2)])
        return x
    
    def fnNoNumba2d(numy, offsetx):
        x = np.arange(numy, dtype=np.int64).reshape((1, numy))
        print('INTERMEDIATE RESULT FOR 2D NP.FLIP AT OFFSET ', offsetx, ' (NO NUMBA): ', np.flip(x[0, offsetx:(offsetx+2)]))
        x[0, offsetx:(offsetx+2)] = np.flip(x[0, offsetx:(offsetx+2)])
        print('FINAL        RESULT FOR 2D NP.FLIP AT OFFSET ', offsetx, ' (NO NUMBA): ', x[0, offsetx:(offsetx+2)])
        return x
    
    @nb.njit()
    def fnNumba1d(numy, offsetx):
        x = np.arange(numy, dtype=np.int64)
        x[offsetx:(offsetx+2)] = np.flip(x[offsetx:(offsetx+2)])
        return x
    
    def fnNoNumba1d(numy, offsetx):
        x = np.arange(numy, dtype=np.int64)
        x[offsetx:(offsetx+2)] = np.flip(x[offsetx:(offsetx+2)])
        return x
    
    # NO DIFFERENCE
    np.testing.assert_array_equal(fnNoNumba1d(3, 0), fnNumba1d(3, 0), err_msg="FAILED: FLIP ELEMENTS 0<->1 IN ARRAY SIZE=3")
    
    # NO DIFFERENCE
    np.testing.assert_array_equal(fnNoNumba1d(3, 1), fnNumba1d(3, 1), err_msg="FAILED: FLIP ELEMENTS 1<->2 IN ARRAY SIZE=3")
    
    # NO DIFFERENCE
    np.testing.assert_array_equal(fnNoNumba2d(3, 0), fnNumba2d(3, 0), err_msg="FAILED: FLIP ELEMENTS 0<->1 IN ARRAY SIZE=1x3")
    
    # NUMBA OUTPUT DIFFERS FROM PYTHON
    np.testing.assert_array_equal(fnNoNumba2d(3, 1), fnNumba2d(3, 1), err_msg="FAILED: FLIP ELEMENTS 1<->2 IN ARRAY SIZE=1x3")

This produces the following output:

    NUMBA VERSION: 0.56.0rc1+0.gea8407264.dirty
    NUMPY VERSION: 1.22.4
    INTERMEDIATE RESULT FOR 2D NP.FLIP AT OFFSET  0  (NO NUMBA):  [1 0]
    FINAL        RESULT FOR 2D NP.FLIP AT OFFSET  0  (NO NUMBA):  [1 0]
    INTERMEDIATE RESULT FOR 2D NP.FLIP AT OFFSET  0     (NUMBA):  [1 0]
    FINAL        RESULT FOR 2D NP.FLIP AT OFFSET  0     (NUMBA):  [1 0]
    INTERMEDIATE RESULT FOR 2D NP.FLIP AT OFFSET  1  (NO NUMBA):  [2 1]
    FINAL        RESULT FOR 2D NP.FLIP AT OFFSET  1  (NO NUMBA):  [2 1]
    INTERMEDIATE RESULT FOR 2D NP.FLIP AT OFFSET  1     (NUMBA):  [2 1]
    FINAL        RESULT FOR 2D NP.FLIP AT OFFSET  1     (NUMBA):  [2 2]
    
    ---------------------------------------------------------------------------
    AssertionError                            Traceback (most recent call last)
    Input In [16], in <cell line: 42>()
         39 np.testing.assert_array_equal(fnNoNumba2d(3, 0), fnNumba2d(3, 0), err_msg="FAILED: FLIP ELEMENTS 0<->1 IN ARRAY SIZE=1x3")
         41 # NUMBA OUTPUT DIFFERS FROM PYTHON
    ---> 42 np.testing.assert_array_equal(fnNoNumba2d(3, 1), fnNumba2d(3, 1), err_msg="FAILED: FLIP ELEMENTS 1<->2 IN ARRAY SIZE=1x3")
    
        [... skipping hidden 1 frame]
    
    File ~\.conda\envs\numbabug\lib\site-packages\numpy\testing\_private\utils.py:844, in assert_array_compare(comparison, x, y, err_msg, verbose, header, precision, equal_nan, equal_inf)
        840         err_msg += '\n' + '\n'.join(remarks)
        841         msg = build_err_msg([ox, oy], err_msg,
        842                             verbose=verbose, header=header,
        843                             names=('x', 'y'), precision=precision)
    --> 844         raise AssertionError(msg)
        845 except ValueError:
        846     import traceback
    
    AssertionError: 
    Arrays are not equal
    FAILED: FLIP ELEMENTS 1<->2 IN ARRAY SIZE=1x3
    Mismatched elements: 1 / 3 (33.3%)
    Max absolute difference: 1
    Max relative difference: 0.5
     x: array([[0, 2, 1]], dtype=int64)
     y: array([[0, 2, 2]], dtype=int64)
    
To summarize: If a submatrix within a 2D array is flipped and assigned back into the input, and if this submatrix is not located at column index 0, entries are duplicated rather than flipped.

Is this indeed a bug, or is it not recommended to assign the output of **numpy.flip** back into the input array? (Given that **numpy.flip** returns a view rather than a copy.)
user: acorver
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_8190: state: open
title: `searchsorted` not working with unicode arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

The `np.searchsorted` function does not work with `@njit` when the query array `v` is of unicode dtype. This seems to be because the `np.isnan` function is not implemented for this type. I would like to get this working so that I can use `np.searchsorted` in parallel using `prange` and `@njit(parallel=True)`.

MWE:
```python
# imports
import numpy as np
from numba import njit, prange

# attributes
UNICODE_a = 97
ALPHABET_SIZE = 26

# parameters
n_reference_string = 100
n_query_string = 10
string_length = 32

# create and sort random reference strings
reference_strings_unicode = np.random.choice(
    np.arange(UNICODE_a, UNICODE_a + ALPHABET_SIZE, dtype=np.uint32),
    size=(n_reference_string, string_length),
)
reference_strings = reference_strings_unicode.view(f"<U{string_length}").reshape(-1)
sorted_reference_strings = np.sort(reference_strings)

# create random query strings
query_strings_unicode = np.random.choice(
    np.arange(UNICODE_a, UNICODE_a + ALPHABET_SIZE, dtype=np.uint32),
    size=(n_query_string, string_length),
)
query_strings = query_strings_unicode.view(f"<U{string_length}").reshape(-1)

# JIT-compiled function
@njit
def query(sorted_reference_strings, query_strings):
    return np.searchsorted(sorted_reference_strings, query_strings)

# Execution
query(sorted_reference_strings, query_strings)
```

Error message:
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
Input In [1], in <cell line: 37>()
     32     return np.searchsorted(sorted_reference_strings, query_strings)
     35 # Execution
---> 37 query(sorted_reference_strings, query_strings)

File /opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/core/dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
    464         msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
    465                f"by the following argument(s):\n{args_str}\n")
    466         e.patch_message(msg)
--> 468     error_rewrite(e, 'typing')
    469 except errors.UnsupportedError as e:
    470     # Something unsupported is present in the user code, add help info
    471     error_rewrite(e, 'unsupported_error')

File /opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/core/dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
    407     raise e
    408 else:
--> 409     raise e.with_traceback(None)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function searchsorted at 0x7f67d40d37f0>) found for signature:
 
 >>> searchsorted(array([unichr x 32], 1d, C), array([unichr x 32], 1d, C))
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'searchsorted': File: numba/np/arraymath.py: Line 3773.
    With argument(s): '(array([unichr x 32], 1d, C), array([unichr x 32], 1d, C))':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<function _searchsorted.<locals>.searchsorted_inner at 0x7f67ae15e830>) found for signature:
    
    >>> searchsorted_inner(array([unichr x 32], 1d, C), [unichr x 32])
    
   There are 2 candidate implementations:
         - Of which 2 did not match due to:
         Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba/core/extending.py: Line 159.
           With argument(s): '(array([unichr x 32], 1d, C), [unichr x 32])':
          Rejected as the implementation raised a specific error:
            TypingError: Failed in nopython mode pipeline (step: nopython frontend)
          No implementation of function Function(<ufunc 'isnan'>) found for signature:
           
           >>> isnan([unichr x 32])
           
          There are 2 candidate implementations:
                - Of which 2 did not match due to:
                Overload in function 'Numpy_rules_ufunc.generic': File: numba/core/typing/npydecl.py: Line 98.
                  With argument(s): '([unichr x 32])':
                 Rejected as the implementation raised a specific error:
                   TypingError: can't resolve ufunc isnan for types [[unichr x 32]]
            raised from /opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/core/typing/npydecl.py:107
          
          During: resolving callee type: Function(<ufunc 'isnan'>)
          During: typing of call at /opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/np/arraymath.py (3746)
          
          
          File "../opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/np/arraymath.py", line 3746:
              def searchsorted_inner(a, v):
                  <source elided>
                  n = len(a)
                  if np.isnan(v):
                  ^
   
     raised from /opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/core/typeinfer.py:1086
   
   During: resolving callee type: Function(<function _searchsorted.<locals>.searchsorted_inner at 0x7f67ae15e830>)
   During: typing of call at /opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/np/arraymath.py (3788)
   
   
   File "../opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/np/arraymath.py", line 3788:
           def searchsorted_impl(a, v, side='left'):
               <source elided>
               for view, outview in np.nditer((v, out)):
                   index = loop_impl(a, view.item())
                   ^

  raised from /opt/anaconda/envs/numba_test/lib/python3.10/site-packages/numba/core/typeinfer.py:1086

During: resolving callee type: Function(<function searchsorted at 0x7f67d40d37f0>)
During: typing of call at /tmp/ipykernel_7977/1750162599.py (32)


File "../tmp/ipykernel_7977/1750162599.py", line 32:
<source missing, REPL/exec in use?>
```

Temporary Fix:
```python
def _searchsorted(func):
    def searchsorted_inner(a, v):
        n = len(a)
        # Commenting out this block solves the problem.
        # if np.isnan(v):
        #     # Find the first nan (i.e. the last from the end of a,
        #     # since there shouldn't be many of them in practice)
        #     for i in range(n, 0, -1):
        #         if not np.isnan(a[i - 1]):
        #             return i
        #     return 0
        lo = 0
        hi = n
        while hi > lo:
            mid = (lo + hi) >> 1
            if func(a[mid], (v)):
                # mid is too low => go up
                lo = mid + 1
            else:
                # mid is too high, or is a NaN => go down
                hi = mid
        return lo
    return searchsorted_inner
```

As I see it, there are couple of options here, but I'm open to better ideas:
1. Implement the `np.isnan` function for the unicode dtype. Needs thinking about because there is no null option for this type.
2. Put a wrapper around the `if` block which prevents calling `np.isnan` if the user has specified (through an option) that there are no null items in the sorted array.

I think 1. is preferable to keep the function as close to that in numpy as possible.

This is the first issue I've raised on an open-source project so please do give me some tips! I'm happy to get involved with the fix if somebody could give me some pointers.
user: stonescw
issue_8179: state: open
title: Presence of assertion prevents `literal_unroll` from working
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG) - yes, v0.55.1
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

The following program fails:

```
import numpy as np
import numba as nb
from numba import literal_unroll

@nb.njit(nogil=True)
def f(lhs, K, rhss):
    T, N = lhs.shape
    assert len(rhss) == K # XXX this line
    
    for t in range(0, T):
        trhss_all_unmasked = np.zeros((N, K), dtype=lhs.dtype)
        
        k = -1
        for rhs in literal_unroll(rhss):
            k += 1
            trhss_all_unmasked[:, k] = rhs[t]
         
        # Optional
        #return trhss_all_unmasked.sum()

f(
    np.ones((2, 2), dtype='f8'),
    2,
    (
        np.ones((2, 2), dtype='f8'),
        np.ones((2, 2), dtype='f4')
    )
)
```

With a traceback like this:

```
~/.conda/envs/py3/lib/python3.8/site-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    480                 e.patch_message(msg)
    481 
--> 482             error_rewrite(e, 'typing')
    483         except errors.UnsupportedError as e:
    484             # Something unsupported is present in the user code, add help info

~/.conda/envs/py3/lib/python3.8/site-packages/numba/core/dispatcher.py in error_rewrite(e, issue_type)
    421                 raise e
    422             else:
--> 423                 raise e.with_traceback(None)
    424 
    425         argtypes = []

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Type of variable 'k.6309' cannot be determined, operation: $82inplace_add.5.6308, location: /var/tmp/ipykernel_2146011/1618017692.py (14)

File "../../../../../../var/tmp/ipykernel_2146011/1618017692.py", line 14:
<source missing, REPL/exec in use?>
```

However, if I comment out the assertion it works fine. I don't think the presence of this assertion should be preventing type inference from failing on the loop variable `k`.
user: batterseapower
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8178: state: open
title: poor performance with try except block in parallel 
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.


```python
import numba
from numba import njit, prange
import numpy as np

x = np.random.randn(10, 10)

@njit("void(f8[:, :], i8)")
def test_1(x, n):
    s = np.sum(x, axis=0)
    for i in prange(n):
        s += np.sum(x, axis=0)

@njit("void(f8[:, :], i8)")
def test_2(x, n):
    s = np.sum(x, axis=0)
    for i in prange(n):
        try:
            s += np.sum(x, axis=0)
        except Exception:
            pass

@njit("void(f8[:, :], i8)", parallel=True)
def test_3(x, n):
    numba.set_num_threads(4)
    s = np.sum(x, axis=0)
    for i in prange(n):
        try:
            s += np.sum(x, axis=0)
        except Exception:
            pass

@njit("void(f8[:, :], i8)", parallel=True)
def test_4(x, n):
    numba.set_num_threads(4)
    s = np.sum(x, axis=0)
    for i in prange(n):
        s += np.sum(x, axis=0)
```

Above I create different examples where sum of x is added in a for loop, with & without `parallel=True` and a `try...expect...` block.

When `parallel` is OFF, the perf is the same whether the `try...except...` block exists or not
```python
%%time
test_1(x, 1_000_000)
```
```
CPU times: user 304 ms, sys: 4 ms, total: 308 ms
Wall time: 306 ms
```
```python
%%time
test_2(x, 1_000_000)
```
```
CPU times: user 331 ms, sys: 145 µs, total: 332 ms
Wall time: 330 ms
```
But when `parallel` is ON, the func with `try...except...` block tooks 10 times more to finish:
```python
%%time
test_3(x, 1_000_000)
```
```
CPU times: user 27.7 s, sys: 763 ms, total: 28.5 s
Wall time: 7.12 s
```
```python
%%time
test_4(x, 1_000_000)
```
```
CPU times: user 2.58 s, sys: 7.9 ms, total: 2.59 s
Wall time: 688 ms
```

user: auderson
labels: performance - run time: Performance issue occurring at run time.
issue_8177: state: open
title: Invalid detection of loop index alias in parfors
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the ~latest released~ `main` branch version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def foo(n):
    for i in prange(n):
        alias_of_i = i
        alias_of_i += 1

foo(4)
```
produces:
```
numba/parfors/parfor.py", line 2750, in _replace_loop_access_indices
    raise errors.UnsupportedRewriteError(
numba.core.errors.UnsupportedRewriteError: Failed in nopython mode pipeline (step: convert to parfors)
Overwrite of parallel loop index

File "bug.py", line 8:
def foo(n):
    <source elided>
        alias_of_i = i
        alias_of_i += 1
```
which I think is incorrect as `alias_of_i` is not the loop index, it's a copy of it.
user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_8171: state: open
title: Add a `deepcopy` method to `numba.core.ir.FunctionIR`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

This class holds Numba's internal representation (IR).
https://github.com/numba/numba/blob/57ce5528af436d5269dd4aa34f24b58a2063cef2/numba/core/ir.py#L1325

It could really do with a `deepcopy` method adding to it so as to help prevent accidental mutations and to also help with things like variable renaming and scope transfers.

CC @DrTodd13 
user: stuartarchibald
issue_8168: state: open
title: Support dict.update with keyword argument key, value pairs
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

Initial support for dict.update with a dictionary as the argument is provided in #7964. Update also needs support for passing key value pairs via keyword arguments. Here is a reproducer:

```python3
In [1]: d = {"a": 1, "b": 2}

In [2]: d.update(c=7)

In [3]: d
Out[3]: {'a': 1, 'b': 2, 'c': 7}
``` 

user: njriasan
labels: good second issue: A good issue for second time contributors
issue_8162: state: open
title: `_compiling_counter` should not include code path when an overload is found.
body: From https://github.com/numba/numba/pull/8037#discussion_r896931553

Change https://github.com/numba/numba/blob/e61c3d348e5f21b2b936f498c5fefb74d0a7ba90/numba/core/dispatcher.py#L939-L973 to only include code path that compilation occurs.

user: sklam
labels: good second issue: A good issue for second time contributors
issue_8160: state: open
title: Program crashes without error message on set inside Typed List
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I have use for a 2-D sequence of Sets of varying size, so numpy arrays are not applicable here. I am trying to use `numba.typed.List` instead, as it allows for a reflected inner type, but the following test program crashes without an error message:

```py
import numba

input_set_list = numba.typed.List([numba.typed.List([
    {1, 2, 3} for _ in range(2)
]) for __ in range(2)])
print('Created')
print(input_set_list)
for pisl in input_set_list:
    print(f'{pisl=}')
    for isl in pisl:
        print(f'{isl=}')
        isl.update({9, 8})
```

I would expect this to print out something like:

```
Created
[[{1, 2, 3}, {1, 2, 3}], [{1, 2, 3}, {1, 2, 3}]]
pisl=[{1, 2, 3}, {1, 2, 3}]
isl={1, 2, 3, 9, 8}
isl={1, 2, 3, 9, 8}
pisl=[{1, 2, 3, 9, 8}, {1, 2, 3, 9, 8}]
isl={1, 2, 3, 9, 8}
isl={1, 2, 3, 9, 8}
```

Instead, I see only the following in my console:

```
C:\Users\alpac\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\typed\typedlist.py:83: NumbaPendingDeprecationWarning: ←[1m←[1m
Encountered the use of a type that is scheduled for deprecation: type 'reflected set' found for argument 'item' of function 'impl_append.<locals>.impl'.

For more information visit https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-reflection-for-list-and-set-types
←[1m
File "C:\Users\alpac\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\typed\listobject.py", line 599:←[0m
←[1m
←[1m    def impl(l, item):
←[0m    ←[1m^←[0m←[0m
←[0m←[0m
  l.append(item)
C:\Users\alpac\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\core\ir_utils.py:2152: NumbaPendingDeprecationWarning: ←[1m
Encountered the use of a type that is scheduled for deprecation: type 'reflected set' found for argument 'item' of function '_append'.

For more information visit https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-reflection-for-list-and-set-types
←[1m
File "C:\Users\alpac\AppData\Local\Programs\Python\Python310\lib\site-packages\numba\typed\typedlist.py", line 82:←[0m
←[1m@njit
←[1mdef _append(l, item):
←[0m←[1m^←[0m←[0m
←[0m
  warnings.warn(NumbaPendingDeprecationWarning(msg, loc=loc))
Created
```

It ends after the "Created" line with no error message or stacktrace, so I do not know what to make of this.
For context, I am trying to JIT compile a function that takes a set of ints, a list of sets of ints, and another set of ints, and reurns the union of the first provided set and all the sets in the list indexed by the members of the final argument. I would be calling this on many lists, so I want to be able to have a list of lists of sets, though only the list of sets would be passed to the JIT function.
user: cppietime
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_8155: state: open
title: CUDA: Provide more flexibility in the FP error model
body: As noted in https://github.com/numba/numba/pull/8137#issuecomment-1153207079, the error model for CUDA is NumPy when debugging is off, and Python when it is on.

It would be desirable to enable the error model to be controlled independently of whether debugging is enabled - some kernels might divide by zero and this not represent an error condition, so debugging them will be difficult. Additionally, one might want to use the Python error model without enabling debugging, in order to generally catch division-by-zero errors at runtime.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_8149: state: open
title: LLVM dump appears to be optimized when it shouldn't be
body: Originally posted at: https://numba.discourse.group/t/understanding-numba-optimization/1377

LLVM dumps seemed to go from being unoptimized to being optimized some time between Numba 0.53.1 and Numba 0.54.1. The following:

```python
from numba import njit

@njit
def add(a, b):
    return a + b

add(5, 10)
```

with Numba 0.53.1:

```
$ NUMBA_DUMP_LLVM=1 python repro.py 
--------------------LLVM DUMP <function descriptor 'add$1'>---------------------
; ModuleID = "add$1"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"

@"_ZN08NumbaEnv8__main__7add$241Exx" = common global i8* null
define i32 @"_ZN8__main__7add$241Exx"(i64* noalias nocapture %"retptr", {i8*, i32, i8*}** noalias nocapture %"excinfo", i64 %"arg.a", i64 %"arg.b") 
{
entry:
  %"a" = alloca i64
  store i64 0, i64* %"a"
  %"b" = alloca i64
  store i64 0, i64* %"b"
  %"$6binary_add.2" = alloca i64
  store i64 0, i64* %"$6binary_add.2"
  %"$8return_value.3" = alloca i64
  store i64 0, i64* %"$8return_value.3"
  br label %"B0"
B0:
  %".7" = load i64, i64* %"a"
  store i64 %"arg.a", i64* %"a"
  %".10" = load i64, i64* %"b"
  store i64 %"arg.b", i64* %"b"
  %".12" = load i64, i64* %"a"
  %".13" = load i64, i64* %"b"
  %".14" = add nsw i64 %".12", %".13"
  %".16" = load i64, i64* %"$6binary_add.2"
  store i64 %".14", i64* %"$6binary_add.2"
  %".18" = load i64, i64* %"b"
  store i64 0, i64* %"b"
  %".20" = load i64, i64* %"a"
  store i64 0, i64* %"a"
  %".22" = load i64, i64* %"$6binary_add.2"
  %".24" = load i64, i64* %"$8return_value.3"
  store i64 %".22", i64* %"$8return_value.3"
  %".26" = load i64, i64* %"$6binary_add.2"
  store i64 0, i64* %"$6binary_add.2"
  %".28" = load i64, i64* %"$8return_value.3"
  store i64 %".28", i64* %"retptr"
  ret i32 0
}
```

whereas with Numba 0.54.1:

```
$ NUMBA_DUMP_LLVM=1 python repro.py 
--------------------LLVM DUMP <function descriptor 'add$1'>---------------------
; ModuleID = "add$1"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"

@"_ZN08NumbaEnv8__main__7add$241Exx" = common global i8* null
define i32 @"_ZN8__main__7add$241Exx"(i64* noalias nocapture %"retptr", {i8*, i32, i8*}** noalias nocapture %"excinfo", i64 %"arg.a", i64 %"arg.b") 
{
entry:
  br label %"B0"
B0:
  %".6" = add nsw i64 %"arg.a", %"arg.b"
  store i64 %".6", i64* %"retptr"
  ret i32 0
}
```
user: gmarkall
labels: bug - documentation incorrect: documentation is incorrect or missing something important
issue_8143: state: open
title: Add fastmath support to cc.export
body: This PR implements the feature in numba/numba/issues/7179. 
user: andrijdavid
issue_8140: state: open
title: `replace_vars` to auto fixup scope
body: The same effect can be achieved by:

```suggestion
                # Also update the callee scope with the new names. Should the
                # type and call maps need updating (which requires SSA form) the
                # transformation to SSA is valid as the IR object is internally
                # consistent.
                # callee_scope.redefine(inlined_name, loc=var.loc)
                var_dict[var.name] = new_var
        self.debug_print("var_dict = ", var_dict)
        replace_vars(callee_blocks, var_dict)

        from numba.core.ir_utils import fixup_var_define_in_scope
        fixup_var_define_in_scope(callee_blocks)
```

Perhaps, `fixup_var_define_in_scope` should be part of `replace_vars`

_Originally posted by @sklam in https://github.com/numba/numba/pull/7823#discussion_r891768995_
user: sklam
labels: discussion: An issue requiring discussion
issue_8139: state: open
title: Stencil neighborhood option doesn't support numpy.integer
body: This PR fixes #6901. It adds a fix in `stencil.py` and a new test case for the stencil operator in `test_stencil.py`. 

user: andrijdavid
labels: Effort - medium: Medium size effort needed
issue_8138: state: open
title: Fix fp16 native cast for CUDA target
body: Support for fp16 is only implemented on the cuda target, but the following code 

```
from numba import njit
import numpy as np

@njit
def f(x):
    return float(x)

print(f(np.float16(2.3)))
```

generates a Typing error on the cpu target:

```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<class 'float'>) found for signature:
 
 >>> float(float16)
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'Float.generic': File: numba/core/typing/builtins.py: Line 968.
    With argument(s): '(float16)':
   Rejected as the implementation raised a specific error:
     NumbaTypeError: float() only support for numbers
  raised from /home/collison/Nvidia/testhound_numba_fork/numba/core/typing/builtins.py:974

During: resolving callee type: Function(<class 'float'>)
During: typing of call at test_cast2.py (7)


File "test_cast2.py", line 7:
def f(x):
    return float(x)
    ^
```

user: testhound
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_8135: state: open
title: Slow compilation of function taking numpy structured arrays with many fields
body: The compilation time of jited functions taking numpy structured is slow, and more less quadratic in the number of fields, resulting in very slow compile times for wide arrays (e.g. 8 seconds for 100 fields for a trivial function). 

I was only able to to test this on 0.55.1, and on linux only.

To reproduce, create a file callled numba_test.py:

```
from numba import njit, literal_unroll
import numpy as np
import sys

@njit
def dummy(arr):
    out = 0
    for f in literal_unroll(cols):
        out += arr[f]
    return out


n_col = int(sys.argv[1])
cols = tuple(f'col_{i}' for i in range(n_col))
dtype = np.dtype([(c, 'f4') for c in cols])

arr = np.zeros(5, dtype=dtype)
dummy(arr[0])
```

And in a terminal:
`for n in $(seq 1 10 150); do echo -n "$n, "; /usr/bin/time -f "%e" python numba_test.py $n; done`


Which gives (run time in seconds, as a function of the number of fields):
1, 0.73
11, 0.91
21, 1.13
31, 1.42
41, 1.80
51, 2.32
61, 3.08
71, 4.05
81, 5.19
91, 6.59
101, 8.56
111, 10.62
121, 12.83
131, 15.53
141, 19.04



user: MarcMassar
labels: performance - compile time: Performance issue occurring at compile time.
issue_8131: state: open
title: All slices of contiguous 2D+ arrays are assumed to be not contiguous (even when they would be)
body: This issue is a summary and a minimal-but-general example of 3 currently open issues:
- 2020, higher-dimensional: https://github.com/numba/numba/issues/5124
- Late 2020, C-contiguity & ellipsis workaround: https://github.com/numba/numba/issues/6481
- 2022, F-contiguity: https://github.com/numba/numba/issues/7840

Premise:
---------
If an array is C or F contiguous, slicing along its contiguity axis preserves contiguity:

```Python
import numpy as np
from numba import njit, typeof, f8

example_c_array = np.array(range(100), dtype = np.float_).reshape(10, 10)
print(typeof(example_c_array)) # C
print(typeof(example_c_array[:, :])) # Retains C
print(typeof(example_c_array[3:7, :])) # Retains C
print(typeof(example_c_array[:, 3:7])) # A
print(typeof(example_c_array[3:7, 3:7])) # A

print()

example_f_array = np.asfortranarray(example_c_array)
print(typeof(example_f_array)) # F
print(typeof(example_f_array[:, :])) # Retains F
print(typeof(example_f_array[3:7, :])) # A
print(typeof(example_f_array[:, 3:7])) # Retains F
print(typeof(example_f_array[3:7, 3:7])) # A
```

Behaviour:
---------
Even when contiguity is known (by explicit typing), compilation assumes that any slicing results in non-contiguity, leading to type mismatch (and slower performance if complying).
Using an ellipsis for single-axis slicing as a workaround (https://github.com/numba/numba/issues/6481#issuecomment-729252931) is also shown below.

2D C-contiguity examples:
```Python
# Known-signature function
@njit(f8(f8[:, ::1]))
def takes_c_contiguous_2d_slice(c_slice): return 1

# Examples
@njit(f8(f8[:, ::1]))
def feeds_c_full(c_array): return takes_c_contiguous_2d_slice(c_array) # Fine
@njit(f8(f8[:, ::1]))
def feeds_c_2d_full_slice(c_array): return takes_c_contiguous_2d_slice(c_array[:, :]) # Should be C, gets A
@njit(f8(f8[:, ::1]))
def feeds_c_2d_slice(c_array): return takes_c_contiguous_2d_slice(c_array[3:5, :]) # Should be C, gets A

# A workaround
@njit(f8(f8[:, ::1]))
def feeds_c_2d_slice_ELLIPSIS(c_array): return takes_c_contiguous_2d_slice(c_array[3:5, ...]) # Fixed for this case
```

2D F-contiguity examples:
```Python
# Known-signature function
@njit(f8(f8[::1, :]))
def takes_f_contiguous_2d_slice(f_slice): return 1

# Examples
@njit(f8(f8[::1, :]))
def feeds_f_full(f_array): return takes_f_contiguous_2d_slice(f_array) # Fine
@njit(f8(f8[::1, :]))
def feeds_f_2d_full_slice(f_array): return takes_f_contiguous_2d_slice(f_array[:, :]) # Should be F, gets A
@njit(f8(f8[::1, :]))
def feeds_f_2d_slice(f_array): return takes_f_contiguous_2d_slice(f_array[:, 3:5]) # Should be F, gets A

# A workaround
@njit(f8(f8[::1, :]))
def feeds_f_2d_slice_ELLIPSIS(f_array): return takes_f_contiguous_2d_slice(f_array[..., 3:5]) # Fixed for this case
```
user: T-Flet
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_8128: state: open
title: `typed.List` is not considered a `types.Sequence` while a reflected list is
body: As title, a `typed.List` is not considered a `types.Sequence` while a reflected list is. Might lead to problems if we shift from reflected to typed lists down the line. 
user: kc611
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_8119: state: open
title: np allocators need to either handle raw python types as dtypes or fail more clearly
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit
import numpy as np

@njit
def foo():
    np.empty(4, dtype=int)

foo()
```
is entirely legal in NumPy, but in Numba raises a generic `TypingError` about there being no matching template. The issue is that the `dtype` is set as a Python `int` which gets interpreted as a `Function(<class 'int'>)` i.e. the `int` class ctor. This is reflected in the error message:
```python
No implementation of function Function(<built-in function empty>) found for signature:
 
 >>> empty(Literal[int](4), dtype=Function(<class 'int'>))
 ```
Options:
1. Catch this case as it's probably relatively common and report in the error message how the user can change their code to get it to work.
2. Actually fix it in Numba, probably just spot the e.g. `Function(<class 'int'>)` and translate to a suitable type, e.g. `types.intp`.

Depends on: https://github.com/numba/numba/pull/7999
user: stuartarchibald
issue_8108: state: open
title: *args Issue Tracking Megathread
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Issue Tracking
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

As discussed in the May 10th Numba developer meeting, this is an issue meant to track the various *args issues that have been reported inside Numba. I determined these by searching `*args` and `star` in the issues, so there may be some I have missed.

### njit

- [ ] #8059: Segfault with objmode
- [ ] #6894: Support *args in closures
- [ ] #2770: Unpack list to *args not supported
- [ ] #5304: Tuple unpacking + keyword arguments not supported

### overload

- [ ] #7933: Check if *args is empty inside an overload
- [ ] #5291: Tuple unpacking + keyword arguments not supported in overloads

### cuda

- [ ] #6891: `*args` treated as a normal argument in CUDA


### vectorize

- [ ] #6954: Support for *args

### type_callable

- [ ] #7973: Support for *args
user: njriasan
labels: discussion: An issue requiring discussion
issue_8092: state: open
title: BUG: Memory leak due to new reference is not decreased on failure (static analyzer reports)
body: New reference is returned here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L284
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L293
Internal Report ID: b8bc21


---
New reference is returned here: 
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L300
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L307
Internal Report ID: ade41c


---
New reference is returned here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L323 
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L328
Internal Report ID: acbd1a


---
New reference is returned here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L345
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L348
Where the return statement in macro `TRY` is here.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L197
Internal Report ID: 92e957

---
New reference is returned here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L734
Function returns without decreasing the refcnt. 
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_typeof.c#L737
Internal Report ID: 5c0301

user: Snape3058
labels: good second issue: A good issue for second time contributors
bug - memory leak: Memory leak
issue_8091: state: open
title: BUG: Memory leak when the module created by `MOD_DEF` is not decreased on failure (static analyzer report)
body: Macro `MOD_DEF` will create a module PyObject with a new reference returned and assigned to the first argument.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_pymodule.h#L16

The following places invoke the macro but do not decrease the refcnt of the module PyObject on failure.

--- 
Invoked here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_dispatcher.cpp#L1211
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_dispatcher.cpp#L1217
Internal Report ID: 0dc3d1


---
Invoked here: 
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_dynfuncmod.c#L66
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_dynfuncmod.c#L71
Internal Report ID: 235f50


---
Invoked here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_helpermod.c#L288
Function returns in macro `import_array` without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_helpermod.c#L292
Internal Report ID: f3d5d2


---
Invoked here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/core/runtime/_nrt_pythonmod.c#L193
Function returns in macro `import_array` without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/core/runtime/_nrt_pythonmod.c#L196
Internal Report ID: 724a48


---
Invoked here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/experimental/jitclass/_box.c#L156
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/experimental/jitclass/_box.c#L162
Internal Report ID: 31f898


---
Invoked here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/mviewbuf.c#L356
Function returns without decreasing the refcnt. 
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/mviewbuf.c#L362
Internal Report ID: f68b83


---
Invoked here:
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/np/ufunc/_internal.c#L762
Function returns without decreasing the refcnt.
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/np/ufunc/_internal.c#L769
Internal Report ID: ed7b7c

user: Snape3058
labels: bug - memory leak: Memory leak
issue_8090: state: open
title: BUG: Memory leak when `PyModule_AddObject` fails (static analyzer report)
body: API function `PyModule_AddObject` will only steal the third argument when the return value is zero.
If the return value is not checked, it will lead to a memory-leak bug when the function fails.
Consider using [`PyModule_AddObjectRef`](https://docs.python.org/3/c-api/module.html#c.PyModule_AddObjectRef) instead, which never steals a reference.

The following PyObjects will get leaked if the return value of `PyModule_AddObject` is not zero.

https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_dynfuncmod.c#L73
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/_dynfuncmod.c#L90
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/cuda/cudadrv/_extras.c#L41
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/cuda/cudadrv/_extras.c#L42
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/experimental/jitclass/_box.c#L174
https://github.com/numba/numba/blob/468647dddde27ee8af124c97dfcd20c35c4a2bc6/numba/experimental/jitclass/_box.c#L176

Internal Report IDs: c33201 66bdf9 02b47d e871fc 7e4a97 fe73cf
user: Snape3058
labels: bug - memory leak: Memory leak
issue_8085: state: open
title: `cache=True` slow for `parallel` target
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I am using `cache=True` to reuse compiled functions. However, for `target=parallel` it takes two seconds to get the cached function, which should instead be very fast.
I have submitted an example file for testing that. The output of one run in my machine (after a first round to compile and cache the results) is:
```
time1=1653049905.1918075
time2=1653049905.251374
time3=1653049907.4025178
time2 - time1=0.059566497802734375
time3 - time2=2.151143789291382
```

`time2 - time1` is the time it takes to get the cached CPU version, which is very fast.
`time3 - time2` is the time it takes to get the parallel version, which is VEEEERY slow.

In practice this is done at import time, which slows considerably the import time for my library and its dependants (2 seconds extra are VERY noticeable in REPL).

[bug.zip](https://github.com/numba/numba/files/8740161/bug.zip)


user: vnmabus
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
performance - run time: Performance issue occurring at run time.
issue_8062: state: open
title: Jit functions with optional shape arguments for creating numpy arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I am implementing a jitted functions with optional shape arguments for creating numpy arrays, when the optional arguments are used to create a numpy array in the shape argument as a tuple, a `TypingError` occurs:

```python
import numba
import numpy as np

@numba.njit
def create_1D_numpy_array_with_tuple_shape(size: int = None):
    if size is None:
        size = 3
    array = np.zeros((size, ))
    print(array)

create_1D_numpy_array_with_tuple_shape()  # Fails
```

But when I create a 1D array and provide an int value to the shape argument, it is fine:

```python
import numba
import numpy as np

@numba.njit
def create_1D_numpy_array_with_int_shape(size: int = None):
    if size is None:
        size = 3
    array = np.zeros(size)
    print(array)

create_1D_numpy_array_with_int_shape()  # Passes
```

When I assign the argument to a temporary variable, it is also fine:

```python
import numba
import numpy as np

@numba.njit
def create_1D_numpy_array_with_temp_tuple_shape(size: int = None):
    temp_size = size if size is not None else 3
    array = np.zeros((temp_size, ))
    print(array)

create_1D_numpy_array_with_temp_tuple_shape()  # Passes
```

The error message for the above example is:

```python
Traceback (most recent call last):
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python39\lib\site-packages\IPython\core\interactiveshell.py", line 3397, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-6-0c27157a3534>", line 1, in <cell line: 1>
    create_1D_numpy_array_with_tuple_shape()
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python39\lib\site-packages\numba\core\dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\Hailin\AppData\Local\Programs\Python\Python39\lib\site-packages\numba\core\dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function zeros>) found for signature:
 
 >>> zeros(UniTuple(OptionalType(int64) x 1))
 
There are 4 candidate implementations:
  - Of which 4 did not match due to:
  Overload in function '_OverloadWrapper._build.<locals>.ol_generated': File: numba\core\overload_glue.py: Line 131.
    With argument(s): '(UniTuple(OptionalType(int64) x 1))':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<intrinsic stub>) found for signature:
    
    >>> stub(UniTuple(OptionalType(int64) x 1))
    
   There are 2 candidate implementations:
     - Of which 2 did not match due to:
     Intrinsic of function 'stub': File: numba\core\overload_glue.py: Line 35.
       With argument(s): '(UniTuple(OptionalType(int64) x 1))':
      No match.
   
   During: resolving callee type: Function(<intrinsic stub>)
   During: typing of call at <string> (3)
   
   
   File "<string>", line 3:
   <source missing, REPL/exec in use?>
  raised from C:\Users\Hailin\AppData\Local\Programs\Python\Python39\lib\site-packages\numba\core\typeinfer.py:1086
During: resolving callee type: Function(<built-in function zeros>)
During: typing of call at <ipython-input-5-b6f5eb4992d3> (5)
File "<ipython-input-5-b6f5eb4992d3>", line 5:
def create_1D_numpy_array_with_tuple_shape(size: int = None):
    <source elided>
        size = 3
    array = np.zeros((size, ))  # or array = np.zeros((rows, cols)), also fails
    ^
```

user: haiiliin
labels: bug - typing: Bugs: occuring at typing time
issue_8060: state: open
title: Support issuing warnings in nopython mode
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

It would be occasionally useful to be able to issue a `warning` from `nopython` mode code. Not sure how best to implement this as yet, warnings might need to be buffered so as to not interrupt execution, or the GIL acquisition will have to be accepted as a trade off, it might get tricky RE filtering too.

xref: https://github.com/numba/numba/pull/8027#pullrequestreview-974633141.
user: stuartarchibald
issue_8055: state: open
title: much slower for 3d tensor
body: ```
@jit(nopython=True)
def HeadSum_jit(m,d):
	return np.sum(m[:d],axis=0)

@jit(nopython=True)
def HeadSum_for(tensor1,d):
	'''
	tensor1: TrDateNum * 240 * stockNum. such as open/high/low/close/vol/amt/turnover. No Nan in tensor1!!!
	d: countInt
	return np.sum(tensor1[:d],axis=0) 
	'''
	n1,n2,n3 = tensor1.shape[0],tensor1.shape[1],tensor1.shape[2]
	resMat = np.zeros((n1,n3),dtype=np.float32)
	for i in range(n1):
		resMat[i] = HeadSum_jit(tensor1[i],d)

	return resMat

@jit(nopython=True)
def HeadSumTensor_jit(tensor1,d):
	return np.sum(tensor1[:,:d,:],axis=1)
```


```
closeTensor = np.random.randn(120,240,4000).astype(np.float32)
%timeit HeadSumTensor_jit(closeTensor,100)
44.7 ms ± 950 µs

%timeit HeadSumTensor_jit.py_func(closeTensor,100)
12.1 ms ± 65.8 µs

%timeit HeadSum_for(closeTensor,100)
10.6 ms ± 144 µs

numba: '0.54.1'
python: '3.9.7'
```


user: AIQuantRobot
labels: performance - run time: Performance issue occurring at run time.
issue_8047: state: open
title: Overload not properly producing omitted types
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

It seems like the compilation path for overloads doesn't properly do argument folding and therefore doesn't produce omitted types. Here is a reproducer:

```python
from numba.extending import overload
from numba import njit

def foo(a, b=1):
	pass

@overload(foo)
def foo_overload(a, b=1):
	print(a, b)
	def foo_impl(a, b=1):
		return a + b
        return foo_impl


@njit
def g(a):
	return foo(a)

g(100)
```
On master this outputs:

```python
int64 1
```

So b is a python literal 1, not an omitted type.


user: njriasan
labels: bug - typing: Bugs: occuring at typing time
issue_8039: state: open
title: np.random.randint with size
body: ## Feature request

I would like to be able to use something like `np.random.randint(..., size=(..., ...))` to create a **matrix**.

user: feluelle
issue_8036: state: open
title: `raise` and `assert` do not work correctly  in CUDA device functions
body: The following:

```python
from numba import cuda

@cuda.jit(device=True)
def f():
    raise ValueError('Error')

@cuda.jit(debug=True, opt=False)
def kernel():
    f()

kernel[1, 1]()
```

results in an error like:

```
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/dispatcher-refactor/raise_in_devfunc.py", line 14, in <module>
    kernel[1, 1]()
  File "/home/gmarkall/mambaforge/envs/numba0531/lib/python3.9/site-packages/numba/cuda/compiler.py", line 821, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
  File "/home/gmarkall/mambaforge/envs/numba0531/lib/python3.9/site-packages/numba/cuda/compiler.py", line 966, in call
    kernel.launch(args, griddim, blockdim, stream, sharedmem)
  File "/home/gmarkall/mambaforge/envs/numba0531/lib/python3.9/site-packages/numba/cuda/compiler.py", line 716, in launch
    exccls, exc_args, loc = self.call_helper.get_exception(code)
ValueError: not enough values to unpack (expected 3, got 2)
```

If I fix the `MinimalCallHelper` so that reporting the error works correctly (`get_exception()` should return three things, not two):

```diff
diff --git a/numba/core/callconv.py b/numba/core/callconv.py
index b3fa6cbbd..e99494524 100644
--- a/numba/core/callconv.py
+++ b/numba/core/callconv.py
@@ -315,7 +315,10 @@ class _MinimalCallHelper(object):
             return self.exceptions[exc_id]
         except KeyError:
             msg = "unknown error %d in native function" % exc_id
-            return SystemError, (msg,)
+            exc = SystemError
+            exc_args = (msg,)
+            locinfo = None
+            return exc, exc_args, locinfo
 
 # The structure type constructed by PythonAPI.serialize_uncached()
 # i.e a {i8* pickle_buf, i32 pickle_bufsz, i8* hash_buf}
```

then the exception becomes:

```
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/dispatcher-refactor/raise_in_devfunc.py", line 14, in <module>
    kernel[1, 1]()
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 473, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 581, in call
    kernel.launch(args, griddim, blockdim, stream, sharedmem)
  File "/home/gmarkall/numbadev/numba/numba/cuda/dispatcher.py", line 306, in launch
    raise exccls(*exc_args)
SystemError: tid=[0, 0, 0] ctaid=[0, 0, 0]: unknown error 1 in native function
```

Thoughts:

* It seems that two `MinimalCallConv` objects, and therefore two `_MinimalCallHelper` objects get created during compilation.
* The details of the exception get added to one of these (through `return_user_exc()` / `_add_exception()`), but when it's time to look up the exception (through `get_exception()`), the other one is used.
* `BaseCallConv.init_call_helper()`, which calls `self._make_call_helper()` to make the call helper, stashes the call helper it gets on the builder object: https://github.com/numba/numba/blob/0f5953df2a2ee6eea1ac44b974bcd954aae91bc6/numba/core/callconv.py#L105-L114
* It looks like the idea here is to somehow memoize the call helper on the builder so that it can be reused across multiple call conv objects (for example so that they can all have a common dict of exception info in the call helper) but as far as I can see the two call convs have two separate builders, so the isn't the possibility of sharing anyway.
* The next point of investigation is to see how the CPU target handles this case (one njit function calling another that raises an exception) - how does it ensure consistency of information about exceptions between the two functions?

I can relatively easily go back as far as Numba 0.48, in which this also didn't work - I get the impression that this has never worked.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_8034: state: open
title: Feature request: support for `numba._DUFunc` in `@overload`
body: ## Feature request
As title. 
Here's an example:
```python
import numba
import numpy as np
from numba import njit, vectorize
from numba.extending import overload

@vectorize(["float64(float64)"])
def vf_eager(a):
    return a + 1


def vf(a):
    return a + 1


@overload(vf)
def vf_overload(a):
    return vf_eager


@njit
def f(a):
    return vf(a)


arr = np.arange(10.0)

f(arr)
```

```
Traceback (most recent call last):
  File "/home/auderson/miniconda3/envs/py3.9/lib/python3.9/site-packages/IPython/core/interactiveshell.py", line 3361, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-2-f09a2fd81d0d>", line 27, in <cell line: 27>
    f(arr)
  File "/home/auderson/miniconda3/envs/py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/auderson/miniconda3/envs/py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function vf at 0x7ff5842c1280>) found for signature:
 
 >>> vf(array(float64, 1d, C))
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'vf_overload': File: ../../../../../../<ipython-input-2-f09a2fd81d0d>: Line 15.
    With argument(s): '(array(float64, 1d, C))':
   Rejected as the implementation raised a specific error:
     AssertionError: Implementator function returned by `@overload` has an unexpected type.  Got <numba._DUFunc 'vf_eager'>
  raised from /home/auderson/miniconda3/envs/py3.9/lib/python3.9/site-packages/numba/core/typing/templates.py:814
During: resolving callee type: Function(<function vf at 0x7ff5842c1280>)
During: typing of call at <ipython-input-2-f09a2fd81d0d> (22)
File "<ipython-input-2-f09a2fd81d0d>", line 22:
def f(a):
    return vf(a)
    ^

```

user: auderson
issue_8026: state: open
title: When dict value_type is namedtuple, cannot set item for the dict
body: tested on master:
```
from collections import namedtuple

from numba import njit
from numba.core import types
from numba.typed.typeddict import Dict

def test_misc():
    @njit
    def use_tuple_dict(d):
        return d

    Node = namedtuple("Node", ["ID", "Name"])
    node1 = Node("1", "abc")
    dct = Dict.empty(
        key_type  =types.unicode_type, 
        value_type=types.NamedTuple(
            (types.unicode_type, types.unicode_type), 
            Node)
    )
    dct["1"] = node1
    pv = use_tuple_dict.py_func(dct)
    jv = use_tuple_dict(dct)
    assert pv == jv
```
And an Error was reported. (If we change `Node("1", ...)` to `Node(1, ...)`, and the first item to types.int64. This error will not be reported.)
```
Traceback (most recent call last):
  File "/Users/ld/Code/numba/numba/tests/test_unicode_array.py", line 919, in test_misc4
    dct["1"] = node1
  File "/Users/ld/Code/numba/numba/typed/typeddict.py", line 155, in __setitem__
    return _setitem(self, key, value)
  File "/Users/ld/Code/numba/numba/core/dispatcher.py", line 468, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/Users/ld/Code/numba/numba/core/dispatcher.py", line 409, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function setitem>) found for signature:
 
 >>> setitem(DictType[unicode_type,Node(unicode_type, unicode_type)]<iv=None>, unicode_type, Node(unicode_type x 2))
 
There are 16 candidate implementations:
  - Of which 14 did not match due to:
  Overload of function 'setitem': File: <numerous>: Line N/A.
    With argument(s): '(DictType[unicode_type,Node(unicode_type, unicode_type)]<iv=None>, unicode_type, Node(unicode_type x 2))':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'impl_setitem': File: numba/typed/dictobject.py: Line 695.
    With argument(s): '(DictType[unicode_type,Node(unicode_type, unicode_type)]<iv=None>, unicode_type, Node(unicode_type x 2))':
   Rejected as the implementation raised a specific error:
     LoweringError: Failed in nopython mode pipeline (step: native lowering)
   
   
   File "../typed/dictobject.py", line 705:
       def impl(d, key, value):
           <source elided>
           castedkey = _cast(key, keyty)
           castedval = _cast(value, valty)
           ^
   
   During: lowering "castedval = call $12load_global.4(value, $16load_deref.6, func=$12load_global.4, args=[Var(value, dictobject.py:704), Var($16load_deref.6, dictobject.py:705)], kws=(), vararg=None, target=None)" at /Users/ld/Code/numba/numba/typed/dictobject.py (705)
  raised from /Users/ld/Code/numba/numba/core/errors.py:837

During: typing of setitem at /Users/ld/Code/numba/numba/typed/typeddict.py (33)

File "../typed/typeddict.py", line 33:
def _setitem(d, key, value):
    d[key] = value
    ^

```
Actually, I met the same error problem when I use a dict(unicode, list(unicode)). I can create successfully using `Dict.empty(...)` using numba types. But when set item for this dict, the same error happened. Numba doc said TypedDict doesn't support value type as list. So I think this is just my misuse.
cc @luk-f-a 
user: dlee992
labels: bug - typing: Bugs: occuring at typing time
issue_8023: state: open
title: Incorrect docstring for TypeRefAttribute
body: https://github.com/numba/numba/blob/bd1e11a9341e0cb507f876bb49fb37878af25eb5/numba/core/typing/builtins.py#L844-L845
user: sklam
labels: bug - documentation incorrect: documentation is incorrect or missing something important
issue_8021: state: open
title: Infer and propagate constant information earlier in the pipeline.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I'm wondering if code like this could potentially be handled directly by Numba. The following fails at present as it can't unify `agg` in the `agg.shape` call. If the following sequence of passes were run:

* PartialTypeInference (`aggs_and_cols[0]` inferred as 3d)
* RewriteSemanticConstants (`aggs_and_cols[0].ndim` baked into IR as `const(3)`? maybe needs some work on the pass)
* DeadBranchPrune (Remove branching as `3 == 3` is always True)

it might allow elimination of the control flow and permit compilation.

```python
from numba import njit
import numpy as np

@njit
def foo(*aggs_and_cols):
    i = 0
    agg = aggs_and_cols[0] # This agg is 3D
    if aggs_and_cols[0].ndim == 3: # This type could be inferred, semantic rewritten and branch pruned.
        cat_index = aggs_and_cols[1][i]
        agg = agg[:, :, cat_index] # This agg is 2D

    xmax = agg.shape[1] - 1 # What's this agg? 2D or 3D?

args = (np.zeros((3, 4, 5)), (0, 0))

foo(*args)
```
user: stuartarchibald
issue_8018: state: open
title: numba vectorize does not short circuit as expected
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug
I'm trying to write a compiled divide function that will broadcast, to divide a vector by its magnitude, but return zero when dividing by zero  (`zero_divide` below).  However, I want to also use it in other situations when I might not have numpy installed.  The numba vectorize function is perfect for this, but it is not skipping the divide by zero part.

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
## Minimal Example
```
import numpy as np
from numba import float32, float64, int32, int64, vectorize

@vectorize([float32(int32, int32), float64(int64, int64), float32(float32, float32), float64(float64, float64)], nopython=True)
def zero_divide(num, den):
    if den == 0.0:
        return 0.0
    return num / den

if __name__ == '__main__':
    np.seterr(invalid="raise", divide="raise")

    vec = np.array([[1.0, 0.0, 0.0], [3.0, 4.0, 0.0], [0.0, 0.0, 0.0]]).T
    mag = np.array([1.0, 5.0, 0.0])
    exp = np.array([[1.0, 0.0, 0.0], [0.6, 0.8, 0.0], [0.0, 0.0, 0.0]]).T

    out = zero_divide(vec, mag)  # This line raises a FloatingPointError when the divide by zero should not happen
    np.testing.assert_array_equal(out, exp)
```

## Other options with expected behavior

```
import numpy as np

@np.vectorize
def zero_divide1(num, den):
    """numpy vectorize version."""
    if den == 0.0:
        return 0.0
    return num / den

def zero_divide2(num, den):
    """Alternate version with numpy broadcasting, but no numba JIT."""
    b = np.broadcast(num, den)
    out = np.zeros(b.shape)
    for i, (n, d) in enumerate(b):
        if d != 0.0:
            out.flat[i] = n / d
    return out

def zero_divide3(num, den):
    """Probably best numpy one-line solution, but would prefer to have numba solution."""
    return np.divide(num, den, out=np.zeros(num.shape), where=den!=0.0)

if __name__ == '__main__':
    np.seterr(invalid="raise", divide="raise")

    vec = np.array([[1.0, 0.0, 0.0], [3.0, 4.0, 0.0], [0.0, 0.0, 0.0]]).T
    mag = np.array([1.0, 5.0, 0.0])
    exp = np.array([[1.0, 0.0, 0.0], [0.6, 0.8, 0.0], [0.0, 0.0, 0.0]]).T

    out1 = zero_divide1(vec, mag)
    np.testing.assert_array_equal(out1, exp)

    out2 = zero_divide2(vec, mag)
    np.testing.assert_array_equal(out2, exp)

    out3 = zero_divide3(vec, mag)
    np.testing.assert_array_equal(out3, exp)
```
user: DStauffman
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_8013: state: open
title: cc.distutils_extension() does not work in project with nested structure
body: I believe there is a bug when using cc.distutils_extension() in a project with a nested structure.

1) Project setup
```
-project_name
  -src
    -my_module
      -__init__.py
      -code2compile.py
  -setup.py
  -pyproject.toml
  -setup.cfg
  -requirements.txt
```

2) Sample code

setup.py:
```
import os
import sys
if os.getcwd() not in sys.path:
    sys.path.append(os.getcwd())
from src.my_module.code2compile import cc
from setuptools import setup
if __name__ == "__main__":
    setup(ext_modules=[cc.distutils_extension()])
```

code2compile.py:
```
from numba.pycc import CC
cc = CC("my_compiled_code")
@cc.export("f8", "f8(f8)")
@cc.export("f4", "f4(f4)")
def f(a):
    return a + 1.0
```

pyproject.toml:
```
[build-system]
requires = ["setuptools>=42.0", "wheel", "numba>=0.55"]
build-backend = "setuptools.build_meta"
```

setup.cfg:
```
[metadata]
name = my_module
platforms = win32
classifiers =
    Programming Language :: Python :: 3
    Programming Language :: Python :: 3.9
    Programming Language :: Python :: 3 :: Only
[options]
packages=
    my_module
install_requires=
    numba>=0.55
    numpy>=1.20
    scipy>=0.16
python_requires = >=3.9
package_dir =
    =src
zip_safe = no

```

requirements.txt:
```
numba>=0.55
numpy>=1.20
scipy>=0.16
```

3) Error on project installation

When installing the package via `pip install -e .` the following error is produced:
> copying build\lib.win-amd64-cpython-39\src\my_module\my_compiled_code.cp39-win_amd64.pyd -> src\src\my_module
    error: could not create 'src\src\my_module\my_compiled_code.cp39-win_amd64.pyd': No such file or directory

4) How I fixed the bug

new code2compile.py:
```
import numpy as np
from numba.pycc import CC
cc = CC("my_compiled_code")
cc._source_module = "my_module.my_compiled_code"  # src removed from self._source_module
@cc.export("f8", "f8(f8)")
@cc.export("f4", "f4(f4)")
def f(a):
    return a + 1.0
```

I believe the error is with [this line](https://github.com/numba/numba/blob/e5bbae7de22fa8c0b23dcfc8c9a946e5d37ee509/numba/pycc/cc.py#L248) in [numba/numba/pycc/cc.py](https://github.com/numba/numba/tree/e5bbae7de22fa8c0b23dcfc8c9a946e5d37ee509): `python_package_path = self._source_module[:self._source_module.rfind('.')+1]`.

During initialisation of the CC() class in code2compile.py `cc._source_module` is `src.my_module.code2compile`. If  `cc._source_module` is replaced with `my_module.code2compile` the copy error is not produced and the `pip install -e .` is successful.


5) Recommendation on fix

Seems like when working on a project with a nested structure the [line](https://github.com/numba/numba/blob/e5bbae7de22fa8c0b23dcfc8c9a946e5d37ee509/numba/pycc/cc.py#L248) that defines `python_package_path` is not working as it should (i.e. is not getting the my_module directory). I recommend replacing it with:
`python_package_path = ''.join((self._source_module.split('.')[-2], '.'))` to allow for projects with nested structures, which would produce the correct result for `python_package_path` of "my_module." when calling cc.distutils_extension().
user: Stoops-ML
labels: AOT: ahead of time compilation issue
issue_8008: state: open
title: meta-issue: Numba/NumPy interation+collaboration+discussion!
body: Following on from some recent OOB discussions, this is a meta-issue to track ways in which the Numba and NumPy projects could cooperate over common interaction points. The items presented herein are with the sole purpose of attempting to highlight areas to promote discussion and collaboration. Some of the following is also likely to apply to other packages that have similar requirements to Numba (i.e. type stability). Please feel free to comment and/or add more items.

CC @rgommers @seibert 

## Type stability challenges in the NumPy APIs.

Background: Numba uses type inference to compute the type of all variables in user code. This is performed by combining the type information from the arguments to the user function with a lot of rules defined in Numba about what the types of the variables returned by operations and functions for given input types will be. Note that type inference is performed at compile time and depends solely on the types of the arguments involved and not on their values.

The following contains specific examples of the kinds of problems a type inferring compiler may run into when attempting to replicate the NumPy API. The NumPy API has obviously grown and evolved over the years, it makes a lot of use of Python's dynamic nature, and predates e.g. Numba by a long way, so it is entirely understandable that these challenges exist. What will be interesting is working out if they can be overcome via e.g. more advanced type systems or type stable API updates.

### Functions which change their output type depending on value.

Example::

```pycon
In [12]: np.linalg.eigvals([[1, 1], [1, 1]])
Out[12]: array([2., 0.])

In [13]: np.linalg.eigvals([[1, 1],[-1, 1]])
Out[13]: array([1.+1.j, 1.-1.j])
```
this example is at one extreme of the issue in that there's a numerical reason for such a behaviour, however it demonstrates that some functions change their return type (`float64` vs. `complex128` array type) depending on run time value. Another such example is `np.cross`, which is discussed here https://github.com/numba/numba/pull/4128#issuecomment-498324729, where there is a return type specialisation depending on the runtime value of an index of an array `shape`.

### Functions which change their output type depending on values of "flags".

Example::


```pycon
In [18]: np.unique([1, 2, 1], return_index=False)
Out[18]: array([1, 2])

In [19]: np.unique([1, 2, 1], return_index=True)
Out[19]: (array([1, 2]), array([0, 1]))
```

The problem here is that unless the `return_index` flag is provided as a compile time constant value (literally True/False in the user code), it's impossible to determine the return type at compile time.

### Functions that return mutable heterogeneous containers (e.g. lists) when their size is bounded.

Example::

```
In [21]: np.broadcast_arrays(np.ones(2), 3)
Out[21]: [array([1., 1.]), array([3, 3])]

In [22]: np.broadcast_arrays(np.ones(2), 3, 2)
Out[22]: [array([1., 1.]), array([3, 3]), array([2, 2])]
```

The size of the output container is a predicable function of the number of arguments. In a type system such as Numba's there is no support for heterogeneously typed mutable containers, however there is support for heterogeneously typed immutable containers. Given the above is predicable, could the return type reasonably be a tuple?


### Functions implementations that do not match docstrings.

Example::

```
In [38]: print('\n'.join(np.broadcast_shapes.__doc__.splitlines()[:11]))

    Broadcast the input shapes into a single shape.

    :ref:`Learn more about broadcasting here <basics.broadcasting>`.

    .. versionadded:: 1.20.0

    Parameters
    ----------
    `*args` : tuples of ints, or ints
        The shapes to be broadcast against each other.

In [39]: np.broadcast_shapes([12,], (12,))
Out[39]: (12,)
```

Whilst not directly type stability... the issue is that Numba contributors end up having to "reverse" what is going on to work out what is accepted as input. It makes the support experience in Numba a little inconsistent depending on what was implemented and worked out at the time. There are also occasions where what is accepted changes between NumPy versions.

## Some more general mismatches between NumPy and Numba.

There are a few areas where NumPy and Numba differ where they perhaps should not and it'd be good to discuss how to minimise the existing differences and make future ones smaller!

### Naming of arguments to functions is sometimes inconsistent.

Example:

```pycon
In [48]: np.linalg.matrix_power
Out[48]: <function numpy.linalg.matrix_power(a, n)>

In [49]: np.linalg.matrix_rank
Out[49]: <function numpy.linalg.matrix_rank(M, tol=None, hermitian=False)>
```
these two functions are in the same module and both take a matrix or stack of matrices as the first argument. However one implementation uses `a` as the argument name and the other `M`. This doesn't matter hugely but does present a bit of a general inconsistency. This impacts Numba users now and again when they write code which binds to variable names at the call site, if Numba hasn't used the same names as NumPy then the code won't compile. Numba really ought to fix this in its code base, but it might be something NumPy should consider too?

e.g.

```pycon
In [52]: from numba import njit

In [53]: @njit
    ...: def foo(x):
    ...:     np.linalg.matrix_rank(M=x)
    ...:

In [54]: try:
    ...:     foo(np.ones((2, 2)))
    ...: except Exception as e:
    ...:     print(e)
    ...:
Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function matrix_rank at 0x7ffa1b198430>) found for signature:

 >>> matrix_rank(M=array(float64, 2d, C))

There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'matrix_rank_impl': File: numba/np/linalg.py: Line 2419.
    With argument(s): '(M=array(float64, 2d, C))':
   Rejected as the implementation raised a specific error:
     TypingError: missing a required argument: 'a'
```
Numba erroneously uses `a` as its argument name, NumPy uses `M`.

### Mismatch in the use of BLAS/LAPACK precision.

The majority of the NumPy linalg routines all upcast `float32` and `complex64` types to their 64 bit equivalents and then do the work at this precision before casting the answer back to the input type. This creates problems for Numba in that Numba type specialises the BLAS/LAPACK calls based on the input types, which results in a mismatch compared to NumPy's result. This is also why Numba has better performance NumPy in this area when it probably should not. It also causes a degree of issue in Numba's test suite in that the amount that the results differ is sufficiently large to have to write specialised reconstruction routines to check results (opposed to the more usual `np.testing.assert_allclose` equivalent).

### Inf/NaN handling challenges.

Numba has to reimplement NumPy functionality using a what-Numba-supports subset of what is available in NumPy. As a result translating algorithms can be challenging, particularly with regards to Inf/NaN production as it is not always clear whether such an output was intentional or a side effect of the implementation. This often appears as an issue in the case of supporting a new version of NumPy in which some algorithm has changed and Inf/NaN production has changed as a result. An example might be the NumPy 1.19 upgrade https://github.com/numba/numba/pull/7019 where `np.percentile` and `np.quantile` changed production of inf/nan (and also dropped boolean support!). It might be beneficial to specify the expected Inf/NaN handling behaviour of functions cf. standards such as C99 or POSIX.

## Other areas of interaction.

### Exposing NumPy's internals as ctypes pointers.

Relatively recently NumPy added `BitGenerator`/`Generator` to the `np.random` module. Part of the implementation involved exposing the underlying C routines, that produce the bit streams and the "next" random number of a given type, via ctypes/CFFI. This is very useful on two fronts in
terms of Numba providing support for the same:
1. It means that Numba doesn't have to literally copy/replicate the entire C implementation in its code base.
2. It means that Numba can easily achieve bitwise parity to NumPy at a low level as literally the same functions are being called.

Essentially, due to this, it was possible to write something to get basic support plumbed through in a couple of hours (https://github.com/numba/numba/issues/4499#issuecomment-1063138477), without this it would have probably taken nearer a week, so thank you NumPy engineers, this was great! It also means that if NumPy needs to change something low level, these details are hidden from Numba!

There are a couple potential future improvements to this approach:

1. The ctypes functions appear as addresses which end up getting baked into the Numba JIT implementation as `long long`s which breaks Numba's on-disk caching. This is a problem for Numba to resolve!

2. The ctypes bound functions are essentially called like C function pointers, which means the performance is always going to be limited by having to stage a call and to use the compiled implementation from the NumPy DSO. Were there bitcode equivalants of these functions produced then Numba/JIT compilers could just consume these and LLVM could optimise across these function boundaries.

### FFT support in Numba.

Tracking ticket: https://github.com/numba/numba/issues/5864. The main issue is that there's no binding exposed for the FFT functions in the way there is for BLAS/LAPACK (via SciPy) and now also `BitGenerator`. As noted on the ticket, part of the issue is that there's no "consistent" interface for dealing with FFTs. Resolving this in a consistent type stable interface and then exposing this via e.g. ctypes would likely help all JIT applications needing FFT support (and also non-JIT applications!).

### Ufuncs.

There are a few interaction points in relation to ufuncs that might be of interest.

1. The ufunc inner loops could be provided as bitcode such that JIT compilers based on LLVM can request the bitcode implementation for given types and just consume that as part of compilation. This has the advantage of NumPy changes being picked up immediately by JIT compilers and that JIT compiler output becomes more consistent with NumPy. It also means a machine specific inner loop will always be generated by the JIT compiler.

2. NumPy could supply a hook for adding a JIT compiler to the ufunc machinery. As a result, if there is no specific loop available for given input types (i.e. casting would be required to get a match), the JIT compiler could potentially compile one which could lead to improved performance.

4. NumPy could abstract the entire ufunc interface such that an alternative implementation could be provided. Mixed with ideas in 1. and 2. this would let e.g. a JIT compiler produce CPU specific loops specialised directly on the types present. This again potentially leading to increased performance.

## Release testing

### Numba's test suite and build farm.

Numba has a large test suite, a lot of which exercises the NumPy APIs. The tests in the test suite are similar to NumPy's but not always the same. It's quite common for Numba's test suite to identify potential bugs/changes made to NumPy across releases.

Numba also has a large CI infrastructure which tests approximately the latest 3 or 4 NumPy releases against the Numba test suite on a large number of platforms. It has been noted a few times previously that it would be good for Numba to test against upcoming NumPy releases early as a mutually beneficial operation. Numba's test suite could potentially pick up issues in NumPy and vice versa. Further, if there are C-API changes in NumPy (especially with respect to ufuncs) there's a reasonable chance that Numba will pick them up. Numba has an "integration" testing project https://github.com/numba/numba-integration-testing that may help with orchestration of this.

user: stuartarchibald
labels: discussion: An issue requiring discussion
issue_8002: state: open
title: CFuncs cannot use numba.carray when jitting is disabled
body: Even when jitting is disabled with the [NUMBA_DISABLE_JIT](https://numba.pydata.org/numba-doc/dev/reference/envvars.html#envvar-NUMBA_DISABLE_JIT) flag, CFuncs still try to compile. This causes issues when the CFuncs are trying to use additional functions provided by Numba, e.g. [numba.carray](https://numba.pydata.org/numba-doc/dev/reference/utils.html), as those seem not to be available when jitting is disabled.

Could the Numba-provided utilities such as [numba.carray](https://numba.pydata.org/numba-doc/dev/reference/utils.html) be allowed to compile within cfuncs even when jitting is disabled for the rest of the code, or could the error message be clarified?

Minimal example that works with default settings but fails with `NUMBA_DISABLE_JIT=1`:
``` python
import ctypes

import numba
import numpy as np


@numba.cfunc(numba.types.void(
    numba.types.CPointer(numba.types.double)
))
def func(arr: np.ndarray) -> None:
    c_arr = numba.carray(arr, (3,), dtype=np.double)
    c_arr[-1] = 1


my_arr = np.array([1, 2, 3], dtype=np.float_).ctypes.data_as(ctypes.POINTER(ctypes.c_double))
func(my_arr)
```

Error with `NUMBA_DISABLE_JIT=1`:
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function carray at 0x7f8805dea5e0>) found for signature:
 
 >>> carray(float64*, UniTuple(Literal[int](3) x 1), dtype=class(float64))
 
There are 4 candidate implementations:
  - Of which 4 did not match due to:
  Overload in function '_OverloadWrapper._build.<locals>.ol_generated': File: numba/core/overload_glue.py: Line 131.
    With argument(s): '(float64*, UniTuple(int64 x 1), dtype=class(float64))':
   Rejected as the implementation raised a specific error:
     AttributeError: 'function' object has no attribute 'get_call_template'
  raised from <path_to_project>/venv/lib/python3.9/site-packages/numba/core/types/functions.py:541

During: resolving callee type: Function(<function carray at 0x7f8805dea5e0>)
During: typing of call at <path_to_project>/numba_test.py (11)


File "numba_test.py", line 11:
def func(arr: np.ndarray) -> None:
    c_arr = numba.carray(arr, (3,), dtype=np.double)
    ^
```

In my use case this error arises, as I have a cfunc that uses numba.carray, and this is passed to the [NumbaLSODA](https://github.com/Nicholaswogan/numblsoda) library for the integration of a differential equation. It would be useful to be able to compile this CFunc even when jitting is disabled for the rest of the program for debug purposes.
user: AgenttiX
issue_7993: state: open
title: optimization for frequently used code path
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

I'm not sure if numba has this feature already, but if we have, this must be a really good feature:
```python
# example
@njit
def impl_1(arr, mask):
    return arr[mask].mean()

@njit
def impl_2(arr, mask):
    s = 0
    c = 0
    for n, m in zip(arr, mask):
        if m:
            c += 1
            s += n
    if c > 0:
        return s / c
    else:
        return np.nan

arr = np.random.randn(10000)
msk = arr > 0
````
```python
%timeit -n 1000 impl_1(arr, msk)
```
36.8 µs ± 3.89 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
```python
%timeit -n 1000 impl_2(arr, msk)
```
26.8 µs ± 2.32 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

`impl_2` avoids making array copy from `__getitem__`

I think there are lots of optimizations that can be done here (recognize common usages and transform them into more effecient ones).
user: auderson
issue_7987: state: open
title: numba cov() does not support **aweights** parameter.
body: To calculate numpy version of exponential weighted covariance, **aweights**  is needed in numpy.cov() function. 


sample code showed as below:
```
def numpy_ewcov(values):
    length = values.shape[0]
    alpha = 2/(1+length)
    values = values[::-1]
    weight = (np.ones(length) * (1-alpha))**np.arange(0,length,1)
    ew_cov = np.cov(values.T,aweights=weight)
    
    return ew_cov
```
Hope **aweights** parameter for cov() func could be included in next version of Numba update. 
user: adiyaDalat
issue_7985: state: open
title: Rename Registry.register
body: Because I'm confused by `Registry.register` vs `Registry.register_global` in https://github.com/numba/numba/pull/7885#pullrequestreview-942957493

`Registryregister_global` is for real functions. This is more common.
`Registry.register` is for internal function markers/stubs; e.g. `cuda.grid`, `"static_getitem"`. This is rarely needed.


user: sklam
issue_7983: state: open
title: vectorized ufunc doesn't support default arguments
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```python
_norm_pdf_C = np.sqrt(2 * np.pi)


@numba.vectorize
def norm_pdf(x, loc=0, scale=1):
    return np.exp(-((x - loc) / scale) ** 2 * 0.5) / _norm_pdf_C / scale

norm_pdf(np.arange(10))
```
```
Traceback (most recent call last):
  File "/home/auderson/miniconda3/envs/py3.9/lib/python3.9/site-packages/IPython/core/interactiveshell.py", line 3361, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-29-a8ed1afc0938>", line 1, in <cell line: 1>
    norm_pdf(np.arange(10))
  File "/home/auderson/miniconda3/envs/py3.9/lib/python3.9/site-packages/numba/np/ufunc/dufunc.py", line 184, in _compile_for_args
    assert (args_len == nin) or (args_len == nin + self.ufunc.nout)
AssertionError
```
If we precompile it
```python
@numba.vectorize(['float64(float64, int64, int64)'])
def norm_pdf(x, loc=0, scale=1):
    return np.exp(-((x - loc) / scale) ** 2 * 0.5) / _norm_pdf_C / scale

norm_pdf(np.arange(10))
```
```
Traceback (most recent call last):
  File "/home/auderson/miniconda3/envs/py3.9/lib/python3.9/site-packages/IPython/core/interactiveshell.py", line 3361, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-25-a8ed1afc0938>", line 1, in <cell line: 1>
    norm_pdf(np.arange(10))
TypeError: norm_pdf() takes from 3 to 4 positional arguments but 1 were given
```


user: auderson
issue_7981: state: open
title: ppc64le OpenMP threading backend issue with `omp_set_max_active_levels`
body: This is to track an issue that appeared on the PPC64LE target when trying to update the OpenMP threading backend to use `omp_set_max_activate_levels` as a replacement for `omp_set_nested`.
xref: https://github.com/numba/numba/pull/7705.

The test that failed and how it failed is noted here: https://github.com/numba/numba/pull/7705#issuecomment-1018482015

Further investigation is required.
user: stuartarchibald
labels: threading: Issue involving the threading layers
bug - incorrect behavior: Bugs: incorrect behavior
ISA: POWER: Issue related to POWER ISA
issue_7977: state: open
title: Numba JIT becoming slower
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Using JIT makes my method even slower.

```python
import numpy as onp
import numba
import numba.typed as nbt
import time
import multiprocessing as mp


def f_pyo(mats, exps, masks):
    #
    num_groups = max((len(mats), len(exps), len(masks)))
    results = nbt.List()
    for i in range(num_groups):
        #
        results.append(onp.zeros_like(mats[i]))
    for i in numba.prange(num_groups):
        #
        if masks[i]:
            #
            results[i][:] = onp.linalg.matrix_power(mats[i], onp.sum(exps[i]))
        else:
            results[i][:] = onp.linalg.matrix_power(mats[i], 0)
    return results
f_jit1 = numba.njit(f_pyo, parallel=False)
f_jit2 = numba.njit(f_pyo, parallel=True)


nprng = onp.random.RandomState(47)
A = nbt.List()
exp = nbt.List()
mask = nbt.List()
for _ in range(30):
    #
    size = nprng.randint(300, 500 + 1)
    p = nprng.randint(1, 16 + 1)
    m = nprng.randint(0, 1 + 1)
    A.append(nprng.uniform(0.0, 1.0, (size, size)).astype(onp.float64))
    exp.append(onp.array(p).astype(onp.int64))
    mask.append(onp.array(m).astype(onp.bool8))


f_pyo(A, exp, mask)
start = time.time()
f_pyo(A, exp, mask)
elapsed = time.time() - start
print("PyObject:", elapsed)


f_jit1(A, exp, mask)
start = time.time()
f_jit1(A, exp, mask)
elapsed = time.time() - start
print("JIT     :", elapsed)



assert mp.cpu_count() > 4
numba.set_num_threads(4)
f_jit2(A, exp, mask)
start = time.time()
f_jit2(A, exp, mask)
elapsed = time.time() - start
print("JIT-4   :", elapsed)
```

I use SLURM to schedule the resources:

```bash
#!/bin/bash

#SBATCH --job-name=benchmark
#SBATCH --output=benchmark.stdout.txt
#SBATCH --error=benchmark.stderr.txt
#SBATCH --partition=...
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --ntasks-per-node=1
#SBATCH --gres=gpu:0
#SBATCH --cpus-per-task=5
#SBATCH --gpus-per-task=0

#
python benchmark.py
```

The time cost I got:

```
PyObject: 0.06118154525756836
JIT     : 0.0636894702911377
JIT-4   : 0.09839320182800293
```

Clearly, JIT is slower, and JIT with paralleling is even slower.
I have tried several times, and the performance are similar.

However, I am not quite sure about why this is happening.
user: gao462
labels: performance - run time: Performance issue occurring at run time.
issue_7974: state: open
title: Add support for getting the address of a cfunc within jitted code
body: Would it be possible to add support for getting the address of a cfunc within jitted code? This would enable the passing of a user-defined function that has been given to a jitted function to both Numba-jitted code and lower-level code (e.g. C/C++) that takes function pointers as its arguments without having to convert the function to a function pointer at the Python level.

This would also enable the passing of cfuncs to code within [numba.objmode](https://numba.pydata.org/numba-doc/latest/user/withobjmode.html), which does not yet support passing functions as arguments. Since pointers are mere integers, they can be passed to numba.objmode and then converted to Python-callable functions using [ctypes.CFUNCTYPE](https://docs.python.org/3/library/ctypes.html#ctypes.CFUNCTYPE) if necessary. In my particular use case I have a user-defined jitted function that I have to both call from within jitted code and pass it on to various integrators such as [scipy.integrate.odeint](https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.odeint.html) and [scipy.integrate.solve_ivp](https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.solve_ivp.html) that are called from deep within jitted functions using numba.objmode. Currently I have to pass the cfunc and the pointer to it through the jitted functions as separate arguments, but if this feature were implemented, passing only the cfunc would be sufficient.

Minimal example:
``` python
import numba


@numba.cfunc(numba.types.void())
def func():
    return


def wrapper_not_jitted(cfunc):
    """
    This works as described in:
    https://numba.pydata.org/numba-doc/latest/user/cfunc.html
    """
    return cfunc.address


@numba.njit
def wrapper_jitted(cfunc):
    """
    This produces the error:
    numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
    Unknown attribute 'address' of type FunctionType[none()]
    """
    return cfunc.address


print("This works")
wrapper_not_jitted(func)
print("But this does not")
wrapper_jitted(func)
```
user: AgenttiX
issue_7973: state: open
title: type_callable doesn't work with *args in typer
body: Using numba 0.55.1

Currently to use a type as a callable in jitted code you need to use this pattern where you define @type_callable(MyType), and overload(numba_typeref_ctor). This is the pattern used currently to implement List() and Dict(). This pattern works just fine if you use it with a fixed number of arguments, but if you try it with *args then you get an Assertion error. For instance:

```python
from numba import njit, types, i8
from numba.types import Integer
from numba.extending import type_callable, overload
from numba.core.imputils import numba_typeref_ctor

@type_callable(Integer)
def tf_type_callable(context):
    def typer(*args):
        return i8
    return typer

@overload(numba_typeref_ctor)
def tf_numba_typeref_ctor(self, *args):
    if(self.instance_type is Integer): return
    def impl(self, *args):
        return args[0]
    return impl

@njit(cache=True)
def try_Int_as_ctor():
    i = Integer(1,2)
    print("SHOULD BE 1:", i)

try_Int_as_ctor()
# >> AssertionError: Failed in nopython mode pipeline (step: native lowering)
```

The error is raised [here](https://github.com/numba/numba/blob/main/numba/core/lowering.py#L851) from the `stararg_handler` inside `Lower.fold_call_args` in lowering.py. From poking around, and seeing how this gets called on a normally, like when overload is used normally, it seems that there is some issue with the parameters associated with the *arg in the pysig not getting wrapped in a StarArgTuple.

----------------------

While on the topic this pattern seems a little bit heavy handed, and perhaps inefficient if the end user overloaded a lot of Type objects---something they would very reasonably want to do if they wanted their types to work as constructors (which is a desirable usage pattern since this is how python classes work). Right now the `redirect_type_ctor()` [builtin (here)](https://github.com/numba/numba/blob/main/numba/cpython/builtins.py#L586) gobbles up all such implementations and relegates them to numba_typeref_ctor. This means that if I have 100 types that I want to use as constructors then numba needs to try a factor of 100 implementations instead of trying just the one implementation associated with the calling type.

Maybe it would make sense to have a special decorator like `overload_type` for these cases?


user: DannyWeitekamp
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7969: state: open
title: Support `out` supplied as a key word argument to ufuncs (positional argument use is supported).
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

As title.

Plus, can anyone tell me where to find these ufuncs implemented in numba? 
user: auderson
issue_7968: state: open
title: Make `ir.Block.body` immutable
body: and add API to `ir.Block` to do the mutation.

Because exposing a settable and mutable attribute is very dangerous:

```python
saved_body = the_block.body
the_block.body[:] = [*the_block.body]
#~~~~~~~~~~~~~^^^ this matters                  
the_block.body = saved_body
```

vs

```python
saved_body = the_block.body
the_block.body = [*the_block.body]
#~~~~~~~~~~~~~^
the_block.body = saved_body
```
user: sklam
issue_7966: state: open
title: `Jitclass` decorator removes the method signatures of the wrapped instances
body: I've noticed that the `Jitclass` decorator replaces the method signatures of the wrapped instances with a generic `func_name(*args, **kwargs)` signature. See the example below: 

```python
In [1]: from numba.experimental import jitclass

In [2]: from numba import float64

In [3]: specs = [("alpha", float64), ("gamma", float64)]

In [4]: @jitclass(specs)
   ...: class Foo:
   ...:    def __init__(self, alpha, gamma):
   ...:        self.alpha = alpha
   ...:        self.gamma = gamma
   ...:

In [5]: from inspect import signature

In [6]: foo = Foo()

In [7]: foo = Foo(3., 2.)

In [8]: signature(foo.__init__)
Out[8]: <Signature (*args, **kwargs)>
```

I can access the signature of the class, but not the instance:
```python
In [9]: signature(Foo.__init__)
Out[9]: <Signature (self, alpha, gamma)>
``` 

I tried circumventing this issue using the `__class__` attribute, but:
```python
In [10]: signature(foo.__class__.__init__)
Out[10]: <Signature (self, /, *args, **kwargs)>
```

It'd be a valuable addition to keep the method signatures of the jitted instances.
user: PABannier
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7960: state: open
title: Support loading dispatcher metadata from cached functions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

I would like to look at the dispatcher metadata information on a cached function. However, when loading from cache this data isn't written to the cache, so functions that access the metadata fail when loading from cache succeeds. Here is a reproducer:

```python3
import numba
import numpy as np

@numba.njit(cache=True, parallel=True)
def g(A, n):
    B = A + n
    return B

g(np.ones(4), 10)
g.parallel_diagnostics()
```

The first time this runs successfully, but the output when loading from cache is:
```python3
Traceback (most recent call last):
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/test_cache.py", line 10, in <module>
    print(g.parallel_diagnostics())
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 1027, in parallel_diagnostics
    [dump(sig) for sig in self.signatures]
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 1027, in <listcomp>
    [dump(sig) for sig in self.signatures]
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 1019, in dump
    pfdiag = ol.metadata.get('parfor_diagnostics', None)
AttributeError: 'NoneType' object has no attribute 'get'
```
Any feedback you have on the best way to go about this would be greatly appreciated.
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: njriasan
labels: caching: Issue involving caching
issue_7955: state: open
title: Add support for numpy.ndarrays in numpy functions in ALL parameter positions where numpy supports them
body: Hi Numba team,

Thank you for what you have created! The need for better performance in Python is SO needed and this project IMO has the biggest potential. I've been trying to leverage numba in my data analytics projects over the last 6 months but have failed on each attempt, the main reason being the lack of support for numpy.ndarrays in every position that numpy supports. e.g. a_min and a_max can be numpy.ndarray in numpy.clip(a, a_min, a_max, out=None, **kwargs) but can only be simply numbers when used with numba.

I believe adding this capability across numba would be **the biggest increase in utility per unit input time** your team could give for the following reason:

The most likely reason a programmer will find numba is through searching for ways to increase the performance of their python code. They are likely to already have implemented the best practices for increasing performance, such as numpy vectorizing any numerical computation. Therefore, it is very likely that the code your prospective users are trying to speed up will already be leveraging numpy's ability to do operations across ndarrays. If you could support this functionality fully, **mirroring the support for ndarray's in numpy**, it would enable programmers to drop in numba to their code with minimum refactoring and see the results.

What would be truly incredible is if the numba documentation could be summarised as follows:

"Achieve a huge performance boost in python for any function that:
1) does numerical computations..
2) that use just numpy and pure python and ...
3) all objects are numpy objects (e.g. no list, dict or pandas objects)"

Adding support for support for numpy.ndarrays in all parameter positions that numpy does would be a huge step towards this. Removal of condition (3) above would be the next biggest utility increase, as its very likely that a coder would need to do refactoring to avoid passing non-numpy objects to their functions.

I have actually raised a similar issue before "numpy.clip accept numpy.array for a_max #7521". The fix suggested by your contributor sounds easy to implement and I am sure would have worked for me. BUT, any suggest to my organisation I make to use numba will be shot down if its reliant on custom edits to the numba code. Please consider making this general capability a high priority. 

Best wishes and many thanks, Mike

p.s. See issue #7521 for detailed example
user: Twomem
issue_7954: state: open
title: Provide a way for lowering to know what Compute Capability is being targeted
body: As discussed in https://github.com/numba/numba/pull/7556#pullrequestreview-928732504, it's not possible for lowering to generate specific code based on the compute capability of the target device, because there's no way to know what it is.

An example use of this would be to generate inline assembly for CC 8.0 devices for max/min instructions on 16-bit floating point operands - presently we have to instead lower to a generic implementation that works for all compute capabilities.

One way to do this would be to add it to the `CUDAFlags`:

https://github.com/numba/numba/blob/637a75023bae889467ebfc0e8489be547b62a209/numba/cuda/compiler.py#L25-L30

but then we'd also need to provide a route for lowering to be able to tell what the flags are in the current compiler pipeline.


user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7948: state: open
title: No variable slicing with None, as optional type not inferred
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- I have tried using the latest released version of Numba (0.55.1)

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Hello,
 
in a project I am working on right now, I would like to variably slice a numpy array in a numba jitted function.
If I slice with `None` as upper index, I get the whole array, as one would expect. Slicing with a number also works.

What does not work is assigning `None` to the int index and then slicing, i.e. in

```
import numba as nb
import numpy as np

@nb.jit(nopython=True)
def test(A,x):
    y = 1
    if x > 10:
        y = None
    return A[:y]

print(test(np.array([1.0, 2.0, 3.0]), 100))
```

if x>10, one gets a TypeError, `TypeError: expected int64, got None` because, I assume, the type of y cannot be correctly inferred as `numba.optional(int)` 

I assume this is a bug and not intentional behavior. A possible workaround is using if statements and empty slices, i.e. 

```
@nb.jit(nopython=True)
def test1(A,x):
    y = 1
    if x > 10:
        y = None
    if y is None:
      rA = A
    else:
      rA = A[:y]
    return rA
```
but this is obviously really ugly and lengthy if one has to do this a lot.

Txt file with the minimal code: [bug.txt](https://github.com/numba/numba/files/8371843/bug.txt)
user: oliverdrozdowski
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7945: state: open
title: Debugging: optimization issue with parallel:True
body: Hi, I am using Numba 0.55.1, below is my example:

```python
import numpy as np
from numba import njit


@njit(debug=True, parallel=True)
def func_sum(a_in_func, b_in_func):
    result = 0  # func_line_1
    result = a_in_func + b_in_func  # func_line_2
    return result  # func_line_3


@njit(debug=True)
def kernel_sum(a_in_kernel, b_in_kernel, size):
    c_in_kernel = np.empty_like(a_in_kernel)  # numba-kernel-breakpoint
    for i in range(size):  # kernel_line_2
        c_in_kernel[i] = func_sum(a_in_kernel[i], b_in_kernel[i])  # kernel_line_3
    return c_in_kernel  # kernel_line_4


def main():
    a = np.array(
        [1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5]
    )
    b = np.array(
        [9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5]
    )
    global_size = np.size(a)
    c = np.ones_like(a)

    c = kernel_sum(a, b, global_size)


if __name__ == "__main__":
    main()
```

If 'parallel=True' option is set, optimizations from the ParforPass works (ParforPass -> simplify -> remove_dead) and the line 7 disappear from IR and DWARF:
```python
Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x00007fffdc010000      6      0      1   0             0  is_stmt
0x00007fffdc01004d      8      1      1   0             0  is_stmt prologue_end
0x00007fffdc010069      9      1      1   0             0  is_stmt
0x00007fffdc0105c2      9      1      1   0             0  is_stmt end_sequence
```

And as a result of this, the debugger does not see this line and cannot break on it:
```python
(gdb) b /localdisk/work/etotmeni/debug_files/debug_ticket/example.py:7
No source file named /localdisk/work/etotmeni/debug_files/debug_ticket/example.py.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (/localdisk/work/etotmeni/debug_files/debug_ticket/example.py:7) pending.
(gdb) r
Thread 1.1 "python" hit Breakpoint 1, __main__::func_sum_245[abi:c8tJTC_2fWQAkyW1xhBopo9CCDiCFCDMJHDTCIGCy8IDxIcEFloKEF4UEDC8KBhhWIo6mjAE8zUFm0hIwqipFsYTYXQViaAA_3d_3d](double, double) (a_in_func=1234.5, b_in_func=9876.5) at example.py:8
8           result = a_in_func + b_in_func  # func_line_2
```

If the parallel option is set to False, everything works fine and the line 7 is in the dwarf

Is there a way to disable some optimizations for parfor?
user: 1e-to
labels: bug - DWARF: Bugs related to debugging support
issue_7943: state: open
title: CUDA Vector Types
body: CUDA supports writing [builtin vector types](https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#built-in-vector-types) in kernels. Such as `float2`, `uint3`, etc. Each element of the vector type can be accessed via `x`, `y`, `z`, `w`. And each vector type has its own `make_` factory function. It would be nice if Numba cuda supports them.

[UPDATE 04/29/2022]: Per [this comment](https://github.com/numba/numba/pull/7949#issuecomment-1113563337), the cuda vector types are named as `<base_type>x<num_elements>`, names from native cuda will be aliased on top of the previous names.
user: isVoid
labels: CUDA: CUDA related issue/PR
issue_7938: state: open
title: array_equal new impl
body: closes #7937

algo updated: use 2 seperate loop for equal_nan = True / False, which further reduces time spent:

worst case:
1.39 µs vs 2.1 µs
best case
479 ns vs 658 ns

user: auderson
issue_7937: state: open
title: enhancement for `array_equal`
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request


I find current `array_equal` doesn't support `equal_nan` argument, so I made an implementation as follows:
```python
@njit
def eq1(a, b, equal_nan=False):
    a = np.asarray(a)
    b = np.asarray(b)
    if a.shape != b.shape:
        return False
    for _a, _b in zip(a.flat, b.flat):
        if _a != _b:
            if equal_nan and _a != _a and _b != _b:
                continue
            else:
                return False
    return True

@njit
def eq2(a, b):
    return np.array_equal(a, b)

eq3 = np.array_equal
```

Besides, I find my implementation is both faster than original numba implemention and numpy's:

```python
# worst case: all equal
a, b = np.ones((2, 1000))

%timeit -n 10000 _ = eq1(a, b)
# 2.1 µs ± 77.3 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit -n 10000 _ = eq2(a, b)
# 2.6 µs ± 60.5 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit -n 10000 _ = eq3(a, b)
# 4.14 µs ± 969 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

# best case: all non-equal
c = a + 1

%timeit -n 10000 _ = eq1(a, c)
# 658 ns ± 12.8 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit -n 10000 _ = eq2(a, c)
# 1.05 µs ± 22.4 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit -n 10000 _ = eq3(a, c)
# 5.25 µs ± 140 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)
```
FYI: numpy impl:

https://github.com/numpy/numpy/blob/4eb53425ecdad412411d6d174064405f511494eb/numpy/core/numeric.py#L2396-L2464

In my impl, I use a loop instead of `np.all(a==b)`, which may help reducing memory alloc and can return early. 

I can make a PR If you think this new impl is OK.


user: auderson
issue_7935: state: open
title: Experiment with adding a domain field to integer types
body: Following on from https://github.com/numba/numba/issues/7934, this reminded me of a discussion about this exact issue in a Numba public meeting a while back, I don't think the outcome was recorded as an issue so am doing so here.

Taking the example from #7934
```python
from numba import njit, prange
import numpy as np

testarray = np.empty(100)

@njit(parallel=True)
def test(arrayin, backward):
    nx = len(arrayin)
    for ix in prange(nx):
        if backward:
            ixA = nx - ix - 1
        else:
            ixA = ix
        arrayin[ixA] = ix

test(testarray, False)
```
The `prange` loop is typed through to `range_state_uint64` and `range_iter_uint64` with the induction variable `ix` as a `uint64`, this leads to the common issue arising from NumPy's type unification rules whereby:
```python
In [10]: np.dtype(np.mintypecode(np.dtype(np.int64).char, np.dtype(np.uint64).char))
Out[10]: dtype('float64')
```
i.e. `uint64` operating with `int64`, results in a `float64` dtype.

The reason the `prange` loop is typed as unsigned is so as to produce a guarantee about the domain when used as an index into an array. An unsigned index is always 0 or positive so this avoids having to do "wrap around" arithmetic for a potential negative index, and this in turn massively helps vectorization and increases performance as a result.

The discussion in the Numba public meeting on this resulted in there being a need to experiment with adding a `domain` field to signed integer types. This is so that the type inference for a `prange` loop with `parallel=True` can produce a `int64` type for the induction variable, the same as in the `parallel=False` case. However, with the addition of a `domain='postive'` or similar field in the type, code generation for indexing can safely assume no wrap around. Obvious there's some additions needed to type unification to handle this field as part of this experiment.
user: stuartarchibald
issue_7933: state: open
title: Checking *args is empty inside overloaded method
body: Hi,
I have been trying to overload a method with different functionality depending on whether *args is empty or not. However I could not come up with a condition to check if args is empty. 

```
overload_method(SeriesType, 'transform')
def pd_series_overload_single_func_args(self, func, *args):
    print(args)
    <Need the correct condition here>
        def impl(self, func, *args):
            print("hello")

        return impl
    else:
        def impl(self, func, *args):
            print("world")

        return impl
```

I tried comparing to `()` , `None` `OmittedType` etc. but to no avail.
Can someone suggest the correct condition that can be used here?
user: sakshamkumar-byt
issue_7929: state: open
title: CUDA: Using `NUMBA_CUDA_USE_NVIDIA_BINDING` with other GPU Libraries
body: Setting `NUMBA_CUDA_USE_NVIDIA_BINDING=1` causes some interoperability issues with other libraries.

This started out of some testing I was doing with `cudf` using newer versions of numba that support `NUMBA_CUDA_USE_NVIDIA_BINDING` to switch to the CUDA Python binding. Numba is internally self consistent with this set and unset, but other libraries aren't aware of this change though and expect the old API, causing things to break when trying to use these libraries together. For example:

- [here in RMM](https://github.com/rapidsai/rmm/blob/branch-22.04/python/rmm/rmm.py#L121)
- [here in pyarrow](https://github.com/apache/arrow/blob/master/python/pyarrow/_cuda.pyx#L84-L85)

My question is how should these other libraries transition as eventually the new bindings become required? @gmarkall suggested they could temporarily condition on `numba.config` to detect if numba is using the new or old bindings, and do something different based on that (I am happy to put in PRs for this). However ultimately a breaking change will end up being needed, if numba intends to someday only use the `cuda` bindings. I was wondering if there were any thoughts about the best way to handle this?

user: brandon-b-miller
labels: CUDA: CUDA related issue/PR
discussion: An issue requiring discussion
issue_7928: state: open
title: CUDA: functions can only be used as device functions or as kernels, not both in the same program.
body: MWR:
```python
from numba import cuda

@cuda.jit
def f():
    pass

@cuda.jit
def g():
    f() # make call to function `f`

f[1, 1]() # function f used as a kernel
g[1, 1]() # function f used as a device function
```
Produces:
```
NotImplementedError: No definition for lowering None() -> none
```
Switching the order of the calls to `f` and `g` results in the same. Whichever use is made of `f` first (kernel or device function) "wins".

In theory this restriction should not exist at all. In practice it might be easier to get this working for cases where no signature is provided. When a signature is provided, to emulate the CPU target behaviour, the CUDA target would need to compile as soon as the decorator is executed and this means knowing whether the function is intended for use as a device function or as a kernel.

user: stuartarchibald
labels: CUDA: CUDA related issue/PR
issue_7927: state: open
title: CUDA: discussion: retire the use of a separate launch configuration object, launch kernels directly!
body: In Numba, when a CUDA kernel is executed it must first be configured for the execution. This is done via the overloaded `__getitem__` syntax which returns an intermediate "configured launch" object that, when called, actually executes the kernel launch. Splitting this out so as to make it clear what is happening...
```python
from numba import cuda

@cuda.jit
def foo():
  pass

configured_launch = foo[1, 1] # __getitem__ on the CUDADispatcher, returns an instance of a _LaunchConfiguration
configured_launch() # Calling this _LaunchConfiguration instance executes the kernel.
```
For reference, the `__getitem__` code that returns the `_LaunchConfiguration` is here:
https://github.com/numba/numba/blob/fa3630edab447f38f81c97cbd943809ebe7a9840/numba/cuda/dispatcher.py#L516-L523
and the execution of the kernel is undertaken by the `__call__` of the `_LaunchConfiguration` object:
https://github.com/numba/numba/blob/fa3630edab447f38f81c97cbd943809ebe7a9840/numba/cuda/dispatcher.py#L453-L474

From OOB discussion with @gmarkall and @seibert (both independently), there are a few issues with the above:
1. In terms of performance, having a two stage kernel launch adds to launch time. The intermediate launch object has to be created, and it's largely ephemeral/might not be obvious to users that it can addressed as a separate object. Example:
    ```python
    from numba import cuda
    from numba import config

    # switch this check off, just time object creation/dispatch
    config.CUDA_LOW_OCCUPANCY_WARNINGS=0

    @cuda.jit
    def nop():
        pass

    # Combined configure and launch.
    nop[1, 1]() # Locally this is 23.1 microseconds

    # Separate configuration and launch.
    cfg = nop[1, 1]
    cfg() # Locally this is 16.7 microseconds, i.e. 38% faster.
    ```
2. Due to historical reasons, the arguments to the `__getitem__` on a kernel to specify the launch configuration are positional. This means if a user wants to supply ``sharedmem`` but not ``stream``, they have no option but to work out a stream for use. Further, the argument order of shared memory and stream is the reverse order of that in the Execution Configuration specification https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#execution-configuration.


3. In terms of being able to JIT compile the launch site, which will create a faster launch and also eventually permit launching CUDA kernels from CPU code (see https://github.com/numba/numba/pull/7860), if there's a single stage launch it potentially makes the code generation a lot easier as there's just a single object to handle.


Given the above and all those involved so far agreeing that this needs to be addressed. This ticket is to explore the merits of a single stage launch and how to implement this through reserved keyword arguments on a kernel call.

Assuming a prototype like:
```python
@cuda.jit
def kernel(arg0, arg1, ..., *args, kw0=tmp0, kw1=tmp1, ... kwn=tmpn)
```
Additional launch arguments to the kernel need to convey:
 * Grid information
 * Block information
 * Shared memory information
 * Stream information

Some initial ideas (using the variable names/meanings as per the CUDA C guide):

1. Grid/block as tuples
```python
@cuda.jit
def kernel(arg0, arg1, ..., *args, kw0=tmp0, kw1=tmp1, ... kwn=tmpn,
          grid = (Dg.x, Dg.y, Dg.z), # up to 3-tuple of int
          block = (Db.x, Db.y, Db.z), # up to 3-tuple of int
          sharedmem = Ns, # int
          stream = None, # None for default (translates to 0) or stream type.
          )
```
2. Grid/block as variables
```python
@cuda.jit
def kernel(arg0, arg1, ..., *args, kw0=tmp0, kw1=tmp1, ... kwn=tmpn,
          gridx = Dg.x,
          gridy = Dg.y,
          gridz = Dg.z,
          blockx = Db.x,
          blocky = Db.y,
          blockz = Db.z,
          sharedmem = Ns, # int
          stream = None, # None for default (translates to 0) or stream type.
          )
```


user: stuartarchibald
labels: CUDA: CUDA related issue/PR
discussion: An issue requiring discussion
issue_7925: state: open
title: typed.List 2x slower than reflected list (reproduced on Intel and AMD CPUs)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
You need numpy, scipy and numba to run the code.

The **only difference** between the different `process` are the way **individual `stencils` are accessed**: though iterators in `process`, `getitem_unchecked` in `process2` (typed List only) and normal `getitem` in `process3` (reflected list only).

<details>
<summary>Code (bug.py)</summary>

```python
import numba as nb
import numpy as np
from numba.extending import intrinsic
from numba.types import ir
from time import perf_counter_ns
from scipy.ndimage import gaussian_filter

@intrinsic
def addmod_tuples(tyctx, tpl1, tpl2, shape):
    """Returns tuple((t1+t2)%s for t1, t2, s in zip(tpl1, tpl2, shape))"""
    ret = tpl1
    count = tpl1.count
    dtype = ret.dtype
    typ = ir.types.IntType(dtype.bitwidth)
    zero = ir.Constant(typ, 0)
    
    def codegen(cgctx, builder, sig, args):
        val_tpl1, val_tpl2, val_shape = args

        tup = cgctx.get_constant_undef(ret)
        
        for i in range(count):
            # Extract scalars
            t1 = builder.extract_value(val_tpl1, i)
            t2 = builder.extract_value(val_tpl2, i)
            s = builder.extract_value(val_shape, i)
            
            # Modulo
            bb_main = builder.block
            
            main_val = builder.add(t1, t2)
            
            overflow = builder.icmp_signed(">=", main_val, s, name='')
            underflow = builder.icmp_signed("<", main_val, zero, name='')
            
            bb_main = builder.block
            with builder.if_then(overflow, likely=False):
                over_val = builder.sub(main_val, s)
                bb_overflow = builder.block
                
            val_ = builder.phi(typ)
            val_.add_incoming(main_val, bb_main)
            val_.add_incoming(over_val, bb_overflow)
                
            bb_main2 = builder.block
            with builder.if_then(underflow, likely=False):
                under_val = builder.add(main_val, s)
                bb_underflow = builder.block
            
            # Phi node:  val = (t1+t2)%s
            val = builder.phi(typ)
            val.add_incoming(val_, bb_main2)
            val.add_incoming(under_val, bb_underflow)
            
            
            # Assign to tuple
            tup = builder.insert_value(tup, val, i)
        return tup
    sig = ret(tpl1, tpl2, shape)
    return sig, codegen

@nb.jit
def process(arr, stencils):
    
    shape = arr.shape     
    direction = np.empty(arr.shape, dtype=np.int8)
    
    for index in nb.pndindex(shape):
        old_g = -np.inf
        cdir = -1  
        g_c = arr[index]
        
        
        ## THIS IS THE MAIN CHANGING PART:
        for i, stencil in enumerate(stencils):
            ## END OF CHANGING PART
            
            nindex = addmod_tuples(index, stencil, shape)
            
            g_n = arr[nindex]
            
            new_g = (g_n - g_c)
            
            if old_g < new_g:
                old_g = new_g
                if new_g > 0.0:
                    # Saves i (as in 'stencils[i]') as main direction
                    cdir = i
            
            if (new_g < 0.0) and (cdir == -1):
                # Local maximum
                cdir = -2
        direction[index] = cdir
    return direction

@nb.jit
def process2(arr, stencils):
    
    shape = arr.shape     
    direction = np.empty(arr.shape, dtype=np.int8)
    
    N = len(stencils)
    
    for index in nb.pndindex(shape):
        old_g = -np.inf
        cdir = -1  # No gradient, default
        g_c = arr[index]

        ## THIS IS THE MAIN CHANGING PART:
        for i in range(N):
            stencil = stencils.getitem_unchecked(i)
            ## END OF CHANGING PART
            
            nindex = addmod_tuples(index, stencil, shape)
            
            g_n = arr[nindex]
            
            new_g = (g_n - g_c)
            
            if old_g < new_g:
                old_g = new_g
                if new_g > 0.0:
                    # Saves i (as in 'stencils[i]') as main direction
                    cdir = i
            
            if (new_g < 0.0) and (cdir == -1):
                # Local maximum
                cdir = -2
        direction[index] = cdir
    return direction

@nb.jit
def process3(arr, stencils):
    
    shape = arr.shape     
    direction = np.empty(arr.shape, dtype=np.int8)
    
    N = len(stencils)
    
    for index in nb.pndindex(shape):
        old_g = -np.inf
        cdir = -1  # No gradient, default
        g_c = arr[index]

        ## THIS IS THE MAIN CHANGING PART:
        for i in range(N):
            stencil = stencils[i]
            ## END OF CHANGING PART
            
            nindex = addmod_tuples(index, stencil, shape)
            
            g_n = arr[nindex]
            
            new_g = (g_n - g_c)
            
            if old_g < new_g:
                old_g = new_g
                if new_g > 0.0:
                    # Saves i (as in 'stencils[i]') as main direction
                    cdir = i
            
            if (new_g < 0.0) and (cdir == -1):
                # Local maximum
                cdir = -2
        direction[index] = cdir
    return direction


# Generate stencils
r = (-1, 0, 1)
stencils_refl = [(i, j, k) for i in r for j in r for k in r if (i, j, k) != (0, 0, 0)]
stencils_typed = nb.typed.List()
for s in stencils_refl:
    stencils_typed.append(s)
    
# Generate dummy data
shape = (259, 259, 259)
arr = np.zeros(shape, dtype=np.float64)

for _ in range(3):
    arr += (np.random.rand(*shape) > 0.95).astype(np.float64)
    arr = gaussian_filter(arr, 10.0, mode="wrap")


# JIT warm-up
d1 = process(arr, stencils_refl)
d2 = process(arr, stencils_typed)
d3 = process2(arr, stencils_typed)
d4 = process3(arr, stencils_refl)

assert np.all(d1 == d2)
assert np.all(d2 == d3)
assert np.all(d3 == d4)


# Helper function for benchmarking
def bench(n, /, f, *args, **kwargs):
    tot = 0.0
    for _ in range(n):
        tic = perf_counter_ns()
        f(*args, **kwargs)
        toc = perf_counter_ns()
        tot += (toc - tic)
    return tot / n


# Benchmark
print( "============================================")
print( " List type     implementation     time (ms)")
print( "--------------------------------------------")

t = bench(3, process, arr, stencils_refl)
print(f" reflected       iterators        {t/1e6:8.5f}")

t = bench(3, process, arr, stencils_typed)
print(f"   typed         iterators        {t/1e6:8.5f}")

t = bench(3, process2, arr, stencils_typed)
print(f"   typed          getitem         {t/1e6:8.5f}")

t = bench(3, process3, arr, stencils_refl)
print(f" reflected        getitem         {t/1e6:8.5f}")
print( "--------------------------------------------")
```
</details>

With real-life data and a slightly different implementation (adding complexity for nothing), I get

```text
============================================
 List type     implementation     time (ms)
--------------------------------------------
 reflected       iterators        1236.13449
   typed         iterators        2368.16592
   typed          getitem         2299.75980
 reflected        getitem         2030.11379
--------------------------------------------
```

With the exact code I provided, I get

```text
============================================
 List type     implementation     time (ms)
--------------------------------------------
 reflected       iterators        1898.99720
   typed         iterators        2673.21427
   typed          getitem         2933.83761
 reflected        getitem         2405.43470
--------------------------------------------
```
user: gdonval
labels: performance - run time: Performance issue occurring at run time.
issue_7922: state: open
title: gcd, lcm, subtract, sign, and negative don't match numpy behavior with bool inputs
body: ## Reporting a bug
- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I noticed that numba doesn't match NumPy's behavior for `np.gcd`, `np.lcm`, and `np.sign` with bool inputs.  Notably, NumPy raises, but numba treats bools as ints:
```python
>>> import numpy as np
>>> import numba
>>> @numba.njit
... def gcd(x, y):
...     return np.gcd(x, y)
...
>>> gcd(True, True)
1
>>> np.gcd(True, True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
numpy.core._exceptions._UFuncNoLoopError: ufunc 'gcd' did not contain a loop with signature matching types (dtype('bool'), dtype('bool')) -> dtype('bool')
>>> @numba.njit
... def sign(x):
...     return np.sign(x)
...
>>> sign(True)
1
>>> np.sign(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
numpy.core._exceptions._UFuncNoLoopError: ufunc 'sign' did not contain a loop with signature matching types dtype('bool') -> dtype('bool')
>>> @numba.njit
... def lcm(x, y):
...     return np.lcm(x, y)
...
>>> lcm(True, True)
1
>>> np.lcm(True, True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
numpy.core._exceptions._UFuncNoLoopError: ufunc 'lcm' did not contain a loop with signature matching types (dtype('bool'), dtype('bool')) -> dtype('bool')
```
I can get by with the current behavior, but thought you would want to know.
user: eriknw
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7921: state: open
title: BUG: bytes type equals goes through ufunc mechanism
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This
```python
from numba import njit

@njit
def foo(x,):
    return x == x

foo(b'')
```
results in:
```
Failed in nopython mode pipeline (step: nopython frontend)
No conversion from array(bool, 1d, C) to bool for '$8return_value.3', defined at None

File "issue.py", line 1:
from numba import njit
```
which is due to the `arrayexpr` rewrite considering `b''` as `Bytes` type which is `ArrayCompatible` , hence it ends up trying to rewrite the expression `x == x` as a ufunc.  This consequently triggers typing via: 
https://github.com/numba/numba/blob/181f57c22e8b9708f5864196ef4f254895181374/numba/core/typing/npydecl.py#L202-L223
which leads to a signature:
```
(readonly bytes(uint8, 1d, C), readonly bytes(uint8, 1d, C)) -> array(bool, 1d, C)
```
that is accepted as `Bytes` is `ArrayCompatible`:
https://github.com/numba/numba/blob/181f57c22e8b9708f5864196ef4f254895181374/numba/core/typing/npydecl.py#L220-L222
and this is root cause of the error message above.

The secondary issue in all this is that the error message refers to line 1 of the original script opposed to the generated arrayexpr function source.

user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
bug - typing: Bugs: occuring at typing time
issue_7917: state: open
title: Potential enhancements after dropping python 3.7
body: There was a suggestion on dropping python 3.7 after Numba 0.56 release. This issue keep tracks of potential enhancements after python 3.7 is dropped.

The following list will be expanded as needed.

- [ ] use [vectorcall](https://peps.python.org/pep-0590/) for reducing Dispatcher call overhead. This has proven to be useful in nanobind (https://github.com/wjakob/nanobind#dependencies).
user: sklam
issue_7916: state: open
title: Silently incorrect compilation involving nested functions and asserts
body: This is a very nasty bug that leads to silently incorrect compilation. I first encountered it using `cuda.jit`, but have reproduced it identically on plain `nb.jit`. Here's a repro and explanation.

```python3
import numpy as np
import numba as nb

@nb.jit
def foo_kernel(data):
  def inner(): 
    assert True

    def even_innerer(): pass

    even_innerer()

    foo = 0
    foo = 0
    data[foo] = 1

  inner()

foo_data = np.zeros((1))
foo_kernel(foo_data)
print(foo_data)
```

The above should print `[1.]` but instead prints `[0.]`.

The correct behaviour can be restored by doing any one of the following things:
- Removing `assert True` (it seems to happen for any assertion)
- Removing the `even_innerer()` call
- Removing either one of the duplicated `foo = 0` lines
- Removing the nesting - i.e. inlining the content of `inner` directly into the kernel
- Moving the `assert` below the second `foo = 0`. If it's anywhere above that (including between the two) then the bug triggers.

The position of the `even_innerer()` call doesn't seem to matter at all, its mere presence triggers the bug.

I've confirmed this on `0.51.2` and `0.55.1` on Google Colab.

I'd appreciate any information/speculation on what's going on here, as I have a fairly large and involved CUDA kernel with a few levels of nesting, and I'm now scared that things are going to break in ways that are very hard to detect. This already took a few hours to track down, after systematically eliminating all other possible causes. For example, reassurance that this bug only occurs in the presence of `assert` would give me a clear path to guarantee that I don't stumble into it again.
user: SamPruden
labels: bug - miscompile: Bugs: miscompile
issue_7913: state: open
title: Using a function that prints inside another AOT function causes `RuntimeError: missing Environment`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python

from numba import njit
from numba.pycc import CC
from numba.core.types import void, int64

cc = CC('aot_test')


@njit
def _func_print(a):
    print(a)


@njit
def _func_normal(a):
    return a


@cc.export('func_print', void(int64))
def func_print(a):
    _func_print(a)


@cc.export('func_normal', int64(int64))
def func_normal(a):
    return _func_normal(a)


@cc.export('func_direct_print', void(int64))
def func_direct_print(a):
    print(a)


cc.compile()

import aot_test as aot


aot.func_print(1)
# RuntimeError: missing Environment: _ZN08NumbaEnv8__main__15_func_print_245B42c8tJTIeFCjyCbUFRqqOAK_2f6h0kCng1maAA_3d_3dEx
aot.func_normal(1)
# 1
aot.func_direct_print(1)
# 1
```
`func_print` uses `_func_print` which contains `print` inside. 
`func_normal` uses `_func_normal` which doesn't print.
`func_direct_print` use `print` directly.
user: auderson
labels: AOT: ahead of time compilation issue
bug - incorrect behavior: Bugs: incorrect behavior
issue_7907: state: open
title: Debugging: strange behavior info locals
body: Hi, I am using Numba 0.55.1, below is my example:

```python
import numpy as np
from numba import njit


@njit(debug=True)
def func_sum(a_in_func, b_in_func):
    result = 0  # func_line_1
    result = a_in_func + b_in_func  # func_line_2
    return result  # func_line_3


@njit(debug=True)
def kernel_sum(a_in_kernel, b_in_kernel, size):
    c_in_kernel = np.empty_like(a_in_kernel)  # numba-kernel-breakpoint
    for i in range(size):  # kernel_line_2
        c_in_kernel[i] = func_sum(a_in_kernel[i], b_in_kernel[i])  # kernel_line_3
    return c_in_kernel  # kernel_line_4


def main():
    a = np.array(
        [1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5, 1234.5]
    )
    b = np.array(
        [9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5, 9876.5]
    )
    global_size = np.size(a)
    c = np.ones_like(a)

    c = kernel_sum(a, b, global_size)


if __name__ == "__main__":
    main()

```

When I put a breakpoint on line 7 and try to look at info locals it shows the following:

```bash
Thread 1.1 "python" hit Breakpoint 1, __main__::func_sum_245[abi:c8tJTC_2fWgEeGLSgydRTQUgiqKEZ6gEoDvQJmaQIA](double, double) (a_in_func=1234.5, b_in_func=9876.5) at example.py:7
7           result = 0  # func_line_1
(gdb)  info locals
result = 0
result$1 = 0
```

Why do we have two variables here (result and result$1)? Is this correct? Isn't the result$1 variable debug information and shouldn't be displayed?
Also after the following commands:

```bash
(gdb) n
8           result = a_in_func + b_in_func  # func_line_2
(gdb)  info locals
result = 0
result$1 = 0
(gdb) n
9           return result  # func_line_3
(gdb)  info locals
result = 0
result$1 = 11111
```

Why are these two variables saved and we see the value 11111 only on line 9 and not on line 8?
user: 1e-to
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
bug - DWARF: Bugs related to debugging support
issue_7903: state: open
title: error from getitem with optional array
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi, I found the following codes will fail:
```python
import numpy as np
from numba import njit


@njit("float64[:](float64[:], optional(boolean[:]))")
def f1(x, mask=None):
    if mask is None:
        mask = np.isfinite(x)
    return x[mask]
```
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function getitem>) found for signature:
 
 >>> getitem(array(float64, 1d, A), OptionalType(array(bool, 1d, A)))
 
There are 22 candidate implementations:
  - Of which 20 did not match due to:
  Overload of function 'getitem': File: <numerous>: Line N/A.
    With argument(s): '(array(float64, 1d, A), OptionalType(array(bool, 1d, A)))':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'GetItemBuffer.generic': File: numba/core/typing/arraydecl.py: Line 166.
    With argument(s): '(array(float64, 1d, A), OptionalType(array(bool, 1d, A)))':
   Rejected as the implementation raised a specific error:
     NumbaTypeError: unsupported array index type OptionalType(array(bool, 1d, A)) in [OptionalType(array(bool, 1d, A))]
  raised from /home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/typing/arraydecl.py:72
During: typing of intrinsic-call at <ipython-input-4-70443e7e4add> (5)
File "<ipython-input-4-70443e7e4add>", line 5:
def f1(x, mask=None):
    <source elided>
        mask = np.isfinite(x)
    return x[mask]
    ^
```
```python

@njit("float64[:](float64[:], optional(int64[:]))")
def f2(x, mask=None):
    if mask is None:
        mask = np.arange(x.size)
    return x[mask]
```
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function getitem>) found for signature:
 
 >>> getitem(array(float64, 1d, A), OptionalType(array(int64, 1d, A)))
 
There are 22 candidate implementations:
    - Of which 20 did not match due to:
    Overload of function 'getitem': File: <numerous>: Line N/A.
      With argument(s): '(array(float64, 1d, A), OptionalType(array(int64, 1d, A)))':
     No match.
    - Of which 2 did not match due to:
    Overload in function 'GetItemBuffer.generic': File: numba/core/typing/arraydecl.py: Line 166.
      With argument(s): '(array(float64, 1d, A), OptionalType(array(int64, 1d, A)))':
     Rejected as the implementation raised a specific error:
       NumbaTypeError: unsupported array index type OptionalType(array(int64, 1d, A)) in [OptionalType(array(int64, 1d, A))]
  raised from /home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/typing/arraydecl.py:72
During: typing of intrinsic-call at <ipython-input-5-0db23a20b7d4> (5)
File "<ipython-input-5-0db23a20b7d4>", line 5:
def f2(x, mask=None):
    <source elided>
        mask = np.arange(x.size)
    return x[mask]
    ^
```
Looks like `OptionalType` is not correctly handled here.

user: auderson
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7897: state: open
title: Enable setting of kernel attributes via cuFuncSetAttribute
body: Presently we support getting some attributes of a kernel e.g. via `Function.read_func_attr_all`:

https://github.com/numba/numba/blob/59fa2e335be68148b3bd72a29de3ff011430038d/numba/cuda/cudadrv/driver.py#L2482-L2490

However we don't provide a way to set function attributes, which would be useful for example for setting the shared memory carveout (this is an evolution of the functionality provided by [`cache_config()`](https://github.com/numba/numba/blob/59fa2e335be68148b3bd72a29de3ff011430038d/numba/cuda/cudadrv/driver.py#L2464) which allows for finer-grained control over the level of carveout. From the [Ampere Tuning Guide](https://docs.nvidia.com/cuda/ampere-tuning-guide/index.html#l1-cache):

> In the NVIDIA Ampere GPU architecture, the portion of the L1 cache dedicated to shared memory (known as the carveout) can be selected at runtime as in previous architectures such as Volta, using `cudaFuncSetAttribute()` with the attribute `cudaFuncAttributePreferredSharedMemoryCarveout`. The NVIDIA A100 GPU supports shared memory capacity of 0, 8, 16, 32, 64, 100, 132 or 164 KB per SM. GPUs with compute capability 8.6 support shared memory capacity of 0, 8, 16, 32, 64 or 100 KB per SM. 

(cc @gavinpotter)
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7896: state: open
title: `cfunc` unable to compile UDF with record dtype that accesses a record attribute
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

I want to use numba to compile functions that operate on custom numpy dtypes (including record dtypes) to use with `cffi`.  To do this, I use `numba.cfunc` that takes in pointers of the output and input arguments.

Here is a working example that doesn't access a record attribute:
```python
import numba
import numpy as np

record_dtype = np.dtype([("x", np.float64), ("y", np.float64)], align=True)
numba_dtype = numba.typeof(record_dtype)
sample = np.zeros(1, dtype=record_dtype)[0]

##############
# This works #
##############

@numba.njit
def identity(val):
    return val

assert identity(sample) == sample

wrapper_signature = numba.types.void(
    numba.types.CPointer(numba_dtype),
    numba.types.CPointer(numba_dtype),
)

@numba.cfunc(wrapper_signature, nopython=True)
def wrapper(result_ptr, val_ptr):
    result_ptr[0] = identity(val_ptr[0])
```

This fails:
```python
@numba.njit
def get0(val):
    return val[0]

assert get0(sample) == sample[0]

wrapper_signature = numba.types.void(
    numba.types.CPointer(numba.types.float64),
    numba.types.CPointer(numba_dtype),
)

@numba.cfunc(wrapper_signature, nopython=True)  # <-- fails here
def wrapper(result_ptr, val_ptr):
    result_ptr[0] = get0(val_ptr[0])
```
and this fails:
```python
@numba.njit
def getx(val):
    return val["x"]

assert getx(sample) == sample["x"]

wrapper_signature = numba.types.void(
    numba.types.CPointer(numba.types.float64),
    numba.types.CPointer(numba_dtype),
)

@numba.cfunc(wrapper_signature, nopython=True)  # <-- fails here
def wrapper(result_ptr, val_ptr):
    result_ptr[0] = getx(val_ptr[0])
```
Here is a traceback:
```python-traceback
Traceback (most recent call last):
  File "/home/erik/git/grblas/run8.py", line 44, in <module>
    def wrapper(result_ptr, val_ptr):
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/decorators.py", line 282, in wrapper
    res.compile()
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/ccallback.py", line 67, in compile
    cres = self._compile_uncached()
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/ccallback.py", line 81, in _compile_uncached
    return self._compiler.compile(sig.args, sig.return_type)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/dispatcher.py", line 129, in compile
    raise retval
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/dispatcher.py", line 139, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/dispatcher.py", line 152, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler.py", line 693, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler.py", line 429, in compile_extra
    return self._compile_bytecode()
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler.py", line 497, in _compile_bytecode
    return self._compile_core()
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler.py", line 476, in _compile_core
    raise e
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler.py", line 463, in _compile_core
    pm.run(self.state)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 353, in run
    raise patched_exception
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 341, in run
    self._runPass(idx, pass_inst, state)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 296, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 269, in check
    mangled = func(compiler_state)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/typed_passes.py", line 105, in run_pass
    typemap, return_type, calltypes, errs = type_inference_stage(
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/typed_passes.py", line 83, in type_inference_stage
    errs = infer.propagate(raise_errors=raise_errors)
  File "/home/erik/miniconda3/envs/grblas/lib/python3.9/site-packages/numba/core/typeinfer.py", line 1086, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function getitem>) found for signature:

 >>> getitem(dtype(Record(x[type=float64;offset=0],y[type=float64;offset=8];16;True)), Literal[int](0))

There are 22 candidate implementations:
  - Of which 22 did not match due to:
  Overload of function 'getitem': File: <numerous>: Line N/A.
    With argument(s): '(dtype(Record(x[type=float64;offset=0],y[type=float64;offset=8];16;True)), int64)':
   No match.

During: typing of intrinsic-call at /home/erik/git/grblas/run8.py (34)
During: typing of static-get-item at /home/erik/git/grblas/run8.py (34)

File "run8.py", line 34:
def get0(val):
    return val[0]
    ^

During: resolving callee type: type(CPUDispatcher(<function get0 at 0x7f8c300fbd30>))
During: typing of call at /home/erik/git/grblas/run8.py (45)

During: resolving callee type: type(CPUDispatcher(<function get0 at 0x7f8c300fbd30>))
During: typing of call at /home/erik/git/grblas/run8.py (45)


File "run8.py", line 45:
def wrapper(result_ptr, val_ptr):
    result_ptr[0] = get0(val_ptr[0])
    ^
```
And I'm curious: what's the difference between `numba_dtype` and `numba_dtype.dtype`?  I get different errors when I use `numba_dtype.dtype` above in `wrapper_signature `.
```python
In [4]: numba_dtype
Out[4]: dtype(Record(x[type=float64;offset=0],y[type=float64;offset=8];16;True))

In [5]: numba_dtype.dtype
Out[5]: Record(x[type=float64;offset=0],y[type=float64;offset=8];16;True)
```
user: eriknw
issue_7892: state: open
title: Add support for default rcond=None in np.linalg.lstsq
body: As title.

Fixes #7790

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on main/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against main they should
   be resolved by merging main into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: stuartarchibald
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - medium: Medium size effort needed
issue_7888: state: open
title: incorrect float64 type assigned
body: minimal code to replicate

```
@njit(int32(uint64, uint64))
def func(a, b):

    while 1:
        b = b & ~(1 << 1)
    return -1

a = 0b11111
b = 0b10111111000

print(func(a,b))
```

gives

```
No implementation of function Function(<built-in function and_>) found for signature:
 
 >>> and_(float64, Literal[int](-3))
 
There are 6 candidate implementations:
  - Of which 4 did not match due to:
  Overload of function 'and_': File: <numerous>: Line N/A.
    With argument(s): '(float64, int64)':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'and_': File: unknown: Line unknown.
    With argument(s): '(float64, int64)':
   No match for registered cases:
    * (bool, bool) -> bool
    * (int64, int64) -> int64
    * (int64, uint64) -> int64
    * (uint64, int64) -> int64
    * (uint64, uint64) -> uint64

During: typing of intrinsic-call at /Users/vic/Desktop/POKER/VIC_POKER_SRC/v.py (9)

File "v.py", line 9:
def func(a, b):
    <source elided>
    while 1:
        b = b & ~(1 << 1)
```

env

_```
_OS Information__
Platform Name                                 : macOS-10.16-x86_64-i386-64bit
Platform Release                              : 21.3.0
OS Name                                       : Darwin
OS Version                                    : Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64
OS Specific Version                           : 10.16   x86_64
Libc Version                                  : ?

__Python Information__
Python Compiler                               : Clang 10.0.0 
Python Implementation                         : CPython
Python Version                                : 3.9.7
Python Locale                                 : en_AU.UTF-8

__Numba Toolchain Versions__
Numba Version                                 : 0.54.1
llvmlite Version                              : 0.37.0

__LLVM Information__
LLVM Version                                  : 11.1.0
```
user: deus777
labels: bug - typing: Bugs: occuring at typing time
issue_7886: state: open
title: Numba implementation of `numpy.random.vonmises` does not match NumPy
body: It looks like the Numba (version 0.55.1) implementation of `numpy.random.vonmises` is using a different parameterization than NumPy (version 1.21.5):
```python
import numpy as np
import numba as nb


@nb.njit
def vonmises(mu, kappa, size):
    np.random.seed(232)

    res = np.empty(size, dtype=np.float64)
    for n in range(size):
        res[n] = np.random.vonmises(mu, kappa)

    return res


numba_res = vonmises(0.0, 1.0, 1000)
numba_res.mean()
# 3.032362867944328

np.random.seed(232)
exp_res = np.random.vonmises(0.0, 1.0, size=1000)
exp_res.mean()
# 0.047849847034024555
```

If Numba's implementation follows `random.vonmisesvariate`, then the range probably needs to be shifted from `[0, 2 * pi]` to `[-pi, pi]` in order to match NumPy.
user: brandonwillard
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_7879: state: open
title: Type annotations with custom classes are not supported when pickling jitted functions.
body: I run into issues when trying to pickle a numba jitted function (via Dask multiprocessing) that had a type annotated parameter.

The following code (no Dask needed):
```python
from typing import NamedTuple
import pickle
import numba


class Param(NamedTuple):
    x: int
    y: int

@numba.njit
def test_func(param: Param):
    return param.x + param.y


pickle.loads(pickle.dumps(test_func))
```
Results in the following uninformative error:
```python-traceback
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
Input In [6], in <module>
     10 @numba.njit
     11 def test_func(param: Param):
     12     return param.x + param.y
---> 15 pickle.loads(pickle.dumps(test_func))

File ./lib/python3.10/site-packages/numba/core/serialize.py:97, in _unpickle__CustomPickled(serialized)
     92 def _unpickle__CustomPickled(serialized):
     93     """standard unpickling for `_CustomPickled`.
     94 
     95     Uses `NumbaPickler` to load.
     96     """
---> 97     ctor, states = loads(serialized)
     98     return _CustomPickled(ctor, states)

File ./lib/python3.10/site-packages/numba/cloudpickle/cloudpickle.py:740, in _make_skeleton_class(type_constructor, name, bases, type_kwargs, class_tracker_id, extra)
    728 def _make_skeleton_class(type_constructor, name, bases, type_kwargs,
    729                          class_tracker_id, extra):
    730     """Build dynamic class with an empty __dict__ to be filled once memoized
    731 
    732     If class_tracker_id is not None, try to lookup an existing class definition
   (...)
    738     forward compatibility shall the need arise.
    739     """
--> 740     skeleton_class = types.new_class(
    741         name, bases, {'metaclass': type_constructor},
    742         lambda ns: ns.update(type_kwargs)
    743     )
    744     return _lookup_class_or_track(class_tracker_id, skeleton_class)

File ./lib/python3.10/types.py:77, in new_class(name, bases, kwds, exec_body)
     75 if resolved_bases is not bases:
     76     ns['__orig_bases__'] = bases
---> 77 return meta(name, resolved_bases, ns, **kwds)

File ./lib/python3.10/typing.py:2259, in NamedTupleMeta.__new__(cls, typename, bases, ns)
   2252     elif default_names:
   2253         raise TypeError(f"Non-default namedtuple field {field_name} "
   2254                         f"cannot follow default field"
   2255                         f"{'s' if len(default_names) > 1 else ''} "
   2256                         f"{', '.join(default_names)}")
   2257 nm_tpl = _make_nmtuple(typename, types.items(),
   2258                        defaults=[ns[n] for n in default_names],
-> 2259                        module=ns['__module__'])
   2260 # update from user namespace without overriding special namedtuple attributes
   2261 for key in ns:

KeyError: '__module__'
```

It took me a while to figure out that the issue was the type annotation with a custom class. Removing the `: Param` from the `test_func` solves this particular issue. However, I think this is a bug with Numba.

Versions used:
* Numba: 0.55.1
* Python 3.10.2
user: peterroelants
issue_7870: state: open
title: Add support of keyword argument to Dispatchers from `numba.cuda.jit`
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

Currently, the `numba.njit` decorated functions can support keyword arguments and can be invoked as regular python functions (where positional arguments can be interpreted as keywords and etc.)

However, the same is not possible with `numba.cuda.jit` results. This is likely due to the definition of `_KernelConfiguration` (now called [`_LaunchConfiguration`](https://github.com/numba/numba/blob/a38cfe537269f3bdc9c3401bceba588c7ae07c85/numba/cuda/dispatcher.py#L218-L240) that is returned as a result of the `__getitem__` call to a jitted cuda kernel. 

Not sure how this could be accomplished, would it be possible to wrap the original function with the `_LaunchConfiguration` instance that is returned from `__getitem__`?

```py
import numba
import numpy as np
from numba import cuda

@numba.njit
def func_cpu(a, b=0.):
    for i in range(a.shape[0]):
        a[i]+= b

@cuda.jit
def func_cuda(a, b=0.):
    for i in range(a.shape[0]):
        a[i]+= b


# these all work
a = np.random.randn(1000000)
_ = func_cpu(a)
func_cpu(a, b=1.)
func_cpu(a, 2.)

a_g = cuda.to_device(a)
# 1. This works
func_cuda[1,1](a_g, 2.) 

# 2. Raises TypeError:
#    TypeError: Failed in cuda mode pipeline (step: fix up args)
#    Signature mismatch: 1 argument types given, but function takes 2 arguments
func_cuda[1,1](a_g) 

# 3. Raise TypeError:
#    __call__() got an unexpected keyword argument 'b'
func_cuda[1,1](a_g, b=1.)
```
user: TK-21st
labels: CUDA: CUDA related issue/PR
issue_7868: state: open
title: Numba incorrectly interpreting generator function
body: I'm having some trouble JIT-ing a generator function with Numba. Specifically, I'm trying to implement Heap's algorithm for generating permutations of an array given that Numba doesn't work with the itertools package (basically just copying pseudocode from [Wikipedia](https://en.wikipedia.org/wiki/Heap%27s_algorithm)):

```python
import numpy as np
from numba import njit


@njit()
def permutations(arr):

    c = np.zeros(arr.shape[0], dtype=np.int64)
    yield arr
    i = 0
    while i < arr.shape[0]:
        if c[i] < i:
            if i % 2 == 0:
                arr[0], arr[i] = arr[i], arr[0]
            else:
                arr[c[i]], arr[i] = arr[i], arr[c[i]]
            yield arr
            c[i] += 1
            i = 0
        else:
            c[i] = 0
            i += 1
            
            
def main():

    arr = np.array(['A', 'B', 'C', 'D'])
    for permutation in permutations(arr):
        print(permutation)


if __name__ == '__main__':
    main()
```

Without `@njit()`, I get the correct result:

```
['A' 'B' 'C' 'D']
['B' 'A' 'C' 'D']
['C' 'A' 'B' 'D']
['A' 'C' 'B' 'D']
['B' 'C' 'A' 'D']
['C' 'B' 'A' 'D']
['D' 'B' 'A' 'C']
['B' 'D' 'A' 'C']
['A' 'D' 'B' 'C']
['D' 'A' 'B' 'C']
['B' 'A' 'D' 'C']
['A' 'B' 'D' 'C']
['A' 'C' 'D' 'B']
['C' 'A' 'D' 'B']
['D' 'A' 'C' 'B']
['A' 'D' 'C' 'B']
['C' 'D' 'A' 'B']
['D' 'C' 'A' 'B']
['D' 'C' 'B' 'A']
['C' 'D' 'B' 'A']
['B' 'D' 'C' 'A']
['D' 'B' 'C' 'A']
['C' 'B' 'D' 'A']
['B' 'C' 'D' 'A']
```

However, with `@njit()`, I get this output:

```
['A' 'B' 'C' 'D']
['B' 'A' 'C' 'D']
```

As well as this error code: `Process finished with exit code -1073740940 (0xC0000374)`

Platform information:
Python 3.9.5
Numba 0.55.1
Numpy 1.21.5
Windows 10 Home, Version 21H1, OS Build 19043.1526
user: cfandrews
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_7863: state: open
title: Multiple ConcreteTemplates should not be considered separately
body: Functions with multiple ConcreteTemplates must be combined and considered at the same time during function resolution.

The problem is discovered by @testhound in https://github.com/testhound/numba/commit/5188b287d9d7384c388846085ea8416bd7f210a4.

Reproducer:

```python
import numpy as np
from numba import cuda

@cuda.jit
def kernel(arr):
    v = arr[0]
    exp = -v                 # fp16 negate is being considered first; making exp a float64
    arr[0] = exp & 1    # operator.and_ does not support float64

arr = np.zeros(1, dtype=np.intp)
kernel[1, 1](arr)
```
user: sklam
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7862: state: open
title: Wrong results with prange on Linux with Numba 0.55.1
body: Hello,

I have observed an issue with version `0.55.1` which seems to be related to one of the [previously resolved issues involving a race condition](https://github.com/numba/numba/issues/3681). Interestingly, I only observe it on Linux and not on macOS. Here is a simple code snippet that reproduces it:

```python
import numba as nb
import numpy as np


def func_fail(arr):
    res = np.zeros(arr.shape[1])
    for i in nb.prange(arr.shape[0]):
        for j in range(arr.shape[1]):
            res[j] += arr[i][j]
    return res


func_fail_numba = nb.njit(fastmath=True, parallel=True)(func_fail)


def func_success(arr):
    res = np.zeros(arr.shape[1])
    for i in nb.prange(arr.shape[0]):
        res += arr[i]
    return res


func_success_numba = nb.njit(fastmath=True, parallel=True)(func_success)


if __name__ == "__main__":
    assert nb.__version__ == "0.55.1"
    np.random.seed(42)
    arr = np.random.uniform(0, 1, (20, 40))
    assert np.allclose(func_success(arr), func_success_numba(arr))
    assert np.allclose(func_fail(arr), func_fail_numba(arr))

```

Even though `func_success_numba` and `func_fail_numba` should have the same output, only `func_success_numba` returns the same result as the pure Python implementation. In my observations, the final `assert` statement only passes on macOS and not on Linux, even though both have the same `llvmlite` version (`0.38.0`).

user: msuruzhon
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7859: state: open
title: Incorrect behavior with numpy array equality against a scalar unicode string
body: Hello,
I have a different behavior when executing the following code with or with numba:

```python
import numpy as np
import numba as nb
table = np.zeros(2, dtype=([('field1', np.uint8), ('field2', '<U1')]))
table[0] = (1, 'A')
table[1] = (2, 'B')
@nb.njit
def foo(table):
    print(table['field1'] == 1)
    print(table['field2'] == 'A')
    return
foo(table)
```

**Without numba:** (prints two vectors of boolean, OK)
[ True False]
[ True False]

**With numba:** (second print returns just a boolean, NOK)
[ True False]
False


Thanks for your help!
Anthony


user: Anthony-C31
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7857: state: open
title: Using numba and julia (or any other LLVM loader?) at the same time leads to segfaults
body: ## Reporting a bug

- [X] I have tried using the latest released version of Numba
- [X] I have included a self contained code sample to reproduce the problem.

There are several bugs related to julia ([here](https://github.com/JuliaPy/PyCall.jl/issues/903), [here](https://github.com/JuliaPy/pyjulia/issues/443), and [here](https://github.com/cjdoris/PythonCall.jl/issues/115)) that relate to segmentation faults when trying to use numba after julia has loaded.  The segfaults can be triggered either by calling numba from julia, or by calling numba from python after loading julia.  They appear to be due to the fact that julia has already loaded (and presumably used) a different version of libLLVM (currently 12) than numba uses (currently 11).

Julia has implemented symbol versioning in the build of libLLVM that it ships along with julia binaries.  So the [suggestion from the julia side](https://github.com/JuliaLang/julia/issues/12644#issuecomment-1048139525) is that there is likely an ffi call in numba (or maybe llvmlite?) that is missing a library name.

If this is true, then it seems like the bug could be triggered without julia at all, but would require loading (and using?) the different version of libLLVM, which is not something I know how to do.  But it also suggests that this would be a problem any time someone wants to use numba alongside anything that uses a different libLLVM.  So here's the simplest reproducer I can use, which does use julia from python (and therefore assumes julia has also been installed):
```bash
> mamba create -n test_numba_segfault numba
> conda activate test_numba_segfault
> python -m pip install julia
> python
>>> from julia.api import Julia
>>> jl = Julia(compiled_modules=False)
>>> import numba
>>> numba.njit(lambda a, b: a+b)
```


<details>
<summary>The resulting segfault looks like this:</summary>

```
signal (11): Segmentation fault: 11
in expression starting at none:0
_ZN4llvm17PMTopLevelManager16addImmutablePassEPNS_13ImmutablePassE at /Users/me/miniconda3/envs/test_numba_segfault/lib/libLLVM-11.dylib (unknown line)
_ZN4llvm17PMTopLevelManager12schedulePassEPNS_4PassE at /Users/me/miniconda3/envs/test_numba_segfault/lib/libLLVM-11.dylib (unknown line)
_ZN4llvm17PMTopLevelManager12schedulePassEPNS_4PassE at /Users/me/miniconda3/envs/test_numba_segfault/lib/libLLVM-11.dylib (unknown line)
_ZN4llvm18PassManagerBuilder25populateModulePassManagerERNS_6legacy15PassManagerBaseE at /Users/me/miniconda3/envs/test_numba_segfault/lib/libLLVM-11.dylib (unknown line)
ffi_call_unix64 at /Users/me/miniconda3/envs/test_numba_segfault/lib/libffi.8.dylib (unknown line)
ffi_call_int at /Users/me/miniconda3/envs/test_numba_segfault/lib/libffi.8.dylib (unknown line)
_ctypes_callproc at /Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/lib-dynload/_ctypes.cpython-310-darwin.so (unknown line)
PyCFuncPtr_call at /Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/lib-dynload/_ctypes.cpython-310-darwin.so (unknown line)
_PyObject_Call at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_FastCallDictTstate at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
slot_tp_call at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_MakeTpCall at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
method_vectorcall at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_FastCallDictTstate at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
slot_tp_init at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
type_call at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_MakeTpCall at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
method_vectorcall at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_FastCallDictTstate at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
slot_tp_init at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
type_call at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_MakeTpCall at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
object_vacall at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
PyObject_CallFunctionObjArgs at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_GenericGetAttrWithDict at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
property_descr_get at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_GenericGetAttrWithDict at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_FastCallDictTstate at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
slot_tp_init at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
type_call at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyObject_Call at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
PyVectorcall_Call at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
call_function at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_EvalFrameDefault at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyEval_Vector at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
PyRun_InteractiveOneObjectEx at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyRun_InteractiveLoopObject at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
_PyRun_AnyFileObject at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
PyRun_AnyFileExFlags at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
pymain_run_stdin at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
pymain_run_python at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
Py_RunMain at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
pymain_main at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
main at /Users/me/miniconda3/envs/test_numba_segfault/bin/python (unknown line)
Allocations: 34468216 (Pool: 34457208; Big: 11008); GC: 36
Fatal Python error: PyThreadState_Get: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)
Python runtime state: initialized

Current thread 0x000000011429ae00 (most recent call first):
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/llvmlite/binding/ffi.py", line 151 in __call__
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/llvmlite/binding/transforms.py", line 88 in _populate_module_pm
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/llvmlite/binding/transforms.py", line 95 in populate
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/codegen.py", line 1212 in _module_pass_manager
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/codegen.py", line 1191 in _init
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/codegen.py", line 1172 in __init__
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/cpu.py", line 50 in init
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/compiler_lock.py", line 35 in _acquire_compile_lock
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/base.py", line 262 in __init__
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/cpu.py", line 41 in __init__
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/registry.py", line 31 in _toplevel_target_context
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/functools.py", line 981 in __get__
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/registry.py", line 47 in target_context
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/dispatcher.py", line 824 in __init__
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/decorators.py", line 208 in wrapper
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/decorators.py", line 179 in jit
  File "/Users/me/miniconda3/envs/test_numba_segfault/lib/python3.10/site-packages/numba/core/decorators.py", line 258 in njit
  File "<stdin>", line 1 in <module>

Extension modules: numpy.core._multiarray_umath, numpy.core._multiarray_tests, numpy.linalg.lapack_lite, numpy.linalg._umath_linalg, numpy.fft._pocketfft_internal, numpy.random._common, numpy.random.bit_generator, numpy.random._bounded_integers, numpy.random._mt19937, numpy.random.mtrand, numpy.random._philox, numpy.random._pcg64, numpy.random._sfc64, numpy.random._generator, numba.core.typeconv._typeconv, numba._helperlib, numba._dynfunc, numba._dispatcher, numba.core.runtime._nrt_python, numba.np.ufunc._internal, scipy._lib._ccallback_c (total: 21)

signal (6): Abort trap: 6
in expression starting at none:0
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 34468216 (Pool: 34457208; Big: 11008); GC: 36
Abort trap: 6

```

</details>
user: moble
labels: no action required: No action was needed to resolve.
llvm: LLVM related issues
issue_7856: state: open
title: Some random distributions do not accept size=None arguments
body: From a discussion in #7690 

Some of numba's random distribution functions cannot handle size=None arguments, despite size=None being the default value for all of these functions. 

```python
import numpy as np
import numba as nb

# this works
@nb.njit
def nb_chi2(df):
    return np.random.chisquare(df)

nb_chi2(2)

# this also works
np.random.chisquare(2)

# this does not work
@nb.njit
def nb_chi2(df, size):
    return np.random.chisquare(df, size)

nb_chi2(2, None)

# while this does
np.random.chisquare(2, None)
```
This means you have to write something like this everywhere if you want to use np.random.chisquare in a jitted function, though you'd hope that numba's dispatch mechanism would be handling this for you. 

```python
if size is None:
    return np.random.chisquare(df)
else:
    return np.random.chisquare(df, size)
```
Trying the above nonfunctioning function gives this error:
```
              Traceback (most recent call last):
                File "/Users/vhaenel/git/numba/numba/core/types/functions.py", line 308, in get_call_type
                  sig = temp.apply(nolitargs, nolitkws)
                File "/Users/vhaenel/git/numba/numba/core/typing/templates.py", line 351, in apply
                  sig = generic(args, kws)
                File "/Users/vhaenel/git/numba/numba/core/typing/templates.py", line 972, in generic
                  result = self._definition_func(self.context, *args, **kws)
                File "/Users/vhaenel/git/numba/numba/core/overload_glue.py", line 37, in stub
                  return body(tyctx)  # noqa: F821
                File "/Users/vhaenel/git/numba/numba/core/overload_glue.py", line 140, in body
                  sig = typing.apply(ol_args, ol_kwargs)
                File "/Users/vhaenel/git/numba/numba/core/typing/templates.py", line 414, in apply
                  sig = typer(*args, **kws)
                File "/Users/vhaenel/git/numba/numba/core/typing/randomdecl.py", line 277, in typer
                  return self.array_typer(size)(a)
                File "/Users/vhaenel/git/numba/numba/core/typing/randomdecl.py", line 63, in typer
                  shape, ndim = normalize_shape(size)
                File "/Users/vhaenel/git/numba/numba/core/typing/randomdecl.py", line 37, in normalize_shape
                  ndim = len(shape)
              TypeError: object of type 'NoneType' has no len()
```

@stuartarchibald points out that the issue is likely in here.

https://github.com/numba/numba/blob/290bcaa63804fb99b1fe238b0f8fe1caf7686899/numba/core/typing/randomdecl.py#L264-L278


<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

My main question is - is it worth just rewriting these functions to use the new API? It'd be quite a project (that I'm happy to chip away at), but would improve the clarity of randomimpl, which currently uses both extension APIs.

user: rishi-kulkarni
issue_7849: state: open
title: CUDA: `ptx` attribute fails for device function
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Min repro:
```python
from numba import cuda

def f(x):
    return x + 3.14

compiled = cuda.jit("float32(float32)", device=True)(f)
print(compiled.ptx)
```

Failure:
```
Traceback (most recent call last):
  File "/home/yhw/dev/numba_explore/cuda_device_get_ptx.py", line 8, in <module>
    print(compiled.ptx)
  File "/home/yhw/dev/numba/numba/cuda/dispatcher.py", line 909, in ptx
    return {sig: overload.ptx for sig, overload in self.overloads.items()}
  File "/home/yhw/dev/numba/numba/cuda/dispatcher.py", line 909, in <dictcomp>
    return {sig: overload.ptx for sig, overload in self.overloads.items()}
AttributeError: 'CompileResult' object has no attribute 'ptx'
```

Expected result (work around, assuming compiled for current device):

Same as following output.
```python
cc = get_current_device().compute_capability
args, return_type = sigutils.normalize_signature("float32(float32)")
lib = compiled.overloads[args].library
ptx = lib.get_asm_str(cc=cc)
```
user: isVoid
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_7841: state: open
title: Compilation error under parfor in parallel decorator
body: A simple code to shift functions over arbitrary grids does not compile when the "parallel" decorator is set to True. The following code compiles in the serialized version:

```
import numpy as np
from numba import jit, prange


@jit( nopython=True, parallel=True )
def roll_arrays( a, shift_values,x_grid ):
       
    x_max          = np.amax(x_grid)       
    total_items    = a.shape[0]  
    the_ddtype     = a.dtype    
    result         = np.zeros( (a.shape[0], a.shape[1] ), dtype=the_ddtype )
           
    for k in prange( total_items ):        
        edge_val_left  = a[k,0]
        edge_val_right = a[k,-1]  
        #extend grid to edges with boundary values (flat extrapolation)
        extended_boundary = np.abs( shift_values[k] )#positive or negative depending on shift 
        
        if( shift_values[k] != 0.0 ):
                   
            x0_right          = np.linspace( x_max, x_max + extended_boundary, 10 )
            x0_left           = np.linspace( -x_max-extended_boundary, -x_max, 10 )
            if( shift_values[k]>0.0 ):
                #we fill left values
                x_dense_grid  = np.concatenate( ( x0_left, x_grid + shift_values[k] ) )
                x_dense_grid  = np.unique( x_dense_grid )                
                ynew          = np.concatenate(  ( edge_val_left*np.ones( 10 ), a[k,:] )  )            
                
            elif( shift_values[k]<0.0 ):
                x_dense_grid  = np.concatenate( ( x_grid + shift_values[k], x0_right ) )
                x_dense_grid  = np.unique( x_dense_grid )                
                ynew          = np.concatenate(  ( a[k,:], edge_val_right*np.ones( 10 ) )  ) 
            
            max_index     =   x_dense_grid.shape[0] - 1
            mid_x_index   =   np.int( x_dense_grid.shape[0]/2 )
            shift_index   = - ( np.argmin( np.abs( x_dense_grid - shift_values[k]) ) - mid_x_index )                  
                 
            if ( shift_index < 0 ):
                ynew[ max_index+shift_index: ] = edge_val_right*np.ones( np.int(1+ np.abs(shift_index)) )
            elif ( shift_index > 0 ):
                ynew[ 0:shift_index ] = edge_val_left*np.ones( np.int(np.abs(shift_index)) )
            if( shift_index ==0 ):
                print("I'm zero")   
           
            #return on the original grid                       
            f_interp    = np.interp( x_grid, x_dense_grid, ynew )                
            result[k,:] = f_interp  
        
        else:
            #no shift
            result[k,:] = a[k,:]             
    
    return result

x      = np.linspace(-10,10, 2001)
shifts = np.array([-1.0,-2.0,1.0])
f      = np.array( [ k/( x**2 + k**2 ) for k in range(1,shifts.shape[0])  ] )
fs     = roll_arrays( f, shifts, x)

print("done")
```
But when "parallel=True", the following error occurs during compilation:

```
TypeError: Failed in nopython mode pipeline (step: convert to parfors)
object of type 'NoneType' has no len()
```
This has originated from a post in StackOverflow where this was tested on a simplified version of the code, just making use of the `np.concatenate` in this simple example:

```
import numpy as np
from numba import njit, prange
 
# Cause the following error:
#
# TypingError: Failed in nopython mode pipeline (step: convert to parfors)
# No implementation of function Function(<function runtime_broadcast_assert_shapes at 0x0000024DFDE44310>) found for signature:
# 
#  >>> runtime_broadcast_assert_shapes(Literal[int](1), array(float64, 1d, C))
# 
# There are 2 candidate implementations:
#       - Of which 2 did not match due to:
#       Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba\core\extending.py: Line 159.
#         With argument(s): '(int64, array(float64, 1d, C))':
#        Rejected as the implementation raised a specific error:
#          TypeError: missing a required argument: 'arg1'
#   raised from c:\users\me\appdata\local\programs\python\python38\lib\inspect.py:2940
 
@njit('float64(float64)', parallel=True)
def roll_arrays(x):
    a = np.linspace(0, 100, 10)
    b = np.linspace(-10, 10, 2001)
    if x > 0.0:
        tmp = np.concatenate((a, b))
    elif x < 0.0:
        tmp = np.concatenate((b, a))
    return np.abs(tmp).sum()
```


Here is the original post: [https://stackoverflow.com/questions/71080890/numba-compilation-fails-in-parallel-for-loop]

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: gc318
labels: bug - ice: Bugs: internal compiler error
bug - failure to compile: Bugs: failed to compile valid code
issue_7840: state: open
title: Order-preserving slice of a Fortran-ordered array results in an A-ordered array
body: Numba seems to infer an incorrect order from an order-preserving slice of a Fortran-ordered array.

This example illustrates the problem:
```python
import numba
import numpy as np

@numba.jit()
def foo():
    X = np.asfortranarray(np.empty((4, 6)))  # X is a Fortran-ordered array.
    y = X[:, :3] @ np.random.randn(3)  # X[:, :3] should be a Fortran-ordered slice, yet Numba says it's A-ordered.
    return y

>>> foo()
NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 1d, C))
  y = X[:, :3] @ np.random.randn(3)
```
user: lsorber
labels: bug - typing: Bugs: occuring at typing time
issue_7839: state: open
title: Using named tuples of type typing.NamedTuple crashes the kernel
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I just upgraded from Python 3.8.3 and Numba 0.54.1 to Python 3.10.0 and Numba 0.55.1 and most of my code crashes when I use `typing.NamedTuple` class do define named tuples. Sometimes an error `CALL_FUNCTION_EX with **kwargs not supported` is thrown. Are we now forced to use solely `collections.namedtuple`? (which is less flexible as code becomes not readable and there is no support for annotations)

Edit: here's a reproducible example:

```python
from typing import NamedTuple
from numba import njit
import numpy as np

class Order(NamedTuple):
    size: float
    print: float

@njit
def order_nb(size: float = np.inf,
             price: float = np.inf) -> Order:

    return Order(
        float(size),
        float(price)
    )

order_nb()
```

Edit 2: Python 3.9 and Numba 0.55.1 work just fine.
user: polakowo
issue_7838: state: open
title: Array analysis pass is not idempotent
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

We run array analysis multiple times since the IR changes throughout the pipeline and shape information is necessary in various places. However, array analysis doesn't seem to be idempotent and has information loss in subsequent runs. In the example below, `post_wrap_slice_size.7` and `$16binary_subscr.8#0` (output of array slice) are in the same class, but this information is lost in the next run.

```python
import numpy as np
import numba
from numba.core.compiler import DefaultPassBuilder, InlineOverloads
from numba.core.compiler_machinery import FunctionPass, register_pass


@register_pass(analysis_only=False, mutates_CFG=True)
class ArrayAnalysisPass(FunctionPass):
    _name = "array_analysis_pass"

    def __init__(self):
        FunctionPass.__init__(self)

    def run_pass(self, state):
        array_analysis = numba.parfors.array_analysis.ArrayAnalysis(
            state.typingctx,
            state.func_ir,
            state.typemap,
            state.calltypes,
        )
        array_analysis.run(state.func_ir.blocks)
        state.func_ir._definitions = numba.core.ir_utils.build_definitions(
            state.func_ir.blocks
        )
        array_analysis.dump()
        return False


class AnalysisTestPipeline(numba.core.compiler.CompilerBase):

    def define_pipelines(self):
        pm = DefaultPassBuilder.define_nopython_pipeline(self.state)
        pm.add_pass_after(ArrayAnalysisPass, InlineOverloads)
        pm.add_pass_after(ArrayAnalysisPass, InlineOverloads)
        pm.finalize()
        return [pm]


@numba.njit(parallel=True, pipeline_class=AnalysisTestPipeline)
def f(A, c):
    B = np.ones(len(A[c:]))
    return B

A = np.arange(10)
f(A, 3)
```

```
Array Analysis:  {0: SymbolicEquivSet({0: ['A_size0.1', 'A#0'], 2: ['c'], 3: ['slice_size.3'], 4: ['var.5'], 5: ['var.6'], 6: ['post_wrap_slice_size.7', '$16binary_subscr.8#0', '$18call_function.9', 'B#0', '$26return_value.12#0']}, ind_to_var={0: [Var(A_size0.1, wrap_numba.py:42)], 2: [Var(c, wrap_numba.py:42)], 3: [Var(slice_size.3, wrap_numba.py:42)], 4: [Var(var.5, wrap_numba.py:42)], 5: [Var(var.6, wrap_numba.py:42)], 6: [Var(post_wrap_slice_size.7, wrap_numba.py:42), Var($18call_function.9, wrap_numba.py:42)]}, def_by={'A_size0.1': ('A_size0.1', 0), 'c': ('c', 0), 'var.5': ('var.5', 0), 'var.6': ('var.6', 0), '$18call_function.9': ('$18call_function.9', 0)}, ref_by={}, ext_shapes={(2, 0): ['var.5'], (0, 0): ['var.6']})}
Array Analysis:  {0: SymbolicEquivSet({0: ['A_size0.11', 'A#0', 'A_shape.0#0', 'A_size0.1'], 4: ['c'], 5: ['slice_size.3'], 6: ['var.5', 'var.15'], 7: ['var.6', 'var.16'], 8: ['post_wrap_slice_size.7', '$18call_function.9', 'B#0', '$26return_value.12#0'], 9: ['slice_size.13'], 12: ['post_wrap_slice_size.17', '$16binary_subscr.8#0']}, ind_to_var={0: [Var(A_size0.11, wrap_numba.py:42), Var(A_size0.1, wrap_numba.py:42), Var(A_size0.1, wrap_numba.py:42)], 4: [Var(c, wrap_numba.py:42)], 5: [Var(slice_size.3, wrap_numba.py:42)], 9: [Var(slice_size.13, wrap_numba.py:42)], 6: [Var(var.5, wrap_numba.py:42), Var(var.15, wrap_numba.py:42)], 7: [Var(var.6, wrap_numba.py:42), Var(var.16, wrap_numba.py:42)], 12: [Var(post_wrap_slice_size.17, wrap_numba.py:42)], 8: [Var(post_wrap_slice_size.7, wrap_numba.py:42), Var($18call_function.9, wrap_numba.py:42)]}, def_by={'A_size0.11': ('A_size0.11', 0), 'A_size0.1': ('A_size0.1', 0), 'c': ('c', 0), 'var.5': ('var.5', 0), 'var.6': ('var.6', 0), 'var.15': ('var.15', 0), 'var.16': ('var.16', 0)}, ref_by={}, ext_shapes={(4, 0): ['var.5', 'var.15'], (0, 0): ['var.6', 'var.16']})}
```

```
Array Analysis:  {0: SymbolicEquivSet({0: ['A_size0.1', 'A#0'], 2: ['c'], 3: ['slice_size.3'], 4: ['var.5'], 5: ['var.6'], 6: ['post_wrap_slice_size.7', '$16binary_subscr.8#0', '$18call_function.9', 'B#0', '$26return_value.12#0']}, ind_to_var={0: [Var(A_size0.1, wrap_numba.py:43)], 2: [Var(c, wrap_numba.py:43)], 3: [Var(slice_size.3, wrap_numba.py:43)], 4: [Var(var.5, wrap_numba.py:43)], 5: [Var(var.6, wrap_numba.py:43)], 6: [Var(post_wrap_slice_size.7, wrap_numba.py:43), Var($18call_function.9, wrap_numba.py:43)]}, def_by={'A_size0.1': ('A_size0.1', 0), 'c': ('c', 0), 'var.5': ('var.5', 0), 'var.6': ('var.6', 0), '$18call_function.9': ('$18call_function.9', 0)}, ref_by={}, ext_shapes={(2, 0): ['var.5'], (0, 0): ['var.6']})}
label 0:
    A = arg(0, name=A)                       ['A']
    A_shape.0 = getattr(value=A, attr=shape) ['A', 'A_shape.0']
    A_size0.1 = static_getitem(value=A_shape.0, index=0, index_var=None, fn=<built-in function getitem>) ['A_shape.0', 'A_size0.1']
    c = arg(1, name=c)                       ['c']
    $2load_global.0 = global(np: <module 'numpy' from '/Users/ehsan/opt/anaconda3/envs/DEV/lib/python3.9/site-packages/numpy/__init__.py'>) ['$2load_global.0']
    $4load_method.1 = getattr(value=$2load_global.0, attr=ones) ['$2load_global.0', '$4load_method.1']
    $6load_global.2 = global(len: <built-in function len>) ['$6load_global.2']
    $const12.5 = const(NoneType, None)       ['$const12.5']
    $14build_slice.6 = global(slice: <class 'slice'>) ['$14build_slice.6']
    $14build_slice.7 = call $14build_slice.6(c, $const12.5, func=$14build_slice.6, args=(Var(c, wrap_numba.py:43), Var($const12.5, wrap_numba.py:43)), kws=(), vararg=None, target=None) ['$14build_slice.6', '$14build_slice.7', '$const12.5', 'c']
    replacement_slice.2 = call $14build_slice.6(c, A_size0.1, func=$14build_slice.6, args=(Var(c, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43)), kws=(), vararg=None, target=None) ['$14build_slice.6', 'A_size0.1', 'c', 'replacement_slice.2']
    slice_size.3 = A_size0.1 - c             ['A_size0.1', 'c', 'slice_size.3']
    wrap.4 = global(wrap_index: <intrinsic wrap_index>) ['wrap.4']
    var.5 = call wrap.4(c, A_size0.1, func=wrap.4, args=[Var(c, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43)], kws={}, vararg=None, target=None) ['A_size0.1', 'c', 'var.5', 'wrap.4']
    var.6 = call wrap.4(A_size0.1, A_size0.1, func=wrap.4, args=[Var(A_size0.1, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43)], kws={}, vararg=None, target=None) ['A_size0.1', 'A_size0.1', 'var.6', 'wrap.4']
    post_wrap_slice_size.7 = var.6 - var.5   ['post_wrap_slice_size.7', 'var.5', 'var.6']
    $16binary_subscr.8 = getitem(value=A, index=replacement_slice.2, fn=<built-in function getitem>) ['$16binary_subscr.8', 'A', 'replacement_slice.2']
    $18call_function.9 = post_wrap_slice_size.7 ['$18call_function.9', 'post_wrap_slice_size.7']
    B = call $4load_method.1($18call_function.9, func=$4load_method.1, args=[Var($18call_function.9, wrap_numba.py:43)], kws=(), vararg=None, target=None) ['$18call_function.9', '$4load_method.1', 'B']
    $26return_value.12 = cast(value=B)       ['$26return_value.12', 'B']
    return $26return_value.12                ['$26return_value.12']

Array Analysis:  {0: SymbolicEquivSet({0: ['A_size0.11', 'A#0', 'A_shape.0#0', 'A_size0.1'], 4: ['c'], 5: ['slice_size.3'], 6: ['var.5', 'var.15'], 7: ['var.6', 'var.16'], 8: ['post_wrap_slice_size.7', '$18call_function.9', 'B#0', '$26return_value.12#0'], 9: ['slice_size.13'], 12: ['post_wrap_slice_size.17', '$16binary_subscr.8#0']}, ind_to_var={0: [Var(A_size0.11, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43)], 4: [Var(c, wrap_numba.py:43)], 5: [Var(slice_size.3, wrap_numba.py:43)], 9: [Var(slice_size.13, wrap_numba.py:43)], 6: [Var(var.5, wrap_numba.py:43), Var(var.15, wrap_numba.py:43)], 7: [Var(var.6, wrap_numba.py:43), Var(var.16, wrap_numba.py:43)], 12: [Var(post_wrap_slice_size.17, wrap_numba.py:43)], 8: [Var(post_wrap_slice_size.7, wrap_numba.py:43), Var($18call_function.9, wrap_numba.py:43)]}, def_by={'A_size0.11': ('A_size0.11', 0), 'A_size0.1': ('A_size0.1', 0), 'c': ('c', 0), 'var.5': ('var.5', 0), 'var.6': ('var.6', 0), 'var.15': ('var.15', 0), 'var.16': ('var.16', 0)}, ref_by={}, ext_shapes={(4, 0): ['var.5', 'var.15'], (0, 0): ['var.6', 'var.16']})}
label 0:
    A = arg(0, name=A)                       ['A']
    A_shape.10 = getattr(value=A, attr=shape) ['A', 'A_shape.10']
    A_size0.11 = static_getitem(value=A_shape.10, index=0, index_var=None, fn=<built-in function getitem>) ['A_shape.10', 'A_size0.11']
    A_shape.0 = getattr(value=A, attr=shape) ['A', 'A_shape.0']
    A_size0.1 = static_getitem(value=A_shape.0, index=0, index_var=None, fn=<built-in function getitem>) ['A_shape.0', 'A_size0.1']
    c = arg(1, name=c)                       ['c']
    $2load_global.0 = global(np: <module 'numpy' from '/Users/ehsan/opt/anaconda3/envs/DEV/lib/python3.9/site-packages/numpy/__init__.py'>) ['$2load_global.0']
    $4load_method.1 = getattr(value=$2load_global.0, attr=ones) ['$2load_global.0', '$4load_method.1']
    $6load_global.2 = global(len: <built-in function len>) ['$6load_global.2']
    $const12.5 = const(NoneType, None)       ['$const12.5']
    $14build_slice.6 = global(slice: <class 'slice'>) ['$14build_slice.6']
    $14build_slice.7 = call $14build_slice.6(c, $const12.5, func=$14build_slice.6, args=(Var(c, wrap_numba.py:43), Var($const12.5, wrap_numba.py:43)), kws=(), vararg=None, target=None) ['$14build_slice.6', '$14build_slice.7', '$const12.5', 'c']
    replacement_slice.2 = call $14build_slice.6(c, A_size0.1, func=$14build_slice.6, args=(Var(c, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43)), kws=(), vararg=None, target=None) ['$14build_slice.6', 'A_size0.1', 'c', 'replacement_slice.2']
    slice_size.3 = A_size0.1 - c             ['A_size0.1', 'c', 'slice_size.3']
    wrap.4 = global(wrap_index: <intrinsic wrap_index>) ['wrap.4']
    var.5 = call wrap.4(c, A_size0.1, func=wrap.4, args=[Var(c, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43)], kws={}, vararg=None, target=None) ['A_size0.1', 'c', 'var.5', 'wrap.4']
    var.6 = call wrap.4(A_size0.1, A_size0.1, func=wrap.4, args=[Var(A_size0.1, wrap_numba.py:43), Var(A_size0.1, wrap_numba.py:43)], kws={}, vararg=None, target=None) ['A_size0.1', 'A_size0.1', 'var.6', 'wrap.4']
    post_wrap_slice_size.7 = var.6 - var.5   ['post_wrap_slice_size.7', 'var.5', 'var.6']
    slice_size.13 = A_size0.1 - c            ['A_size0.1', 'c', 'slice_size.13']
    wrap.14 = global(wrap_index: <intrinsic wrap_index>) ['wrap.14']
    var.15 = call wrap.14(c, A_size0.11, func=wrap.14, args=[Var(c, wrap_numba.py:43), Var(A_size0.11, wrap_numba.py:43)], kws={}, vararg=None, target=None) ['A_size0.11', 'c', 'var.15', 'wrap.14']
    var.16 = call wrap.14(A_size0.1, A_size0.11, func=wrap.14, args=[Var(A_size0.1, wrap_numba.py:43), Var(A_size0.11, wrap_numba.py:43)], kws={}, vararg=None, target=None) ['A_size0.1', 'A_size0.11', 'var.16', 'wrap.14']
    post_wrap_slice_size.17 = var.16 - var.15 ['post_wrap_slice_size.17', 'var.15', 'var.16']
    $16binary_subscr.8 = getitem(value=A, index=replacement_slice.2, fn=<built-in function getitem>) ['$16binary_subscr.8', 'A', 'replacement_slice.2']
    $18call_function.9 = post_wrap_slice_size.7 ['$18call_function.9', 'post_wrap_slice_size.7']
    B = call $4load_method.1($18call_function.9, func=$4load_method.1, args=[Var($18call_function.9, wrap_numba.py:43)], kws=(), vararg=None, target=None) ['$18call_function.9', '$4load_method.1', 'B']
    $26return_value.12 = cast(value=B)       ['$26return_value.12', 'B']
    return $26return_value.12                ['$26return_value.12']
```
user: ehsantn
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7832: state: open
title: manage_memory() needs a param for extra dtor data
body: DPPY reveals the need for the `manage_memory()` to have a parameter for extra dtor data. This will allow GPU device memory to be tracked by Numba's refcount system and when the refcount reaches 0 the related device allocation will be released. 

Example:

```C

void gpu_dtor(void* device_memory, void *extra_gpu_info) {
    ...
}

nrt_manage_memory(device_memory, gpu_dtor, (void*)extra_gpu_info);
```


Related code:

https://github.com/numba/numba/blob/39f03307113eaf76f0b1308cfbe0c8bf78a5c3e9/numba/core/runtime/nrt_external.h#L41-L46

https://github.com/numba/numba/blob/39f03307113eaf76f0b1308cfbe0c8bf78a5c3e9/numba/core/runtime/nrt.c#L542-L551


CC @PokhodenkoSA @Hardcode84 
user: sklam
issue_7831: state: open
title: Investigation in Dispatcher immortality
body: 
Base on recent [main](https://github.com/numba/numba/commit/39f03307113eaf76f0b1308cfbe0c8bf78a5c3e9) branch.

LLVM MCJIT do not release memory of finalized object:

<details>
<summary>code to demonstrate MCJIT leak</summary>

```python
from llvmlite import binding as llvm
from llvmlite import ir

import psutil
import os
import gc

llvm.initialize()
llvm.initialize_native_asmprinter()
llvm.initialize_native_target()


def make_mod():
    mod = ir.Module()
    foo = ir.Function(mod, ir.FunctionType(ir.VoidType(), ()), "foo")
    builder = ir.IRBuilder(foo.append_basic_block())
    builder.ret_void()
    return mod

def make_engine():
    target = llvm.Target.from_default_triple()
    tm = target.create_target_machine(jit=True)

    llmod = llvm.parse_assembly(str(ir.Module()))
    engine = llvm.create_mcjit_compiler(llmod, tm)
    return engine


the_mod = make_mod()
the_engine = make_engine()


def do():
    llmod = llvm.parse_assembly(str(the_mod))
    the_engine.add_module(llmod)
    the_engine.finalize_object()
    the_engine.remove_module(llmod)

    gc.collect()
    process = psutil.Process(os.getpid())
    mem = process.memory_info()
    print(mem)

if __name__ == "__main__":
    while True:
        do()

```

</details>


Here's code to detect immortal Dispatcher. There's no leaked Dispatcher in the basic case:

<details>
<summary>the code</summary>

```python
from numba import njit


def do():
    @njit
    def foo():
        pass

    @njit
    def bar():
        foo()

    bar()


if __name__ == "__main__":
    for _ in range(100):
        do()

```
</details>

<details>
<summary>the diff to add the counter</summary>

```diff
diff --git a/numba/core/dispatcher.py b/numba/core/dispatcher.py
index c9642f729..4d098f0be 100644
--- a/numba/core/dispatcher.py
+++ b/numba/core/dispatcher.py
@@ -234,6 +234,10 @@ class CompilingCounter(object):
     __nonzero__ = __bool__
 
 
+
+live_dispatcher_count = 0
+
+
 class _DispatcherBase(_dispatcher.Dispatcher):
     """
     Common base class for dispatcher Implementations.
@@ -243,6 +247,9 @@ class _DispatcherBase(_dispatcher.Dispatcher):
 
     def __init__(self, arg_count, py_func, pysig, can_fallback,
                  exact_match_required):
+        global live_dispatcher_count
+        live_dispatcher_count += 1
+        print(f"init live_dispatcher_count = {live_dispatcher_count}")
         self._tm = default_type_manager
 
         # A mapping of signatures to compile results
@@ -278,6 +285,11 @@ class _DispatcherBase(_dispatcher.Dispatcher):
         self._compiling_counter = CompilingCounter()
         weakref.finalize(self, self._make_finalizer())
 
+    def __del__(self):
+        global live_dispatcher_count
+        live_dispatcher_count -= 1
+        print(f'del live_dispatcher_count = {live_dispatcher_count}')
+
     def _compilation_chain_init_hook(self):
         """
         This will be called ahead of any part of compilation taking place (this

```
</details>

The code is ending with `del live_dispatcher_count = 0` indicating that no dispatcher is alive at the program exit.


Related issues: https://github.com/numba/numba/issues/5976 https://github.com/numba/numba/issues/5667

user: sklam
labels: discussion: An issue requiring discussion
issue_7824: state: open
title: `_helperlib.c::import_cython_function` erroneously checks result of `PyCapsule_GetName` against `NULL`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

As title. Reported here: https://github.com/numba/numba/issues/7818#issuecomment-1033649811

The problematic code is:
https://github.com/numba/numba/blob/39f03307113eaf76f0b1308cfbe0c8bf78a5c3e9/numba/_helperlib.c#L565-L568

Variable `capsule_name` should not be checked against `NULL`, `PyCapsule_IsValid` or `PyErr_Occurred` should be used as it is legal for a capsule to have name as `NULL`.

Python docs for the C-API call https://docs.python.org/3/c-api/capsule.html#c.PyCapsule_GetName. 
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7820: state: open
title: numpy array inconsistency
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

The following function works fine outside of numba:
```
def myfun():
    y=np.zeros(10)
    y[0]=np.array([3])
    return y
```

However it fails with numba, as shown here:
```
@jit(nopython=True)
def myfun():
    y=np.zeros(10)
    y[0]=np.array([3])
    return y
```

But can be made to work using:
```
@jit(nopython=True)
def myfun():
    y=np.zeros(10)
    y[0]=np.array([3])[0]
    return y
```

This is awkward behaviour - would be nice if it could be solved. Thanks!

(I am using python 3.10 in conda, with numpy v 1.21.2 and numba v 0.55.0 which is the latest version available in conda). Use the following import statements:
```
import numpy as np
from numba import jit
```

user: amireson
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7819: state: open
title: Reduce inspection of args during kernel launch time
body: @testhound and I were looking at reducing launch time .  We were profiling an empty kernel with 4 args and, unsurprisingly, we see [_prepare_args](https://github.com/numba/numba/blob/f051090b7edd914c18c7fc3a55e97ccd59c2bfc2/numba/cuda/dispatcher.py#L221-L237)  called 4 times (one for each arg).  Collectively, this take 94us and the most recent measurement for [4 arg launch time](https://quasiben.github.io/numba-benchmark-ci/#empty_kernels.time_four_arg_float32) is 198us. Is there a better way of converting args to cyptes ?

<img width="1663" alt="Screen Shot 2022-02-08 at 10 42 02 AM" src="https://user-images.githubusercontent.com/1403768/153022129-db844a65-2def-442a-a683-2f3b4765fc14.png">
 
user: quasiben
labels: CUDA: CUDA related issue/PR
performance - run time: Performance issue occurring at run time.
issue_7818: state: open
title: Calling f2py wrapped code (add an example to documentation)
body: Especially in scipy quite a lot functions are wrapped using f2py. Fortran functions which are wrapped using f2py always  have an [`_cpointer `](https://numpy.org/devdocs/f2py/python-usage.html)` attribute.
It would be good to show an example in the documentation of the [High-level extension API](https://numba.pydata.org/numba-doc/latest/extending/high-level.html#high-level-extension-api) and maybe also implement some useful functions in the extension API.

**Code to extract the function pointer**

```Python
from ctypes import pythonapi
#https://docs.python.org/3/c-api/capsule.html

def capsule_name(capsule):
    pythonapi.PyCapsule_GetName.restype = ctypes.c_char_p
    pythonapi.PyCapsule_GetName.argtypes = [ctypes.py_object]
    return pythonapi.PyCapsule_GetName(capsule)

def get_f2py_function_address(capsule):
    name = capsule_name(capsule)
    pythonapi.PyCapsule_GetPointer.restype = ctypes.c_void_p
    pythonapi.PyCapsule_GetPointer.argtypes = [ctypes.py_object, ctypes.c_char_p]
    return pythonapi.PyCapsule_GetPointer(capsule, name)
```
**Example on scipy.interpolate.dfitpack.splev**

```Python
import numba as nb
import numpy as np
import ctypes
from scipy import interpolate

dble_p=ctypes.POINTER(ctypes.c_double)
int_p =ctypes.POINTER(ctypes.c_longlong)

#Calling siganture
functype = ctypes.CFUNCTYPE(ctypes.c_void_p,
                            dble_p,int_p,dble_p,int_p,dble_p,dble_p,int_p,int_p,int_p)

#Get function pointer and create ctypes function
func_ptr=get_f2py_function_address(interpolate.dfitpack.splev._cpointer)
SPLEV = functype(func_ptr)


#########Intrinsics to efficiently to pass scalars by ref#############
#Workaround using stack-allocated arrays, faster than heap-allocated arrays.
#This could be relevant on functions with short runtimes.
from numba import types
from numba.extending import intrinsic
from numba.core import cgutils

@intrinsic
def val_to_ptr(typingctx, data):
    def impl(context, builder, signature, args):
        ptr = cgutils.alloca_once_value(builder,args[0])
        return ptr
    sig = types.CPointer(nb.typeof(data).instance_type)(nb.typeof(data).instance_type)
    return sig, impl

@intrinsic
def ptr_to_val(typingctx, data):
    def impl(context, builder, signature, args):
        val = builder.load(args[0])
        return val
    sig = data.dtype(types.CPointer(data.dtype))
    return sig, impl

#####################################################################

@nb.njit('float64[::1](float64[::1],float64[::1],int64,float64[::1],int64)')
def splev_wrapped(t,c,k,x,e):
    y=np.empty(x.shape[0],dtype=np.float64)
    
    n_arr=val_to_ptr(nb.int64(t.shape[0]))
    k_arr=val_to_ptr(nb.int64(k))
    m_arr=val_to_ptr(nb.int64(x.shape[0]))
    e_arr=val_to_ptr(nb.int64(e))
    ier_arr=val_to_ptr(nb.int64(0))
    
    SPLEV(t.ctypes,n_arr,c.ctypes,k_arr,x.ctypes,
        y.ctypes,m_arr,e_arr,ier_arr)
    
    return y
```





user: max9111
labels: scipy: Requests for scipy features
scumba: Issue relating to SciPy support that could exist in Numba "Scumba!"
issue_7811: state: open
title: Assignment of jitclass-owned array fails when list comprehension is used in the calling function
body: With numba  0.55.1.

Consider the following code:
```
import numpy as np
from numba import njit
from numba.experimental import jitclass
from numba import float64    # import the types

spec = [
    ('var', float64[:]),          
]
@jitclass(spec)
class varClass():
    def __init__(self, a):
        self.var = np.array([a])


@njit
def printVar():
    
    vinst = varClass(1.)
    print(vinst.var)
    vinst.var[0] = 0.0
    print(vinst.var)
    
    # Uncommenting this line breaks the var update
    # positionsPartGroups = [i for i in range(10)]   

printVar()

```

If I run the script, the output is:
```
[1.]
[0.]
```
which is correct.

If I uncomment the last line of the _printVar_ function, which should have no effect, the output is
```
[1.]
[1.]
```
which is not correct.


Note that building the list with a loop works:
```
positionPartGroups= []
    for i in range(10):
        positionPartGroups.append(i)
```
user: sebbelese
labels: bug - miscompile: Bugs: miscompile
issue_7808: state: open
title: has no attribute `class_type` when running `NUMBA_DISABLE_JIT`
body: ```python
integrator_spec = [
    ("model", NumbaModel.class_type.instance_type),
    ("plasma", NumbaPlasma.class_type.instance_type),
    ("points", int64),
]
```

This does not work in `DISABLE_JIT_MODE` that we use for debugging. `numba==0.53.0` 
user: wkerzendorf
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7794: state: open
title: numba 0.55.0 on `defaults` doesn't constrain numpy as expected
body: When using Conda to create an environment with both Numba and NumPy, I notice that the linux-64 numba 0.55.0 package hosted on `defaults` doesn't respect the max version constraint for NumPy like the `conda-forge` package does; this means it is possible to create an environment with numba 0.55 and numpy 1.22, which results in an `ImportError` when trying to import numba:

```bash
$ mamba create -n test numba=0.55 numpy=1.22
...
  + numba                0.55.0  py310h00e6091_0      pkgs/main/linux-64       Cached
  + numpy                1.22.1  py310h454958d_0      conda-forge/linux-64     Cached
```

If we limit the environment creation to only use `conda-forge`, this constraint is properly respected:

```bash
$ mamba create --override-channels -c conda-forge -n test numba=0.55 numpy=1.22
...
Encountered problems while solving:
  - package numba-0.55.0-py37h2d894fd_0 has constraint numpy >=1.18,<1.22 conflicting with numpy-1.22.0-py310h454958d_0
```

Is this different behavior between the two packages expected? I notice that before, the `defaults` hosted packages seemed to respect this constraint:

```bash
$ mamba create --override-channels -c defaults -n test numba=0.54 numpy=1.21
...
Encountered problems while solving:
  - package numba-0.54.1-py37h51133e4_0 has constraint numpy >=1.17,<1.21 conflicting with numpy-1.21.2-py310h20f2e39_0
```

For context, I observed this issue in https://github.com/dask-contrib/dask-sql/pull/383 - [here](https://github.com/dask-contrib/dask-sql/runs/4955701235?check_suite_focus=true) is an example of potential downstream failures that can occur as a result of this. 
user: charlesbluca
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_7790: state: open
title: np1.14+ np.linalg.lstsq has `rcond="warn"` as default and a "new" proposed default of None
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [N/A] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

NumPy 1.14+ function `np.linalg.lstsq` has `rcond="warn"` as default and a "new" proposed default of `None` see:
https://github.com/numpy/numpy/blob/maintenance/1.21.x/numpy/linalg/linalg.py#L2170 
and
https://github.com/numpy/numpy/blob/maintenance/1.21.x/numpy/linalg/linalg.py#L2282-L2294 

whereas the Numba impl has `rcond` as `-1.0` which is the default prior to np 1.14.
https://github.com/numba/numba/blob/324dd8f14aa83404ab6d0e51c5e25665dd89ed8d/numba/np/linalg.py#L1583


user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7784: state: open
title: support  `assume_unique` and `return_indices` arguments in `numpy.intersect1d`
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Current implementation of `numpy.intersect1d` do not support the keyword arguments.

https://github.com/numba/numba/blob/2a792155c3dce43f86b9ff93802f12d39a3752dc/numba/np/arraymath.py#L3651-L3655

It looks like the supporting the keyword arguments should be possible. See [numpy source](https://github.com/numpy/numpy/blob/4adc87dff15a247e417d50f10cc4def8e1c17a03/numpy/lib/arraysetops.py#L447-L465)
user: sklam
issue_7775: state: open
title: Fix DI generation for array exprs
body: Numba's DI generation for array expressions leads to strange behaviour in gdb. Issues include:
* Stepping into an array expression lands here: https://github.com/numba/numba/blob/14b170a11c9b3e546b24943ffc446e152093080d/numba/np/npyimpl.py#L190-L205
* If https://github.com/numba/numba/blob/14b170a11c9b3e546b24943ffc446e152093080d/numba/np/npyimpl.py#L190 is stepped through until finish and then stepped over the next executable line is reported as line 1 of the file containing the array expr.
* Once on line 1, continued stepping repeatedly reports the same location with varying input values, though it will eventually step back into the calling function.

As noted here: https://github.com/numba/numba/pull/7752#issuecomment-1018394185 the fix may be to just omit DI for array expressions.
user: stuartarchibald
labels: discussion: An issue requiring discussion
bug - DWARF: Bugs related to debugging support
issue_7774: state: open
title: inconsistent array order  for bare and qualified jit decorator
body: Consider the following code:

```
import functools
import numpy as np
import numba as nb

N = 4
M = 2
a = np.arange(M*N, dtype=np.float64).reshape(M, N).T
b = np.ones(M, dtype=np.float64)

def calc0(x, y, out=None):
    op = np.multiply
    it = np.nditer((x, y, None), [], [['readonly'], ['readonly'], ['writeonly', 'allocate']])
    for (a, b, c) in it:                                
        op(a, b, out=c)
    return it.operands[2]

@nb.njit
def calc1(x, y, out):
    it = np.nditer((x, y))
    for i, (u, v) in enumerate(it):
        out[i] = u * v
        
@nb.njit(nb.void(nb.float64[:,:], nb.float64[:], nb.float64[:]))
def calc2(x, y, out):
    it = np.nditer((x, y))
    for i, (u, v) in enumerate(it):
        out[i] = u * v
        
def calc1_wrap(x, y):
    shape = np.broadcast_shapes(x.shape, y.shape)
    size = functools.reduce(lambda u, v: u*v, shape)
    out = np.empty(size, dtype=np.float64)
    calc1(x, y, out)
    return out.reshape(shape)
        
def calc2_wrap(x, y):
    shape = np.broadcast_shapes(x.shape, y.shape)
    size = functools.reduce(lambda u, v: u*v, shape)
    out = np.empty(size, dtype=np.float64)
    calc2(x, y, out)
    return out.reshape(shape)

a * b
calc0(a, b)
calc1_wrap(a, b)
calc2_wrap(a, b)
        
calc1.signatures
calc2.signatures
```
The output is:
```
array([[0., 4.],
       [1., 5.],
       [2., 6.],
       [3., 7.]])

array([[0., 4.],
       [1., 5.],
       [2., 6.],
       [3., 7.]])

array([[0., 1.],
       [2., 3.],
       [4., 5.],
       [6., 7.]])

array([[0., 4.],
       [1., 5.],
       [2., 6.],
       [3., 7.]])

[(array(float64, 2d, F), array(float64, 1d, C), array(float64, 1d, C))]
[(array(float64, 2d, A), array(float64, 1d, A), array(float64, 1d, A))]
```
The third array stands out. It seems that the bare ``@njit`` assumes that the ``a`` is in Fortran order. This is not consistent with numpy behaviour. Is there a reason for this, or a minor bug? 

One could argue that numpy documentation is misleading: https://numpy.org/doc/stable/reference/generated/numpy.nditer.html?highlight=nditer#numpy.nditer

user: yt87
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7773: state: open
title: Object mode fall back control flow issue, hits opcode RERAISE
body: I got the following error message when I used the @jit decorator on the function below the error message. This is not the biggest deal but it said to report it so I did.
    
    Traceback (most recent call last):
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/errors.py", line 776, in new_error_context
        yield
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/lowering.py", line 235, in lower_block
        self.lower_inst(inst)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/pylowering.py", line 168, in lower_inst
        raise NotImplementedError(type(inst), inst)
    NotImplementedError: (<class 'numba.core.ir.StaticRaise'>, <numba.core.ir.StaticRaise object at 0x7f94bc91b5b0>)
    
    During handling of the above exception, another exception occurred:
    
    Traceback (most recent call last):
      File "/home/brodkemd/Documents/ns_q/python_version/ns_q.py", line 1644, in <module>
        run()
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/dispatcher.py", line 501, in _compile_for_args
        raise e
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/dispatcher.py", line 434, in _compile_for_args
        return_val = self.compile(tuple(argtypes))
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/dispatcher.py", line 979, in compile
        cres = self._compiler.compile(args, return_type)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/dispatcher.py", line 141, in compile
        status, retval = self._compile_cached(args, return_type)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/dispatcher.py", line 155, in _compile_cached
        retval = self._compile_core(args, return_type)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/dispatcher.py", line 168, in _compile_core
        cres = compiler.compile_extra(self.targetdescr.typing_context,
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler.py", line 686, in compile_extra
        return pipeline.compile_extra(func)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler.py", line 428, in compile_extra
        return self._compile_bytecode()
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler.py", line 492, in _compile_bytecode
        return self._compile_core()
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler.py", line 471, in _compile_core
        raise e
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler.py", line 462, in _compile_core
        pm.run(self.state)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 343, in run
        raise patched_exception
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 334, in run
        self._runPass(idx, pass_inst, state)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
        return func(*args, **kwargs)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
        mutated |= check(pss.run_pass, internal_state)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/compiler_machinery.py", line 262, in check
        mangled = func(compiler_state)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/object_mode_passes.py", line 120, in run_pass
        lowered = backend_object_mode()
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/object_mode_passes.py", line 115, in backend_object_mode
        return self._py_lowering_stage(state.targetctx,
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/object_mode_passes.py", line 78, in _py_lowering_stage
        lower.lower()
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/lowering.py", line 138, in lower
        self.lower_normal_function(self.fndesc)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/lowering.py", line 192, in lower_normal_function
        entry_block_tail = self.lower_function_body()
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/lowering.py", line 221, in lower_function_body
        self.lower_block(block)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/lowering.py", line 235, in lower_block
        self.lower_inst(inst)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/contextlib.py", line 137, in __exit__
        self.gen.throw(typ, value, traceback)
      File "/home/brodkemd/anaconda3/envs/qiskit/lib/python3.9/site-packages/numba/core/errors.py", line 786, in new_error_context
        raise newerr.with_traceback(tb)
    numba.core.errors.LoweringError: Failed in object mode pipeline (step: object mode backend)
    (<class 'numba.core.ir.StaticRaise'>, <numba.core.ir.StaticRaise object at 0x7f94bc91b5b0>)
    
    File "ns_q.py", line 1642:
    def run():
        <source elided>
            if option:
                inst.WriteResults()
                ^
    
    During: lowering "<static> raise <class 'AssertionError'>("Unreachable condition reached (op code RERAISE executed)\n-------------------------------------------------------------------------------\nThis should not have happened, a problem has occurred in Numba's internals.\nYou are currently using Numba version 0.54.1.\n\nPlease report the error message and traceback, along with a minimal reproducer\nat: https://github.com/numba/numba/issues/new\n\nIf more help is needed please feel free to speak to the Numba core developers\ndirectly at: https://gitter.im/numba/numba\n\nThanks in advance for your help in improving Numba!\n\n")" at /home/brodkemd/Documents/ns_q/python_version/ns_q.py (1642)


When the decorator is removed it works as intended.
Here is the Function:
  
    @jit
    def run():
        inst = ns_q()
        # catches keyboard interupts and asks if you want the data from the run
        try:
            inst.run()
        except KeyboardInterrupt:
            print("\n\nExecution halted")
            option = int(input("Do you want to record the data that was generated(1=yes, 0=no)?:"))
            # saves the data
            if option:
                inst.WriteResults()

user: brodkemd
labels: objectmode: object mode related issue
bug - failure to compile: Bugs: failed to compile valid code
bug - incorrect behavior: Bugs: incorrect behavior
issue_7767: state: open
title: Partial support only for `np.ndarray.sort` / support `np.ndarray.sort(axis=...)`
body: ## Reporting a bug
In numba version 0.55 python 3.8, there's no support for sortting a multidimensional array. Consider the following code:

```python
@njit
def sort_multidimensional_arr(arr: np.ndarray) -> np.ndarray:
    arr = arr.reshape(-1, 2)
    arr.sort()

sort_multidimensional_arr(np.arange(10, dtype=int))
```

It results in the following result:
```
Invalid use of BoundFunction(array.sort for array(int64, 2d, C)) with parameters ()

During: resolving callee type: BoundFunction(array.sort for array(int64, 2d, C))
During: typing of call at /home/razor/PycharmProjects/datamind_train_infra/dmcommon-submodule/dmcommon/data_classes/time_types/optimized.py (9)


File "optimized.py", line 9:
def sort_multidimensional_arr(arr: np.ndarray) -> np.ndarray:
    <source elided>
    arr = arr.reshape(-1, 2)
    arr.sort()
    ^


Process finished with exit code 1
```

I may be able to get around it using `arr[:, 0].argsort()`, but for larger arrays the overhead in this becomes substantial.
user: erezinman
issue_7765: state: open
title: Update versioneer to enable Python 3.11
body: versioneer must be updated as the older versions use stuff that is removed in Python 3.11.

So while this may not be enough to run on Python 3.11, it is at least required at some stage. 

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

## Reference an existing issue
<!-- You can link to an existing issue using the github syntax #<issue number>  -->

user: oscargus
issue_7762: state: open
title: Remove duplication of `run_cmd` function, make it a utility.
body: The function `run_cmd` (and variants of) appears a lot in the code base, it's multiply defined:
https://github.com/numba/numba/search?q=run_cmd&type=code

This ticket is a reminder to factor this function out into `numba.core.utils`.
user: stuartarchibald
issue_7761: state: open
title: Typing difference
body: 
The following typing difference was reported by a user:

1) divide int64 by float32 should yield float32 

```python
import numpy as np
import numba

a = np.array([1, 2, 3], dtype=np.int64)
b = np.array([4.4, 5.5, 6.6], dtype=np.float32)

def foo():
    return a / b


jit_foo = numba.njit(foo)

print(foo().dtype)
print(jit_foo().dtype)

```

2) invert on boolean should yield integer.

So, this means there is no `~` on bools.


```python
import numba

def foo(a):
    return ~a

jit_foo = numba.njit(foo)

print(foo(True))
print(jit_foo(True))
```


user: sklam
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7753: state: open
title: performance regression with enumerate since 0.49
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

It seems like using `enumerate(x)` over `range(len(x))` disables SIMD generation.

```python
import numba as nb
import numpy as np

@nb.njit
def test_enumerate(a, b):
    for i, x in enumerate(a):
        b[i] = x

@nb.njit
def test_range(a, b):
    for i in range((len(a))):
        b[i] = a[i]

test_enumerate(np.arange(3, dtype=np.int64), np.empty(3, dtype=np.int64))
test_range(np.arange(3, dtype=np.int64), np.empty(3, dtype=np.int64))
```

<details>
<summary>produces similar results in 0.48, but in 0.49+</summary>

```asm
------------------------------ASSEMBLY test_range-------------------------------
	.section	__TEXT,__text,regular,pure_instructions
	.build_version macos, 12, 0
	.globl	__ZN8__main__14test_range_242B42c8tJTIeFCjyCbUFRqqOAK_2f6h0kCng1maAA_3d_3dE5ArrayIxLi1E1C7mutable7alignedE5ArrayIxLi1E1C7mutable7alignedE
	.p2align	4, 0x90
__ZN8__main__14test_range_242B42c8tJTIeFCjyCbUFRqqOAK_2f6h0kCng1maAA_3d_3dE5ArrayIxLi1E1C7mutable7alignedE5ArrayIxLi1E1C7mutable7alignedE:
	pushq	%rbx
	movq	24(%rsp), %r8
	testq	%r8, %r8
	jle	LBB0_18
	movq	72(%rsp), %r11
	movq	16(%rsp), %rbx
	cmpq	$16, %r8
	jb	LBB0_2
	leaq	(%rbx,%r8,8), %rax
	cmpq	%r11, %rax
	jbe	LBB0_6
	leaq	(%r11,%r8,8), %rax
	cmpq	%rbx, %rax
	jbe	LBB0_6
LBB0_2:
	xorl	%esi, %esi
LBB0_14:
	movq	%rsi, %r9
	notq	%r9
	addq	%r8, %r9
	movq	%r8, %rcx
	andq	$7, %rcx
	je	LBB0_19
	.p2align	4, 0x90
LBB0_15:
	leaq	1(%rsi), %rax
	movq	(%rbx,%rsi,8), %rdx
	movq	%rdx, (%r11,%rsi,8)
	movq	%rax, %rsi
	decq	%rcx
	jne	LBB0_15
	cmpq	$7, %r9
	jb	LBB0_18
	jmp	LBB0_17
LBB0_19:
	movq	%rsi, %rax
	cmpq	$7, %r9
	jb	LBB0_18
	.p2align	4, 0x90
LBB0_17:
	movq	(%rbx,%rax,8), %rcx
	movq	%rcx, (%r11,%rax,8)
	movq	8(%rbx,%rax,8), %rcx
	movq	%rcx, 8(%r11,%rax,8)
	movq	16(%rbx,%rax,8), %rcx
	movq	%rcx, 16(%r11,%rax,8)
	movq	24(%rbx,%rax,8), %rcx
	movq	%rcx, 24(%r11,%rax,8)
	movq	32(%rbx,%rax,8), %rcx
	movq	%rcx, 32(%r11,%rax,8)
	movq	40(%rbx,%rax,8), %rcx
	movq	%rcx, 40(%r11,%rax,8)
	movq	48(%rbx,%rax,8), %rcx
	movq	%rcx, 48(%r11,%rax,8)
	movq	56(%rbx,%rax,8), %rcx
	movq	%rcx, 56(%r11,%rax,8)
	leaq	8(%rax), %rcx
	movq	%rcx, %rax
	cmpq	%rcx, %r8
	jne	LBB0_17
	jmp	LBB0_18
LBB0_6:
	movq	%r8, %rsi
	andq	$-16, %rsi
	leaq	-16(%rsi), %rax
	movq	%rax, %r10
	shrq	$4, %r10
	incq	%r10
	movl	%r10d, %r9d
	andl	$3, %r9d
	cmpq	$48, %rax
	jae	LBB0_8
	xorl	%eax, %eax
	jmp	LBB0_10
LBB0_8:
	andq	$-4, %r10
	xorl	%eax, %eax
	.p2align	4, 0x90
LBB0_9:
	vmovups	(%rbx,%rax,8), %ymm0
	vmovups	32(%rbx,%rax,8), %ymm1
	vmovups	64(%rbx,%rax,8), %ymm2
	vmovups	96(%rbx,%rax,8), %ymm3
	vmovups	%ymm0, (%r11,%rax,8)
	vmovups	%ymm1, 32(%r11,%rax,8)
	vmovups	%ymm2, 64(%r11,%rax,8)
	vmovups	%ymm3, 96(%r11,%rax,8)
	vmovups	128(%rbx,%rax,8), %ymm0
	vmovups	160(%rbx,%rax,8), %ymm1
	vmovups	192(%rbx,%rax,8), %ymm2
	vmovups	224(%rbx,%rax,8), %ymm3
	vmovups	%ymm0, 128(%r11,%rax,8)
	vmovups	%ymm1, 160(%r11,%rax,8)
	vmovups	%ymm2, 192(%r11,%rax,8)
	vmovups	%ymm3, 224(%r11,%rax,8)
	vmovups	256(%rbx,%rax,8), %ymm0
	vmovups	288(%rbx,%rax,8), %ymm1
	vmovups	320(%rbx,%rax,8), %ymm2
	vmovups	352(%rbx,%rax,8), %ymm3
	vmovups	%ymm0, 256(%r11,%rax,8)
	vmovups	%ymm1, 288(%r11,%rax,8)
	vmovups	%ymm2, 320(%r11,%rax,8)
	vmovups	%ymm3, 352(%r11,%rax,8)
	vmovups	384(%rbx,%rax,8), %ymm0
	vmovups	416(%rbx,%rax,8), %ymm1
	vmovups	448(%rbx,%rax,8), %ymm2
	vmovups	480(%rbx,%rax,8), %ymm3
	vmovups	%ymm0, 384(%r11,%rax,8)
	vmovups	%ymm1, 416(%r11,%rax,8)
	vmovups	%ymm2, 448(%r11,%rax,8)
	vmovups	%ymm3, 480(%r11,%rax,8)
	addq	$64, %rax
	addq	$-4, %r10
	jne	LBB0_9
LBB0_10:
	testq	%r9, %r9
	je	LBB0_13
	leaq	96(,%rax,8), %rax
	negq	%r9
	.p2align	4, 0x90
LBB0_12:
	vmovups	-96(%rbx,%rax), %ymm0
	vmovups	-64(%rbx,%rax), %ymm1
	vmovups	-32(%rbx,%rax), %ymm2
	vmovups	(%rbx,%rax), %ymm3
	vmovups	%ymm0, -96(%r11,%rax)
	vmovups	%ymm1, -64(%r11,%rax)
	vmovups	%ymm2, -32(%r11,%rax)
	vmovups	%ymm3, (%r11,%rax)
	subq	$-128, %rax
	incq	%r9
	jne	LBB0_12
LBB0_13:
	cmpq	%r8, %rsi
	jne	LBB0_14
LBB0_18:
	movq	$0, (%rdi)
	xorl	%eax, %eax
	popq	%rbx
	vzeroupper
	retq

----------------------------ASSEMBLY test_enumerate-----------------------------
	.section	__TEXT,__text,regular,pure_instructions
	.build_version macos, 12, 0
	.globl	__ZN8__main__18test_enumerate_241B42c8tJTIeFCjyCbUFRqqOAK_2f6h0kCng1maAA_3d_3dE5ArrayIxLi1E1C7mutable7alignedE5ArrayIxLi1E1C7mutable7alignedE
	.p2align	4, 0x90
__ZN8__main__18test_enumerate_241B42c8tJTIeFCjyCbUFRqqOAK_2f6h0kCng1maAA_3d_3dE5ArrayIxLi1E1C7mutable7alignedE5ArrayIxLi1E1C7mutable7alignedE:
	.cfi_startproc
	pushq	%rbx
	.cfi_def_cfa_offset 16
	.cfi_offset %rbx, -16
	movq	24(%rsp), %r9
	testq	%r9, %r9
	jle	LBB0_8
	movq	72(%rsp), %r10
	movq	32(%rsp), %r11
	movq	16(%rsp), %rsi
	leaq	-1(%r9), %rcx
	movl	%r9d, %r8d
	andl	$7, %r8d
	cmpq	$7, %rcx
	jae	LBB0_3
	xorl	%edx, %edx
	jmp	LBB0_5
LBB0_3:
	andq	$-8, %r9
	xorl	%edx, %edx
	movq	%rsi, %rcx
	.p2align	4, 0x90
LBB0_4:
	movq	(%rcx), %rax
	movq	%rax, (%r10,%rdx,8)
	leaq	(%r11,%rcx), %rax
	movq	(%r11,%rcx), %rcx
	movq	%rcx, 8(%r10,%rdx,8)
	leaq	(%r11,%rax), %rcx
	movq	(%r11,%rax), %rax
	movq	%rax, 16(%r10,%rdx,8)
	leaq	(%r11,%rcx), %rax
	movq	(%r11,%rcx), %rcx
	movq	%rcx, 24(%r10,%rdx,8)
	leaq	(%r11,%rax), %rcx
	movq	(%r11,%rax), %rax
	movq	%rax, 32(%r10,%rdx,8)
	leaq	(%r11,%rcx), %rax
	movq	(%r11,%rcx), %rcx
	movq	%rcx, 40(%r10,%rdx,8)
	leaq	(%r11,%rax), %rbx
	movq	(%r11,%rax), %rax
	movq	%rax, 48(%r10,%rdx,8)
	leaq	(%r11,%rbx), %rcx
	movq	(%r11,%rbx), %rax
	movq	%rax, 56(%r10,%rdx,8)
	addq	$8, %rdx
	addq	%r11, %rcx
	cmpq	%rdx, %r9
	jne	LBB0_4
LBB0_5:
	testq	%r8, %r8
	je	LBB0_8
	leaq	(%r10,%rdx,8), %rcx
	imulq	%r11, %rdx
	addq	%rdx, %rsi
	xorl	%edx, %edx
	.p2align	4, 0x90
LBB0_7:
	movq	(%rsi), %rax
	movq	%rax, (%rcx,%rdx,8)
	incq	%rdx
	addq	%r11, %rsi
	cmpq	%rdx, %r8
	jne	LBB0_7
LBB0_8:
	movq	$0, (%rdi)
	xorl	%eax, %eax
	popq	%rbx
	retq
	.cfi_endproc
```

</details>
user: s22chan
labels: performance - run time: Performance issue occurring at run time.
issue_7750: state: open
title: "Iteration" over empty containers
body: Fixes #7245. This PR includes an optimization pass that removes the loop if it is done over an empty container
user: guilhermeleobas
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - long: Long size effort needed
issue_7743: state: open
title: Make it possible to launch CUDA kernels from CPU JIT code regions.
body: Once https://github.com/numba/numba/issues/7742 is complete, most of the work necessary to make it possible to launch CUDA kernels from CPU JIT code regions will be done. The remaining task is to (probably, as it's not entirely clear how this will work yet):
* Create a configurable dispatcher (ABC or similar?) that extends from the `numba.core.dispatcher` class as an identifier that this type of dispatcher needs configurable launch configuration support (i.e. the `kernel[x, y, z](*args)` `__getitem__` overloaded syntax).
* Make the CUDA dispatcher inherit from the above.
* Implement the `__getitem__` overloads for the CUDA dispatcher type as CPU JIT code.
* Make sure the type system/lowering understands the above.

user: stuartarchibald
labels: CUDA: CUDA related issue/PR
issue_7742: state: open
title: Reduce the CUDA target launch overhead by JIT compiling the launch code
body: Currently the CUDA target prepares for launch and is launched entirely from Python code. This should be replaced by CPU JIT code such that the launches are free of python, this reducing the launch overhead. Further, it is a large step in the direction of making it possible to launch CUDA kernels from CPU JIT regions.

For simplicity, depends on https://github.com/numba/numba/issues/7741
user: stuartarchibald
labels: CUDA: CUDA related issue/PR
issue_7737: state: open
title: Tidy up memmove/memcpy APIs
body: This cleans up the `memcpy` / `memmove` APIs and implementation.

- There is now only one `memcpy` implementation, instead of one using the intrinsic and one using a loop - the implementation always uses the intrinsic now.
- The `align` parameter is removed, which was probably a vestige from an earlier LLVM version and only served to confuse as it was not used.
- The APIs permit using a form where either the length is supplied, or a count and item size are supplied - if the count and item size are supplied, and appropriate multiplication is generated.
- Updated docstrings for these functions.
- Replaced uses of `raw_memcpy` / `raw_memmove` with `memcpy` / `memmove`.

Fixes #7734.
user: gmarkall
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
Effort - medium: Medium size effort needed
issue_7734: state: open
title: `memcpy_region` looks suspiciously wrong
body: https://github.com/numba/numba/blob/f427bd63bbe89a32f16c58d5e01c5867902abefb/numba/core/unsafe/bytes.py#L36-L49

Here `cgutils.raw_memcpy()` is used as:

```python
cgutils.raw_memcpy(builder, dst_ptr, src_ptr, nbytes_val, align_val)
```

whereas `raw_memcpy()` is defined as:

https://github.com/numba/numba/blob/f427bd63bbe89a32f16c58d5e01c5867902abefb/numba/core/cgutils.py#L1051

so this looks like a call to `raw_memcpy` where the `count` is the total number of bytes to copy, and the `itemsize` is the value of `align_val` (which is probably equivalent to 1 in a lot of cases, so this is probably wrong but gets away with it in most cases).
user: gmarkall
issue_7727: state: open
title: improve performance of numba.typed.List constructor with Python list as arg
body: Thanks for making Numba, it is a fantastic tool!

## Background

I have several functions where it is most natural to take Python lists as arguments, as opposed to Numpy arrays. In some cases it is not even possible to use Numpy arrays, because the arguments are lists-of-lists with different lengths.

In the recent Numba versions a warning is generated when calling Jitted functions with Python lists as arguments: `NumbaPendingDeprecationWarning: Encountered the use of a type that is scheduled for deprecation: type 'reflected list' found for argument`

Instead it is recommended to use `numba.typed.List`, but that is very slow as shown below.

## Feature Suggestion

My Jitted functions are typically read-only, so it really isn't necessary for the original Python list contents to be updated once the Jitted function returns. I wonder if perhaps `numba.typed.List` could be made to run much faster, if it was somehow informed that the list contents will not be modified? Or maybe there is just a bug in `numba.typed.List` that makes it run so slowly?

## Related Issues

We have also had a discussion about this on the Numba discourse site [here](https://numba.discourse.group/t/best-practices-for-using-read-only-python-lists/1106), and I think it now merits a proper issue here on GitHub. Issues #5909 and #5822 seem to be related to this.


## Versions

- Numba: 0.54.1
- Numpy: 1.20.3
- Python: 3.8.12


## Example

This examples shows that the function `sum_list` only takes 2.8 ms, but the conversion of the argument from a Python list to a Numba list takes 1.37 s, which is 500 times slower than the actual computation!

    import numpy as np
    import numba
    from numba import njit

    # Number of elements in the list.
    n = 1000000

    # Numpy array with random floats.
    x_np = np.random.normal(size=n)

    # Convert Numpy array to Python list.
    x_list = x_np.tolist()

    # Convert Python list to Numba list.
    x_list_numba = numba.typed.List(x_list)

    @njit
    def sum_list(x):
        # Sum all elements of the list/array x.
        s = 0
        for i in range(len(x)):
            s += x[i]
        return s

    # Ensure the Jit function has been compiled before timing tests.
    sum_list(x=x_list_numba)

    %timeit numba.typed.List(x_list)
    # 1.37 s ± 49 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

    %timeit sum_list(x=x_list_numba)
    # 2.8 ms ± 61.9 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

Thanks!

user: Hvass-Labs
labels: performance - run time: Performance issue occurring at run time.
issue_7725: state: open
title: Raise an error when an array of the wrong types are used for function compiled AOT
body: We have some functions we want to compile AOT using numba which uses arrays as its input. In some cases users of our code may accidentally use an array of float64 instead of int64 for example. In these cases the numba code appears to continue and does not raise an error so that the results will be wrong. Is there something we should be doing to ensure that the user uses the right types?

See the minimal example below,

```python
from numba.pycc import CC
from numba import complex64, float64, int64
from numba.core.types.npytypes import Array


cc = CC('my_module')


@cc.export('multc', Array(complex64, 1, "A")(
    Array(complex64, 1, "A"), Array(complex64, 1, "A")
))
@cc.export('multf', Array(float64, 1, "A")(
    Array(float64, 1, "A"), Array(float64, 1, "A")
))
@cc.export('multi', Array(int64, 1, "A")(
    Array(int64, 1, "A"), Array(int64, 1, "A")
))
def mult(a, b):
    return a * b


if __name__ == "__main__":
    cc.compile()
```

```python
>>> import numpy as np
>>> a = np.array([1, 2, 3, 4], dtype=np.int64)
>>> b = np.array([1.1, 2.2, 3.3, 4.4], dtype=np.float64)
>>> c = np.array([1.1+1.1j, 2.2+2.2j, 3.3+3.3j, 4.4+4.4j], dtype=np.complex64)
>>> import my_module
>>> my_module.multi(a, a)
array([ 1,  4,  9, 16])
>>> my_module.multi(b, b)   # should raise a error
array([-8119809984163909468, -4426858289720102748,  6638485994729205924,
        -733906595276296028])
>>> my_module.multi(c, c)    # should raise a error
array([ 2586564337444281385, -4745352150906872791, -8446381298434483159,
        6369616171939879977])
>>> my_module.multf(a, a)     # should raise a error
array([0., 0., 0., 0.])
>>> my_module.multf(b, b)
array([ 1.21,  4.84, 10.89, 19.36])
>>> my_module.multf(c, c)    # should raise a error
array([1.97754000e-04, 1.29600062e+01, 5.89824048e+03, 8.49346967e+05])
>>> my_module.multc(a, a)    # should raise a error
array([0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j], dtype=complex64)
>>> my_module.multc(b, b)    # should raise a error
array([-3.562656 -5.99540536e-23j, -4.1006246-6.43215599e-23j,
              inf+1.17643584e+24j, -5.1756244-7.22624988e-23j],
      dtype=complex64)
>>> my_module.multc(c, c)
array([0. +2.42j    , 0. +9.68j    , 0.+21.779999j, 0.+38.72j    ],
      dtype=complex64)
```
user: ChiCheng45
labels: AOT: ahead of time compilation issue
issue_7723: state: open
title: Explicitly catch writing to globals and document?
body: Following on from cases like: https://github.com/numba/numba/issues/7669 and numerous questions asked about "Numba treats globals as compile time constants/immutable", am wondering if a patch like (with the same for `static_setitem`):
```diff
diff --git a/numba/core/typeinfer.py b/numba/core/typeinfer.py
index 7dcbf7b..91f03a4 100644
--- a/numba/core/typeinfer.py
+++ b/numba/core/typeinfer.py
@@ -1411,6 +1411,11 @@ https://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-has-an-
             raise UnsupportedError(msg, loc=inst.loc)
 
     def typeof_setitem(self, inst):
+        im_targets = [x.target for x in self.assumed_immutables]
+        if inst.target in im_targets:
+            msg = ("Values in globals are considered immutable, writing to "
+                   "them is forbidden. For details see: <some numba doc>")
+            raise UnsupportedError(msg, loc=inst.loc)
         constraint = SetItemConstraint(target=inst.target, index=inst.index,
                                        value=inst.value, loc=inst.loc)
         self.constraints.append(constraint)
```
would be a good idea. The impact of this patch is to turn the exception in cases like:
```python
from numba import njit
import numpy as np

x = np.ones(5)

@njit
def foo(i):
    x[i] = 1

foo(1)
```
from:
```
... <lots more of this> ....
numba.core.errors.TypingError: No implementation of function Function(<built-in function setitem>) found for signature:
 
 >>> setitem(readonly array(float64, 1d, C), int64, Literal[int](1))
 
There are 16 candidate implementations:
  - Of which 14 did not match due to:
  Overload of function 'setitem': File: <numerous>: Line N/A.
    With argument(s): '(readonly array(float64, 1d, C), int64, int64)':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'SetItemBuffer.generic': File: numba/core/typing/arraydecl.py: Line 176.
    With argument(s): '(readonly array(float64, 1d, C), int64, int64)':
   Rejected as the implementation raised a specific error:
     NumbaTypeError: Cannot modify readonly array of type: readonly array(float64, 1d, C)
... <lots more of this> ....
```
to
```
numba.core.errors.UnsupportedError: Failed in nopython mode pipeline (step: nopython frontend)
Values in globals are considered immutable, writing to them is forbidden. For details see: <some numba doc>

File "write_global_arr.py", line 8:
def foo(i):
    x[i] = 1
    ^
```
user: stuartarchibald
labels: discussion: An issue requiring discussion
issue_7719: state: open
title: The ability to set fma, prec_div, and prec_sqrt options dynamically for cuda.jit
body: I wish to be able to set ```fma, prec_div, and prec_sqrt``` dynamically using ```cuda.jit```. Results from the GPU then matches the CPU which may be a desired effect.

```python
@cuda.jit(fma=False, prec_div=True, prec_sqrt=True)
```

For validating GPU results with the CPU, I inserted code locally on my dev machine to llvm_to_ptx function in ```.../site-packages/numba/cuda/cudadrv/nvvm.py```. Please allow the flags to be set dynamically. Thank you.

```python
def llvm_to_ptx(llvmir, **opts):
    if isinstance(llvmir, str):
        llvmir = [llvmir]

    # cuda.jit(fma=False, et cetera fails), so setting here 
    opts.update({
        'fma': False,
        'prec_div': True,
        'prec_sqrt': True,
    })
    ...
```
user: marioroy
labels: CUDA: CUDA related issue/PR
issue_7716: state: open
title: Numba doesn't keep a reference to dynamic global array
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Seems like Numba doesn't keep a reference to dynamic global arrays, leading to data getting garbage collected prematurely. The program below crashes for me on a Mac (smaller sizes which avoid dynamic globals work fine):
```python
import numpy as np
import numba
from numba.extending import intrinsic
from numba.np.arrayobj import _getitem_array_single_int
from numba.core import types, cgutils
import gc


@intrinsic
def get_arr_sum(typingctx):
    def codegen(context, builder, signature, args):
        n = 10**8
        A = context.make_constant_array(
            builder,
            types.Array(types.int64, 1, "C"),
            np.arange(n),
        )
        arr_struct = context.make_array(types.Array(types.int64, 1, "C"))(
            context, builder, A
        )
        zero = context.get_constant(types.int64, 0)
        n_vals = context.get_constant(types.int64, n)
        s = cgutils.alloca_once_value(builder, zero)
        with cgutils.for_range(builder, n_vals) as loop:
            val = _getitem_array_single_int(
                context,
                builder,
                types.int64,
                types.Array(types.int64, 1, "C"),
                arr_struct,
                loop.index,
            )
            builder.store(builder.add(builder.load(s), val), s)

        return builder.load(s)

    return types.int64(), codegen


gc.collect()
s = numba.njit(lambda: get_arr_sum())()
gc.collect()
print(s)
```
user: ehsantn
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_7711: state: open
title: in operator for the type returned by numba.typed.Dict().keys()?
body: ## Feature request


Hello I'm a noob, but playing a bit with Numba I had a problem (since solved) but in the process of solving it, a seemingly knowledgeable SO poster advised that what I was trying to do relies on a feature not currently in Numba 

So here it goes:

In python, it is efficient to do:

```
some_dict = {33:22}
33 in some_dict.keys()
```

but in numba, alto this works:

```
some_dict = numba.typed.Dict.empty(key_type=numba.types.int64, value_type=numba.types.int64)
some_dict[33] = 22
33 in some_dict
```

this doesn't 
```
33 in some_dict.keys()
```
The aforementioned knowledgeable person on SO interpreted this to mean that the `in` operator is not implemented for the type returned by numba.typed.Dict().keys() and that this would cause the compiled code to be inefficient.




user: kvak
issue_7710: state: open
title: CUDA: Don't use typemap for function name and line number 
body: Following discussion around #7704 and #7709 it becomes clear that we shouldn't really rely on the type annotation for the function name and line number in CUDA's `compile_ptx` function. We should remove the use of the type annotation for this and instead get them from the Python function.

We will also need to add a test that the type annotation is present when compiling in the CUDA target, to ensure it is available for display (e.g. with `numba --annotate-html`).
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7708: state: open
title: Enable Boxing Unhashable Literals
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

closes #7707

Provides support for boxing an unhashable literal (i.e. slice).  This updates serializing to avoid trying to place an unhashable object in a dictionary. It reuses the hashing implementation from the literal type but creates a new object type to avoid conflicts with serializing the actual type.
user: njriasan
labels: Effort - medium: Medium size effort needed
issue_7707: state: open
title: Cannot box Literals that aren't hashable
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Passing literals that aren't hashable fails at boxing in Numba. Here is a reproducer with a slice.

```python
import numba

@numba.njit
def f(x):
    slc = numba.literally(x)
    return slc

print(f(slice(1, 2)))
```

Which produces the following stack trace
```
Traceback (most recent call last):
  File "test_unhashable_literal.py", line 8, in <module>
    print(f(slice(1, 2)))
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 443, in _compile_for_args
    return_val = self._compile_for_args(*args)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 487, in _compile_for_args
    raise e
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 965, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 125, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 139, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 152, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 693, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 429, in compile_extra
    return self._compile_bytecode()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 497, in _compile_bytecode
    return self._compile_core()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 472, in _compile_core
    raise e
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 463, in _compile_core
    pm.run(self.state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 349, in run
    raise e
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 341, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 296, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 269, in check
    mangled = func(compiler_state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typed_passes.py", line 398, in run_pass
    lower.create_cpython_wrapper(flags.release_gil)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 292, in create_cpython_wrapper
    self.context.create_cpython_wrapper(self.library, self.fndesc,
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/cpu.py", line 184, in create_cpython_wrapper
    library.add_ir_module(wrapper_module)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/codegen.py", line 727, in add_ir_module
    ir = cgutils.normalize_ir_text(str(ir_module))
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/module.py", line 242, in __repr__
    lines += self._get_body_lines()
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/module.py", line 212, in _get_body_lines
    lines += [str(v) for v in self.globals.values()]
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/module.py", line 212, in <listcomp>
    lines += [str(v) for v in self.globals.values()]
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/values.py", line 1002, in __str__
    self.descr(buf)
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/values.py", line 997, in descr
    self.descr_body(buf)
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/values.py", line 991, in descr_body
    blk.descr(buf)
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/values.py", line 1131, in descr
    buf += ["  {0}\n".format(instr) for instr in self.instructions]
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/values.py", line 1131, in <listcomp>
    buf += ["  {0}\n".format(instr) for instr in self.instructions]
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/_utils.py", line 48, in __str__
    s = self.__cached_str = self._to_string()
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/values.py", line 548, in _to_string
    self.descr(buf)
  File "/Users/nicholasriasanovsky/miniconda3/envs/NUMBA55/lib/python3.8/site-packages/llvmlite/ir/instructions.py", line 218, in descr
    .format(self.opname, return_value.type,
AttributeError: 'tuple' object has no attribute 'type'
```

The source of the problem appears to be `serialize_object` because the line `gv = self.module.__serialized[obj]` always fails when a literal isn't hashable.

I think a reasonable solution would be to support passing a key to `serialize_object`. `box_literal` could then construct a unique object to use as a key.

A possible implementation could build a wrapper type around the literal type that reuse the literal type's hash (but uses a different object to avoid collisions with actually serializing the type).
user: njriasan
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7705: state: open
title: Use `omp_set_max_active_levels()` instead of `omp_set_nested()`
body: `omp_set_nested()` is deprecated and often results in a warning on recent installations. Following the discussion in Issue #5275, this commit changes the call to `omp_set_max_active_levels()`. Ideally we'd set it to the maximum supported nesting level, but we can't determine what that is; the function `omp_get_supported_active_levels()` was only added in OpenMP 5.0, which is quite recent and was not supported by some implementations until very recently (e.g. it was added to GNU OpenMP in mid-2020). We arbitrarily set the nesting level to 32, which is far greater than any real requirement, and the implementation will limit the nesting levels to the supported number as per the spec if it is less than 32.

Fixes #5275.
user: gmarkall
labels: Pending BuildFarm: For PRs that have been reviewed but pending a push through our buildfarm
4 - Waiting on reviewer: Waiting for reviewer to respond to author
4 - Waiting on CI: Review etc done, waiting for CI to finish
Effort - short: Short size effort needed
issue_7697: state: open
title: CUDA: support recursion in device functions
body: Presently this isn't supported because we always inline the device function in the caller. A motivating example from @c200chromebook:

```python
from numba import cuda
import numba
import numpy


@cuda.jit(device=True)
def a(q, x):
    if x:
        q[0] += x
        b(q, x-1)


@cuda.jit(device=True)
def b(q, x):
    if x:
        q[0] += x
        a(q, x-1)


@cuda.jit(numba.void(numba.types.int32[:], numba.int32))  # <-
def z(q, x):
    b(q, x)


q = numpy.array((5,), dtype=numpy.int64)
z[1,1](q, 4)
#z(q, 4)
print(q)
```
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7686: state: open
title: numba and parallel random generators on CPU
body: When using random numbers for parallel computing it is recommended to use 

https://numpy.org/doc/stable/reference/random/parallel.html

from numpy. Unfortunately numba does only support the standart random functionality
https://numba.pydata.org/numba-doc/latest/reference/numpysupported.html#random

Below a small example to detail the wish (it does not work with numba but without numba). I think there are a lot of people out there making simulations with random numbers on multiple cores and want to speed up code with numba. 

```python
    import numpy as np
    from numba import jit
    import multiprocessing as mp


    @jit(nopython=True) 
    def compute_with_random(j,rng):
      x=rng.normal(0,0.3,j)
      y=np.sum(x)/j
      return y


    @jit(nopython=True) 
    def single(args):
      (n,se)=args
      rng=np.random.default_rng(se)
      s=0
      for i in range(1,n):
        s+=compute_with_random(i,rng)
      return s


    def Call_Multi():
      seed_sequence = np.random.SeedSequence(12345)  
      seeds = seed_sequence.spawn(4)

      all_ins=[ (500,seeds[0]), (700,seeds[1]), (500,seeds[2]), (700,seeds[3]) ]
      pool = mp.Pool(4)
      result = pool.map( single, all_ins )  

      return result


    if __name__=='__main__':
      print( Call_Multi() )
```

That would be really great, thanks.


---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: emi0000
issue_7681: state: open
title: Bug of mismatch shape with parallel mode 
body: Hello all,
If parallel is False in the simple code below it works fine but when turned to True, it raises an assertion error with an incoherent mismatch of sizes.

python : 3.8.8
numba : 0.54.1
OS : unbuntu 20.04

```
import numpy as np
from numba import njit
@njit
def foo(x):
    return np.exp(x)

@njit(parallel=True)
def toto(x):
    a=foo(x)
    for i in range(2):
        if i==1:
            c=a
        else:
            c=foo(x)
    return a*c
```
and calling:
```
toto(np.random.rand(10))
```
In parallel mode, the for loop and the if else condition seems to mess around something even if a and c presents the same shape. Changing the condition to i==0 do not change the error.
Strange...

Thanks for the help !
user: lanougue
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7678: state: open
title: Reflected lists aren't usable as `jitclass` members
body: The following (a minimal example from that originally asked about in #7672):

```python
from numba.experimental import jitclass
from numba.types import int64
import typing as pt

@jitclass
class Node():
    items: pt.List[int64]

    def __init__(self):
        self.items = [3]

Node()
```

gives

```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Failed in nopython mode pipeline (step: native lowering)
Cannot cast list(int64)<iv=[3]> to ListType[int64]: %".109" = load {i8*, i8*}, {i8*, i8*}* %".10"
During: lowering "(self).items = $4build_list.1" at /home/gmarkall/numbadev/issues/7672/repro.py (11)
During: resolving callee type: jitclass.Node#7f8facbb53a0<items:ListType[int64]>
During: typing of call at <string> (3)

During: resolving callee type: jitclass.Node#7f8facbb53a0<items:ListType[int64]>
During: typing of call at <string> (3)


File "<string>", line 3:
<source missing, REPL/exec in use?>
```

I believe this is a bug because although there's a typing error raised, its source is an error in the lowering triggered by typing. I don't know that we should necessarily fix this due to the deprecation of reflected lists - we should recommend typed lists instead.

cc @esc who may find this and/or #7672 interesting.
cc @abdullahkavakli who reported #7672.
user: gmarkall
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7677: state: open
title: `parallel=True` causes `AssertionError` in slicing even with no parallel transformation
body: A slightly modified version of the reproducer from https://numba.discourse.group/t/how-do-i-parallelize-this-code/1085/7?u=gmarkall:

```python
from numba import njit
import numpy as np

@njit(parallel=True)
def myFoo(par,x):
    par[:,0:1]*x
    return 1

x=np.array(np.arange(0,10,2.0))
par=np.array([[i*10.0,i*4.0] for i in range(1,3)])
myFoo(par,x)
```

produces:

```
/home/gmarkall/numbadev/numba/numba/core/typed_passes.py:331: NumbaPerformanceWarning: 
The keyword argument 'parallel=True' was specified but no transformation for parallel execution was possible.

To find out why, try turning on parallel diagnostics, see https://numba.pydata.org/numba-doc/latest/user/parallel.html#diagnostics for help.

File "repro2.py", line 5:
@njit(parallel=True)
def myFoo(par,x):
^

  warnings.warn(errors.NumbaPerformanceWarning(msg,
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/discourse-1085/repro2.py", line 11, in <module>
    myFoo(par,x)
AssertionError: Sizes of $18binary_subscr.10, x do not match on /home/gmarkall/numbadev/issues/discourse-1085/repro2.py (6)
```

(running with `parallel=False` produces no error)

Could you take a look please @DrTodd13 ?
user: gmarkall
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7676: state: open
title: Incorrect results with `prange` and sliced array
body: This is a simplified version of the reproducer from https://numba.discourse.group/t/how-do-i-parallelize-this-code/1085/6?u=gmarkall.

The following:

```python
import numpy as np
from numba import prange, njit


@njit(parallel=True)
def myFoo(x, par, numthreads):
    n_par = par.shape[0]
    n_x = len(x)
    result = np.zeros((n_par, n_x), dtype=np.float64)
    chunklen = (len(x) + numthreads - 1) // numthreads

    for i in prange(numthreads):
        start = i * chunklen
        stop = (i + 1) * chunklen
        result[:, start:stop] = x[start:stop] * par[:, 0:1]

    return result


x = np.array(np.arange(0, 12, 1.0))
par = np.array([[1.0, 0.5], [2.0, 3.0], [3.0, 5.0]])
print(myFoo(x, par, 4))
print(myFoo.py_func(x, par, 4))
```

when run with `parallel=False` gives:

```
[[ 0.  1.  2.  3.  4.  5.  6.  7.  8.  9. 10. 11.]
 [ 0.  2.  4.  6.  8. 10. 12. 14. 16. 18. 20. 22.]
 [ 0.  3.  6.  9. 12. 15. 18. 21. 24. 27. 30. 33.]]
[[ 0.  1.  2.  3.  4.  5.  6.  7.  8.  9. 10. 11.]
 [ 0.  2.  4.  6.  8. 10. 12. 14. 16. 18. 20. 22.]
 [ 0.  3.  6.  9. 12. 15. 18. 21. 24. 27. 30. 33.]]
```

but when run with `parallel=True` gives:

```
[[0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.]
 [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.]
 [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.]]
[[ 0.  1.  2.  3.  4.  5.  6.  7.  8.  9. 10. 11.]
 [ 0.  2.  4.  6.  8. 10. 12. 14. 16. 18. 20. 22.]
 [ 0.  3.  6.  9. 12. 15. 18. 21. 24. 27. 30. 33.]]
```

Could you take a look please @DrTodd13 ?
user: gmarkall
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7670: state: open
title: [FEATURE REQUEST] Raise custom exception when users try to import numba.roc
body: Hi :-)

There has been a post on the [discourse board](https://numba.discourse.group/t/how-in-the-world-do-i-get-numba-roc-to-work/1081/2) where a new user tried to import numba.roc and was simply met with import errors.

Given that the ROC module used to exist, would it be helpful to reintroduce a roc.py file in the top level package directory that does nothing but raise a custom exception mentioning the dropped support?

Happy to make a PR, just wanted to get an opinion first.

Cheers!

EDIT:
This exception would only raise if a user writes either `import numba.roc` or `from numba import roc` but not if they `import numba` and then later refer to `numba.roc`. But at least it would cover the most common import habits?
user: HPLegion
labels: ROC: ROC related issue/PR
issue_7668: state: open
title: aot compile raise error with yield
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [√ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ √] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

OS: win10 64
Python: 3.10.1
numba: 0.55.0rc1

```
import numba as nb
from numba.pycc import CC

cc = CC('numba_test')


@nb.njit()
@cc.export('f', ())
def f():
    yield 1
    yield 2
    yield 333
    pass


if __name__ == '__main__':
    cc.compile()

```
distutils.errors.LinkError: Command "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:E:\www\python_projects\trading_projects\pipenv_based\auto_trading\venv\libs /LIBPATH:C:\Users\xiaobaitu\AppData\Local\Programs\Python\Python310\libs /LIBPATH:C:\Users\xiaobaitu\AppData\Local\Programs\Python\Python310 /LIBPATH:E:\www\python_projects\trading_projects\pipenv_based\auto_trading\venv\PCbuild\amd64 /LIBPATH:E:\\www\\python_projects\\trading_projects\\pipenv_based\\auto_trading\\venv\\lib\\site-packages\\numpy\\core\\lib /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\lib\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\lib\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\ucrt\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x64 python310.lib msvcrt.lib npymath.lib /EXPORT:PyInit_numba_test C:\Users\xiaobaitu\AppData\Local\Temp\pycc-build-numba_test-ma1dxzla\numba_test.cp310-win_amd64.o C:\Users\xiaobaitu\AppData\Local\Temp\pycc-build-numba_test-ma1dxzla\www\python_projects\trading_projects\pipenv_based\auto_trading\venv\lib\site-packages\numba\pycc\modulemixin.obj C:\Users\xiaobaitu\AppData\Local\Temp\pycc-build-numba_test-ma1dxzla\www\python_projects\trading_projects\pipenv_based\auto_trading\venv\lib\site-packages\numba\cext\dictobject.obj C:\Users\xiaobaitu\AppData\Local\Temp\pycc-build-numba_test-ma1dxzla\www\python_projects\trading_projects\pipenv_based\auto_trading\venv\lib\site-packages\numba\cext\listobject.obj C:\Users\xiaobaitu\AppData\Local\Temp\pycc-build-numba_test-ma1dxzla\www\python_projects\trading_projects\pipenv_based\auto_trading\venv\lib\site-packages\numba\cext\utils.obj C:\Users\xiaobaitu\AppData\Local\Temp\pycc-build-numba_test-ma1dxzla\www\python_projects\trading_projects\pipenv_based\auto_trading\venv\lib\site-packages\numba\pycc\../core/runtime/nrt.obj /OUT:E:\www\python_projects\trading_projects\pipenv_based\auto_trading\auto_trading\just_for_test_dir\numba_test\numba_test.cp310-win_amd64.pyd /IMPLIB:C:\Users\xiaobaitu\AppData\Local\Temp\pycc-build-numba_test-ma1dxzla\numba_test.cp310-win_amd64.lib" failed with exit status 1120


user: guzuomuse
labels: AOT: ahead of time compilation issue
bug - failure to compile: Bugs: failed to compile valid code
issue_7666: state: open
title: numpy.copy messes up result of njitted generator
body: 
The generator `neighborgood` is meant to generate all versions of 0-1 array with a single item flipped:
```python
@numba.njit
def neighborgood(x):
    n = len(x)
    for i in range(n):
        y = numpy.copy(x)
        y[i] = 1 - y[i]
        yield y
```
Example use: 
```python
>>> list(neighborgood(numpy.array([0, 1, 0, 0, 0], dtype=np.int8)))
[array([1, 1, 0, 0, 0], dtype=int8),
 array([0, 0, 0, 0, 0], dtype=int8),
 array([0, 1, 1, 0, 0], dtype=int8),
 array([0, 1, 0, 1, 0], dtype=int8),
 array([0, 1, 0, 0, 1], dtype=int8)]
```
But when `numpy.copy` or `numpy.ndarray.copy` is called after `yield` statement, something mysterious happens:
```python
@numba.njit
def neighborgood(x):
    n = len(x)
    for i in range(n):
        y = numpy.copy(x)
        y[i] = 1 - y[i]
        yield y
        numpy.copy(y)
```
```python
>>> list(neighborgood(np.array([0, 1, 0, 0, 0], dtype=np.int8)))
[array([-34, -34, -34, -34, -34], dtype=int8),
 array([-34, -34, -34, -34, -34], dtype=int8),
 array([-34, -34, -34, -34, -34], dtype=int8),
 array([-34, -34, -34, -34, -34], dtype=int8),
 array([-34, -34, -34, -34, -34], dtype=int8)]
```
### The bug occurred on Google Collaboratory 

user: PrefixCoder
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
bug - incorrect behavior: Bugs: incorrect behavior
issue_7663: state: open
title: Feature request numpy.unique axis=0
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

I want to go from
```
a = np.array([[1, 1, 1, 0, 0, 0],
              [0, 1, 1, 1, 0, 0],
              [0, 1, 1, 1, 0, 0],
              [1, 1, 1, 0, 0, 0],
              [1, 1, 1, 1, 1, 0]])
```

to 
```
array([[1, 1, 1, 0, 0, 0],
       [0, 1, 1, 1, 0, 0],
       [1, 1, 1, 1, 1, 0]])
```

Using numpy I would use 

`unique_rows = np.unique(a, axis=0)`

however, the [axis parameter is not supported yet](https://numba.pydata.org/numba-doc/dev/reference/numpysupported.html). I tried some workarounds based on [this SO question](https://stackoverflow.com/questions/16970982/find-unique-rows-in-numpy-array), but I havn't figured out a sollution yet.
user: lukasalexanderweber
labels: good second issue: A good issue for second time contributors
issue_7662: state: open
title: IntEnum as array index? No implementation of getitem found for signature
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.
[advent_2021_15.zip](https://github.com/numba/numba/files/7722820/advent_2021_15.zip)

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
I have an observably bad Python program that I tried to apply Numba to. Unfortunately, JIT fails with some arcane reason that could be related to trying to use an IntEnum as an array index.
```
Traceback (most recent call last):
  File "advent_2021_15.py", line 194, in <module>
    (width + height) * pages - 2, # heuristic
  File "C:\Users\Haley\AppData\Roaming\Python\Python37\site-packages\numba\core\dispatcher.py", line 482, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\Haley\AppData\Roaming\Python\Python37\site-packages\numba\core\dispatcher.py", line 423, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function getitem>) found for signature:

 >>> getitem(reflected list(int32)<iv=None>, IntEnum<int32>(Route))

There are 22 candidate implementations:
      - Of which 22 did not match due to:
      Overload of function 'getitem': File: <numerous>: Line N/A.
        With argument(s): '(reflected list(int32)<iv=None>, IntEnum<int32>(Route))':
       No match.

During: typing of intrinsic-call at advent_2021_15.py (170)
During: typing of static-get-item at advent_2021_15.py (170)

File "advent_2021_15.py", line 170:
def push_route(route):
    <source elided>
 for i, r in enumerate(frontier):
  if r[Route.X] == route[Route.X] and r[Route.Y] == route[Route.Y]:
  ^
```
user: JapanYoshi
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7658: state: open
title: parallel `LoweringError` when aliasing `a = a.flat`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Here's a small error I found for a corner case, where the user tries to redefine a variable as `a = a.flat`. Defining a new variable instead, e.g. `b = a.flat` and looping over that doesn't trigger the error.

```python
import numba
import numpy as np

@numba.njit(parallel=True)
def parallel(a):
    a = a.flat
    for i in numba.prange(len(a)):
        a[i] += 1

a = np.arange(10)
parallel(a)
```

Truncated output:
```
[...]
LoweringError: Failed in nopython mode pipeline (step: native lowering)
Type of #18 arg mismatch: i64* != i64

File "<ipython-input-2-40361620b89e>", line 7:
def parallel(a):
    <source elided>
    a = a.flat
    for i in numba.prange(len(a)):
    ^

During: lowering "id=0[LoopNest(index_variable = parfor_index.2, range = (0, $16call_function.6, 1))]{24: <ir.Block at <ipython-input-2-40361620b89e> (7)>}Var(parfor_index.2, <ipython-input-2-40361620b89e>:7)" at <ipython-input-2-40361620b89e> (7)
```

Full output:
<details>

```
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
~/numba/numba/core/errors.py in new_error_context(fmt_, *args, **kwargs)
    816     try:
--> 817         yield
    818     except NumbaError as e:

~/numba/numba/core/lowering.py in lower_block(self, block)
    279                                    loc=self.loc, errcls_=defaulterrcls):
--> 280                 self.lower_inst(inst)
    281         self.post_block(block)

~/numba/numba/core/lowering.py in lower_inst(self, inst)
    551                     if isinstance(inst, _class):
--> 552                         func(self, inst)
    553                         return

~/numba/numba/parfors/parfor_lowering.py in _lower_parfor_parallel(lowerer, parfor)
    315         print("loop_ranges = ", loop_ranges)
--> 316     call_parallel_gufunc(
    317         lowerer,

~/numba/numba/parfors/parfor_lowering.py in call_parallel_gufunc(lowerer, cres, gu_signature, outer_sig, expr_args, expr_arg_types, loop_ranges, redvars, reddict, redarrdict, init_block, index_var_typ, races, exp_name_to_tuple_var)
   1463 
-> 1464     info = build_gufunc_wrapper(llvm_func, cres, sin, sout,
   1465                                 cache=False, is_parfors=True)

~/numba/numba/np/ufunc/parallel.py in build_gufunc_wrapper(py_func, cres, sin, sout, cache, is_parfors)
    258     signature = cres.signature
--> 259     innerinfo = ufuncbuilder.build_gufunc_wrapper(
    260         py_func, cres, sin, sout, cache=cache, is_parfors=is_parfors,

~/numba/numba/np/ufunc/wrappers.py in build_gufunc_wrapper(py_func, cres, sin, sout, cache, is_parfors)
    500                else _GufuncWrapper)
--> 501     return wrapcls(
    502         py_func, cres, sin, sout, cache, is_parfors=is_parfors,

~/numba/numba/core/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     34             with self:
---> 35                 return func(*args, **kwargs)
     36         return _acquire_compile_lock

~/numba/numba/np/ufunc/wrappers.py in build(self)
    454         wrapper_name = "__gufunc__." + self.fndesc.mangled_name
--> 455         wrapperlib = self._compile_wrapper(wrapper_name)
    456         return _wrapper_info(

~/numba/numba/np/ufunc/wrappers.py in _compile_wrapper(self, wrapper_name)
    433             # Build wrapper
--> 434             self._build_wrapper(wrapperlib, wrapper_name)
    435         # Non-parfors?

~/numba/numba/np/ufunc/wrappers.py in _build_wrapper(self, library, name)
    411             args = [a.get_array_at_offset(loop.index) for a in arrays]
--> 412             innercall, error = self.gen_loop_body(builder, pyapi, func, args)
    413             # If error, escape

~/numba/numba/np/ufunc/wrappers.py in gen_loop_body(self, builder, pyapi, func, args)
    460     def gen_loop_body(self, builder, pyapi, func, args):
--> 461         status, retval = self.call_conv.call_function(
    462             builder, func, self.signature.return_type, self.signature.args,

~/numba/numba/core/callconv.py in call_function(self, builder, callee, resty, argtys, args, attrs)
    580             raise TypeError("attrs must be an iterable of strings or None")
--> 581         code = builder.call(callee, realargs, attrs=_attrs)
    582         status = self._get_return_status(builder, code,

~/miniconda3/envs/forge/lib/python3.8/site-packages/llvmlite/ir/builder.py in call(self, fn, args, name, cconv, tail, fastmath, attrs, arg_attrs)
    879         """
--> 880         inst = instructions.CallInstr(self.block, fn, args, name=name,
    881                                       cconv=cconv, tail=tail, fastmath=fastmath,

~/miniconda3/envs/forge/lib/python3.8/site-packages/llvmlite/ir/instructions.py in __init__(self, parent, func, args, name, cconv, tail, fastmath, attrs, arg_attrs)
     91                        .format(1 + i, expected_type, arg.type))
---> 92                 raise TypeError(msg)
     93             args[i] = arg

TypeError: Type of #18 arg mismatch: i64* != i64

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-2-40361620b89e> in <module>
      9 
     10 a = np.arange(10)
---> 11 parallel(a)

~/numba/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    485                     e.patch_message('\n'.join((str(e).rstrip(), help_msg)))
    486             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 487             raise e
    488         finally:
    489             self._types_active_call = []

~/numba/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    418         return_val = None
    419         try:
--> 420             return_val = self.compile(tuple(argtypes))
    421         except errors.ForceLiteralArg as e:
    422             # Received request for compiler re-entry with the list of arguments

~/numba/numba/core/dispatcher.py in compile(self, sig)
    963                 with ev.trigger_event("numba:compile", data=ev_details):
    964                     try:
--> 965                         cres = self._compiler.compile(args, return_type)
    966                     except errors.ForceLiteralArg as e:
    967                         def folded(args, kws):

~/numba/numba/core/dispatcher.py in compile(self, args, return_type)
    123 
    124     def compile(self, args, return_type):
--> 125         status, retval = self._compile_cached(args, return_type)
    126         if status:
    127             return retval

~/numba/numba/core/dispatcher.py in _compile_cached(self, args, return_type)
    137 
    138         try:
--> 139             retval = self._compile_core(args, return_type)
    140         except errors.TypingError as e:
    141             self._failed_cache[key] = e

~/numba/numba/core/dispatcher.py in _compile_core(self, args, return_type)
    150 
    151         impl = self._get_implementation(args, {})
--> 152         cres = compiler.compile_extra(self.targetdescr.typing_context,
    153                                       self.targetdescr.target_context,
    154                                       impl,

~/numba/numba/core/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    691     pipeline = pipeline_class(typingctx, targetctx, library,
    692                               args, return_type, flags, locals)
--> 693     return pipeline.compile_extra(func)
    694 
    695 

~/numba/numba/core/compiler.py in compile_extra(self, func)
    427         self.state.lifted = ()
    428         self.state.lifted_from = None
--> 429         return self._compile_bytecode()
    430 
    431     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/numba/numba/core/compiler.py in _compile_bytecode(self)
    495         """
    496         assert self.state.func_ir is None
--> 497         return self._compile_core()
    498 
    499     def _compile_ir(self):

~/numba/numba/core/compiler.py in _compile_core(self)
    474                     self.state.status.fail_reason = e
    475                     if is_final_pipeline:
--> 476                         raise e
    477             else:
    478                 raise CompilerError("All available pipelines exhausted")

~/numba/numba/core/compiler.py in _compile_core(self)
    461                 res = None
    462                 try:
--> 463                     pm.run(self.state)
    464                     if self.state.cr is not None:
    465                         break

~/numba/numba/core/compiler_machinery.py in run(self, state)
    351                     (self.pipeline_name, pass_desc)
    352                 patched_exception = self._patch_error(msg, e)
--> 353                 raise patched_exception
    354 
    355     def dependency_analysis(self):

~/numba/numba/core/compiler_machinery.py in run(self, state)
    339                 pass_inst = _pass_registry.get(pss).pass_inst
    340                 if isinstance(pass_inst, CompilerPass):
--> 341                     self._runPass(idx, pass_inst, state)
    342                 else:
    343                     raise BaseException("Legacy pass in use")

~/numba/numba/core/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     33         def _acquire_compile_lock(*args, **kwargs):
     34             with self:
---> 35                 return func(*args, **kwargs)
     36         return _acquire_compile_lock
     37 

~/numba/numba/core/compiler_machinery.py in _runPass(self, index, pss, internal_state)
    294             mutated |= check(pss.run_initialization, internal_state)
    295         with SimpleTimer() as pass_time:
--> 296             mutated |= check(pss.run_pass, internal_state)
    297         with SimpleTimer() as finalize_time:
    298             mutated |= check(pss.run_finalizer, internal_state)

~/numba/numba/core/compiler_machinery.py in check(func, compiler_state)
    267 
    268         def check(func, compiler_state):
--> 269             mangled = func(compiler_state)
    270             if mangled not in (True, False):
    271                 msg = ("CompilerPass implementations should return True/False. "

~/numba/numba/core/typed_passes.py in run_pass(self, state)
    394                 lower = lowering.Lower(targetctx, library, fndesc, interp,
    395                                        metadata=metadata)
--> 396                 lower.lower()
    397                 if not flags.no_cpython_wrapper:
    398                     lower.create_cpython_wrapper(flags.release_gil)

~/numba/numba/core/lowering.py in lower(self)
    181         if self.generator_info is None:
    182             self.genlower = None
--> 183             self.lower_normal_function(self.fndesc)
    184         else:
    185             self.genlower = self.GeneratorLower(self)

~/numba/numba/core/lowering.py in lower_normal_function(self, fndesc)
    235         # Init argument values
    236         self.extract_function_arguments()
--> 237         entry_block_tail = self.lower_function_body()
    238 
    239         # Close tail of entry block, do not emit debug metadata else the

~/numba/numba/core/lowering.py in lower_function_body(self)
    264             bb = self.blkmap[offset]
    265             self.builder.position_at_end(bb)
--> 266             self.lower_block(block)
    267         self.post_lower()
    268         return entry_block_tail

~/numba/numba/core/lowering.py in lower_block(self, block)
    278             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    279                                    loc=self.loc, errcls_=defaulterrcls):
--> 280                 self.lower_inst(inst)
    281         self.post_block(block)
    282 

~/miniconda3/envs/forge/lib/python3.8/contextlib.py in __exit__(self, type, value, traceback)
    129                 value = type()
    130             try:
--> 131                 self.gen.throw(type, value, traceback)
    132             except StopIteration as exc:
    133                 # Suppress StopIteration *unless* it's the same exception that

~/numba/numba/core/errors.py in new_error_context(fmt_, *args, **kwargs)
    829             else:
    830                 tb = None
--> 831             raise newerr.with_traceback(tb)
    832         elif use_new_style_errors():
    833             raise e

LoweringError: Failed in nopython mode pipeline (step: native lowering)
Type of #18 arg mismatch: i64* != i64

File "<ipython-input-2-40361620b89e>", line 7:
def parallel(a):
    <source elided>
    a = a.flat
    for i in numba.prange(len(a)):
    ^

During: lowering "id=0[LoopNest(index_variable = parfor_index.2, range = (0, $16call_function.6, 1))]{24: <ir.Block at <ipython-input-2-40361620b89e> (7)>}Var(parfor_index.2, <ipython-input-2-40361620b89e>:7)" at <ipython-input-2-40361620b89e> (7)
```
</details>

Tested on 0.55.0dev0 and master.  Maybe related to the old #2954 and #3015.
user: lgarrison
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7655: state: open
title: parallel=True does not work for functions with a jitclass instance as an argument
body: I am using version 0.53.1.

Here is a MWE:

```python
import numpy as np
from numba.experimental import jitclass
from numba import njit, prange, int32, float32, deferred_type

spec = [('value', int32)]
@jitclass(spec)
class Bag(object):
    def __init__(self, value):
        self.value = value
        
Bag_type = deferred_type()
Bag_type.define(Bag.class_type.instance_type)
spec = [('value', int32),('bag',Bag_type)]
@jitclass(spec)
class Sack(object):
    def __init__(self, value):
        self.value = value
        self.bag = Bag(value+5)
        
    def call_foo(self,n):
        print(foo(self.bag,n))
        
    def call_foo_parallel(self,n):
        print(foo_parallel(self.bag,n))

@njit
def foo(bag,n):
    out = 0
    for i in prange(n):
        out += bag.value
    return out

@njit(parallel=True)
def foo_parallel(bag,n):
    out = 0
    for i in prange(n):
        out += bag.value
    return out

sack = Sack(10)
print(sack.value)
print(sack.bag.value)
sack.call_foo(3)
sack.call_foo_parallel(3)
```
Which outputs the following:

10
15
45
Traceback (most recent call last):

  File "C:\Users\MTH31973\Desktop\commz\commz\tests\benchmark\parallel_processing_benchmark.py", line 51, in <module>
    sack.call_foo_parallel(3)

  File "C:\Aeroapps\AnacondaP3x64-2020.07\lib\site-packages\numba\experimental\jitclass\boxing.py", line 60, in wrapper
    return method(*args, **kwargs)

  File "C:\Aeroapps\AnacondaP3x64-2020.07\lib\site-packages\numba\core\dispatcher.py", line 420, in _compile_for_args
    error_rewrite(e, 'typing')

  File "C:\Aeroapps\AnacondaP3x64-2020.07\lib\site-packages\numba\core\dispatcher.py", line 361, in error_rewrite
    raise e.with_traceback(None)

TypingError: - Resolution failure for literal arguments:
Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x000002588836FD60>.
Failed in nopython mode pipeline (step: nopython mode backend)
cannot store %"deferred.2578128644272.value" to %"deferred.2578128644272.data"*: mismatching types

File "parallel_processing_benchmark.py", line 43:
def foo_parallel(bag,n):
    <source elided>
    out = 0
    for i in prange(n):
    ^

During: lowering "id=11[LoopNest(index_variable = parfor_index.1771, range = (0, n, 1))]{16: <ir.Block at C:\Users\MTH31973\Desktop\commz\commz\tests\benchmark\parallel_processing_benchmark.py (43)>}Var(parfor_index.1771, parallel_processing_benchmark.py:43)" at C:\Users\MTH31973\Desktop\commz\commz\tests\benchmark\parallel_processing_benchmark.py (43)
During: resolving callee type: type(CPUDispatcher(<function foo_parallel at 0x0000025887FD3550>))
During: typing of call at C:\Users\MTH31973\Desktop\commz\commz\tests\benchmark\parallel_processing_benchmark.py (31)

Enable logging at debug level for details.

File "parallel_processing_benchmark.py", line 31:
    def call_foo_parallel(self,n):
        print(foo_parallel(self.bag,n))
        ^

- Resolution failure for non-literal arguments:
None

During: resolving callee type: BoundFunction((<class 'numba.core.types.misc.ClassInstanceType'>, 'call_foo_parallel') for instance.jitclass.Sack#2584933e0d0<value:int32,bag:DeferredType#2578128644272>)
During: typing of call at <string> (3)

user: hunterdsp
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7654: state: open
title: Record `mangling_args` should not use `self._code`
body: https://github.com/numba/numba/blob/4cc738b0cea246bb0cfd9807a8c783be0fa5ddac/numba/core/types/npytypes.py#L163-L165

It should use type-parameters. See `Tuple` implementation.
user: sklam
issue_7653: state: open
title: Better, more official way to get specific macOS SDKs?
body: Extracting the question/concern from #7650 into a separate issue: We are now downloading a macOS SDK from an unofficial site in order to build our developer conda packages.  This seems silly, but in fact is common practice among packagers who need to build with a consistent baseline of macOS support on automated systems.

As I understand it, Apple usually distributes these SDKs with specific XCode versions, and those XCode versions cannot be installed in an automated fashion since they require an Apple ID (either to get the latest one from the App Store, or to log into the Apple Developer Portal to download old XCode versions).  On CI systems where fixed worker images are provided, the desired SDK might not be present (as is in our case now on Azure), so the CI build process might actually need to download the desired SDK (say, for macOS 10.10 to maintain compatibility with Anaconda compilers).  This creates the demand for these unofficial SDK repositories, which I can only assume are violating Apple terms of use.  (Apple must know about this and either chooses to not to do anything about it, or maybe there is a license carve out for this?)

Anyway, the current solution of checking the downloaded SDK against a known hash is a good stop-gap to prevent someone from messing with the upstream repository later, but is not ideal.  Is there a better way to deal with this that someone else knows?  The main constraint is that you must be able to get the SDK installed in a fully-automated way without individual Apple ID credentials.
user: seibert
labels: discussion: An issue requiring discussion
issue_7640: state: open
title: Boolean operators behave differently when refactoring intermediate expression into variable
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Tested using numba 0.54.1 (Windows 10, python 3.8, numpy 1.19.2).

```
import numba
import numpy as np

@numba.jit()
def foobar():
    a = np.array([True])
    b = np.array([True])
    a_times_b = a * b
    print(~(a * b))
    print(~a_times_b)

foobar()
```

Output:
```
[ True]
[False]
```

I was expecting both lines to be `[False]`. Without the `@numba.jit()`, this prints `[False]` on both lines.

My best guess was a mix-up between `~` as bitwise negation vs. boolean negation. Adding an explicit `dtype=np.bool_` to the array constructors doesn't make a difference.
user: daanmichiels
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7624: state: open
title: Compare DeviceArray and CuPy arrays
body: In many cases using CuPy arrays is preferable to using Numba's device arrays, and I generally recommend people to use CuPy arrays and functionality, and write/call Numba CUDA kernels on them for functionality that's specific to their use case or otherwise unavailable in CuPy. However, the extent of overlap between CuPy arrays and Numba device arrays is unclear.

This issue records that we should:

- Check whether there are any differences between Numba device arrays and CuPy arrays, particularly where Numba arrays support something that CuPy does not, or where semantics deviate.
- Use this knowledge to make a long-term plan for how device arrays should be supported in the future.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7616: state: open
title: Local variable gets overwritten causing wrong gdb debugging display
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
# File simple_kernel.py
from numba import jit
import numpy as np

@jit(nopython=True, debug=True)
def double_add_1(a):
    one = 1.0
    result = a * 2 + one # breakpoint
    return result

def main():
    sz = 100
    a = np.ones((sz,), np.float32)
    out = double_add_1(a)

if __name__ == "__main__":
    main()
```

Reproducing debugging commands:
```shell
# shell
NUMBA_OPT=0 gdb python
# gdb commands
b simple_kernel.py:8
r simple_kernel.py
p one
```

`one` is expected to be 1.0, but is printed 0. The lines around the stopped at assembly from `disass`:
```
   0x00007fffe15f1339 <+825>:   movabs $0x3ff0000000000000,%r10
   0x00007fffe15f1343 <+835>:   mov    %r10,0x2b8(%rsp)
   0x00007fffe15f134b <+843>:   movq   $0x0,0x2b8(%rsp)
=> 0x00007fffe15f1357 <+855>:   movq   $0x2,0x2b0(%rsp)
   0x00007fffe15f1363 <+867>:   movq   $0x0,0x2b0(%rsp)
```
It looks like the constant 1.0 is loaded to `0x2b8(%rsp)` but was immediately set to 0 again. In gdb, `info one address` gives
`Symbol "one" is a variable at frame base reg $rsp offset 0+696.`

The below contains full `disass` output and `llvm_dump`
[disass_llvm_dump.zip](https://github.com/numba/numba/files/7645396/disass_llvm_dump.zip)




user: isVoid
labels: bug - DWARF: Bugs related to debugging support
issue_7615: state: open
title: Significant slow down on njit'd functions when optional arguments not provided
body: Hello I ran into a problem where an njit'd function that has optional arguments is almost 200 times slower then when the arguments are provided. 

I saw a similar issue from a [few years ago](https://github.com/numba/numba/issues/2029) which was resolved. Not sure if this is related or not. My numba and python versions are below.

```
import sys
import numba
import numpy as np

@numba.njit
def calc(x_squared, order_l: int = 2, init_l: int = 10):

    z = x_squared / (2. * init_l + 3.)
    for l_fake in range(order_l - 1, init_l - 1):
        l = init_l - l_fake
        l += 1
        z = x_squared / ((2. * l + 1.) - z)

    return z

%timeit calc(0.1)
%timeit calc(0.1, order_l=2, init_l=10)

# Perhaps an initial compile issue (even though timeit should catch that.), try running again
print('2nd Run')
%timeit calc(0.1)
%timeit calc(0.1, order_l=2, init_l=10)

print('\n')
print('python version:', sys.version)
print('numba version:', numba.__version__)
print('numpy version:', np.__version__)
```

Running this leads to the following output
```
54.3 µs ± 554 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
332 ns ± 3.34 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
2nd Run
54 µs ± 258 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
331 ns ± 2.76 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)


python version: 3.9.7 (default, Sep 16 2021, 16:59:28) [MSC v.1916 64 bit (AMD64)]
numba version: 0.54.1
numpy version: 1.20.3
```

As you can see the non argument provided version runs in around 54 us versus the provided version which is only 0.3 us!



user: jrenaud90
labels: performance - run time: Performance issue occurring at run time.
issue_7614: state: open
title: Make sure types.Type instances are not mutated
body: > it's because the type instance was mutated directly and the `name` of the type would not reflect this. Am happy to merge this patch as is, but for the future, perhaps it'd make sense to create a task for making types immutable to prevent this sort of accident from reoccurring?

_Originally posted by @stuartarchibald in https://github.com/numba/numba/pull/7610#pullrequestreview-821429226_

Todos:

- Use `@property` for attribute of `Type` instances.

user: sklam
labels: good second issue: A good issue for second time contributors
issue_7613: state: open
title: CUDA typing mode
body: Numba’s type inference is not well-suited to CUDA, and often assigns wider-than-necessary types to values. The effects are:

- This balloons register usage / reduces occupancy
- Reduces memory bandwidth efficiency,
- and forces the use of instructions that take more cycles than necessary.

Creating a specialized typing for CUDA so it is more appropriate for CUDA devices will alleviate these issues.

The pre-NBEP 1 typing was more appropriate for CUDA - since NBEP 1, likely worse for CUDA: https://numba.readthedocs.io/en/latest/proposals/integer-typing.html

See also this PR where I attempted to change the types of special indices (thread ID, block ID, etc) to be unsigned to match CUDA C/C++ - this mostly reduced the number of sign extension operations but occasionally resulted in float indices due to the typing: https://github.com/numba/numba/pull/6112
user: gmarkall
labels: CUDA: CUDA related issue/PR
performance: performance related issue
issue_7612: state: open
title: CUDA Benchmarking
body: There is presently no benchmark suite for Numba’s CUDA target, and there is a gap between Numba’s performance and the maximum achievable. To support performance optimization efforts, a benchmark suite is needed that:

- [ ] Runs regularly (with CI, perhaps before merge)
- [ ] Measures compilation time - this has been drifting upwards with each release.
- [ ] Measures kernel launch time - this is known to be slow in comparison to CUDA C/C++.
- [ ] Contains a set of micro-benchmarks to spot existing opportunities for optimization and avoid regressions.
- [ ] Benchmarks common real-world workloads (e.g. ETL operations, custom filters, etc.)

user: gmarkall
labels: CUDA: CUDA related issue/PR
performance: performance related issue
issue_7611: state: open
title: njit with parallel=True causes fatal Python error and aborted
body: # Reporting a bug

```
import time
import unittest
import pandas as pd
import numpy as np
from numba import njit, prange, typed

num_columns, num_rows, num_borders = 50, 100_000, 20
target_col = 'col0'

features = [f'col{i}' for i in range(num_columns)]
input_df = pd.DataFrame(np.random.rand(num_rows, num_columns), columns=features)
borders = tuple([x/100 for x in range(0, 100, 3)][:num_borders])


# ndarray_2d: N * M, ndarray_1d: N
def _compute(ndarray_2d, ndarray_1d, numba_list):
    for i in prange(len(borders)):
        filtered = (ndarray_2d >= borders[i]).astype(np.int_) # filtered: N * M
        filtered_1d = filtered.sum(axis=0).astype(np.float_) # filtered_1d: M
        another_filtered_1d = (filtered.transpose() * ndarray_1d).sum(axis=1) # another_filtered_1d: M
        for item in zip(filtered_1d, another_filtered_1d):
            numba_list.extend(item)


class MyTestCase(unittest.TestCase):
    @staticmethod
    def test_something():
        numba_list = typed.List()
        numba_list.append(0.1)
        ndarray_2d = input_df.to_numpy()
        ndarray_1d = input_df[target_col].to_numpy()

        njit_parallel_func = njit(parallel=True)(_compute)
        # njit_parallel_func(ndarray_2d, ndarray_1d, numba_list)

        python_func = _compute
        numba_list = []
        start_time = time.time()
        python_func(ndarray_2d, ndarray_1d, numba_list)
        print(f'python time = {time.time() - start_time}s')

        njit_func = njit(_compute)
        for _ in range(5):
            numba_list = typed.List()
            numba_list.append(0.1)
            middle_time = time.time()
            njit_func(ndarray_2d, ndarray_1d, numba_list)
            print(f'njit time = {time.time() - middle_time}s')


if __name__ == '__main__':
    unittest.main()

```

In this test code:

1. if uncomment `njit_parallel_func(ndarray_2d, ndarray_1d, numba_list)`, python process will be killed by sth bad happend in numba internal.
```
test_parallel.py::MyTestCase::test_something Fatal Python error: Aborted

Thread 0x000000011094f600 (most recent call first):
  File "/Users/.../debug-numba/test_parallel.py", line 36 in test_something
  File "/usr/local/anaconda3/lib/python3.8/unittest/case.py", line 633 in _callTestMethod
  File 
Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
```
I think this is a bug with `parallel=True`

2. Besides, the function `_compute()` run much slower than pure python, I couldn't figure it out where I don't write well for numba compilation.
```
python time = 0.7888021469116211s
njit time = 8.057817935943604s
njit time = 4.105954885482788s
njit time = 4.527366876602173s
njit time = 4.559357166290283s
njit time = 4.574266672134399s
```

3. I haven't check out whether the final `numba_list`s are equal.

Mac & conda env: Python 3.8.8 & numba  0.54.0 & numpy 1.19.5
user: dlee992
labels: performance - run time: Performance issue occurring at run time.
issue_7604: state: open
title: Added multiple axes support for np.expand_dims
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities here, please click the arrow besides
   "Create Pull Request" and choose "Create Draft Pull Request".
   When it's ready for review, you can click the button "ready to review" near
   the end of the pull request
   (besides "This pull request is still a work in progress".)
   The maintainers will then be automatically notified to review it.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

This PR adds support for passing multiple axes as a tuple to `np.expand_dims()`.

```python
import numpy as np
import numba

orig_shape = (3,4,5)
orig = np.random.normal(size=orig_shape)
new_order_tuple = (1, 3)

ref = np.expand_dims(orig, new_order_tuple)

@numba.njit
def expand_dims_fn(x, new_order):
    return np.expand_dims(x, new_order)

res = expand_dims_fn(orig, new_order_tuple)

print(ref.shape) # (3, 1, 4, 1, 5)
print(res.shape) # (3, 1, 4, 1, 5)
```

user: kc611
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - medium: Medium size effort needed
issue_7602: state: open
title: Casting error when creating jitclass with list of nested jitclass objects
body: When creating a jitclass where one of elements is a list of objects of jitclass, containing other jitclass object, there is an error:
```
import numba as nb
import numba.experimental as nbe
from numba import deferred_type


@nbe.jitclass()
class Element:
    def __init__(self):
        pass


Element_type = deferred_type()
Element_type.define(Element.class_type.instance_type)


@nbe.jitclass([("calls", Element_type)])
class Container:
    def __init__(self, calls: Element):
        self.calls: Element = calls


Container_type = deferred_type()
Container_type.define(Container.class_type.instance_type)

Container_list_instance = nb.typed.List()
c = Container(Element())
Container_list_instance.append(c)


@nbe.jitclass([("l", nb.types.ListType(Container_type))])
class DataSnapshot:
    def __init__(self, l):
        self.l = l


def main():
    t = Container(Element())
    l = nb.typed.List()
    l.append(t)
    a = DataSnapshot(l)


if __name__ == "__main__":
    main()

```

```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x000001B68F46FC70>.
Failed in nopython mode pipeline (step: native lowering)
Cannot cast ListType[instance.jitclass.Container#1b6ff59f160<calls:DeferredType#1884643296784>] to ListType[DeferredType#1885479760080]: %"inserted.data.1" = insertvalue {i8*, i8*} %"inserted.meminfo.1", i8* %"arg.l.1", 1

File "start_numba.py", line 33:
    def __init__(self, l):
        self.l = l
        ^

```
numba 0.54.0
user: a-gms
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7601: state: open
title: Pickling error when creating jitclass with list of nested jitclass objects, v0.54
body: When creating a jitclass where one of elements is a list of objects of jitclass, containing other jitclass object, there is an error:
```
import numba as nb
import numba.experimental as nbe
from numba import deferred_type


@nbe.jitclass()
class Element:
    def __init__(self):
        pass


Element_type = deferred_type()
Element_type.define(Element.class_type.instance_type)


@nbe.jitclass([("el", Element_type)])
class Container:
    def __init__(self, el: Element):
        self.el: Element = el


Container_type = deferred_type()
Container_type.define(Container.class_type.instance_type)

Container_list_instance = nb.typed.List()
c = Container(Element())
Container_list_instance.append(c)


@nbe.jitclass([("l", nb.typeof(Container_list_instance))])
class BiggerContainer:
    def __init__(self, l):
        self.l = l


def main():
    t = Container(Element())
    l = nb.typed.List()
    l.append(t)
    BiggerContainer(l)


if __name__ == "__main__":
    main()
```

```
    raise pickle.PicklingError(f"Pickling of {type(obj)} is unsupported")
_pickle.PicklingError: Failed in nopython mode pipeline (step: native lowering)
Failed in nopython mode pipeline (step: native lowering)
Pickling of <class 'numba.experimental.jitclass.base.JitClassType'> is unsupported
```

I tried using also 
```@nbe.jitclass([("l", nb.types.ListType(typeof(c)))])```
which gives the same error

user: a-gms
issue_7595: state: open
title: failed to change arrays in list in a for loop
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python

import numpy as np
from numba import njit
from numba.typed import List


def check(arrays):
    for a in arrays:
        assert (a[:, 0] == 3.14).all()


@njit
def func1():
    outs = List([np.empty((3, 4)) for i in range(5)])
    for o in outs:
        o[:, 0] = 3.14
    return outs


ls1 = func1()
check(ls1)


@njit
def func2():
    outs = List([np.empty((3, 4)) for i in range(5)])
    for i, _ in enumerate(outs):
        outs[i][:, 0] = 3.14
    return outs


ls2 = func2()
check(ls2)


@njit
def func3(outs):
    for o in outs:
        o[:, 0] = 3.14
    return outs


ls3 = func3(List([np.empty((3, 4)) for i in range(5)]))
check(ls3)

```
The first func will not pass the check.

When iterating over a list of arrays, if the array is stored to a temp variable as in func1, the corresponding array remains unchanged. The array in the list have to be accessed with the i locator, in order to be modified (func2).

If the array is predefined and sent to the function (func3), no errors will occur.


user: auderson
labels: bug - miscompile: Bugs: miscompile
issue_7592: state: open
title: Invalid static_getitem const inference for list comprehension
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
`RewriteConstGetitems` wrongly infers the output of a list comprehension as an empty list and generates an incorrect `static_getitem`.

Here is a small reproducer (actual use case is something different):

```python
import numba
import numpy as np

@numba.njit
def f(A, B):
    l = [a for a in B]
    return A[l]


A = np.arange(11)
B = [3, 4]
f(A, B)
```
IR right before type inference:
```
label 0:
    A = arg(0, name=A)                       ['A']
    B = arg(1, name=B)                       ['B']
    $10get_iter.4 = getiter(value=B)         ['$10get_iter.4', 'B']
    implicit0.0 = $10get_iter.4              ['$10get_iter.4', 'implicit0.0']
    $2build_list.0.1 = build_list(items=[])  ['$2build_list.0.1']
    $phi16.0.3 = $2build_list.0.1            ['$2build_list.0.1', '$phi16.0.3']
    $phi8.0.4 = $2build_list.0.1             ['$2build_list.0.1', '$phi8.0.4']
    $phi6.1.5 = implicit0.0                  ['$phi6.1.5', 'implicit0.0']
    jump 8                                   []
label 8:
    $6for_iter.2.6 = iternext(value=$phi6.1.5) ['$6for_iter.2.6', '$phi6.1.5']
    $6for_iter.3.7 = pair_first(value=$6for_iter.2.6) ['$6for_iter.2.6', '$6for_iter.3.7']
    $6for_iter.4.8 = pair_second(value=$6for_iter.2.6) ['$6for_iter.2.6', '$6for_iter.4.8']
    $phi8.2.9 = $6for_iter.3.7               ['$6for_iter.3.7', '$phi8.2.9']
    branch $6for_iter.4.8, 10, 18            ['$6for_iter.4.8']
label 10:
    a.10 = $phi8.2.9                         ['$phi8.2.9', 'a.10']
    $12list_append.4.12 = getattr(value=$phi8.0.4, attr=append) ['$12list_append.4.12', '$phi8.0.4']
    $12list_append.5.13 = call $12list_append.4.12(a.10, func=$12list_append.4.12, args=(Var(a.10, getitem_bug.py:6),), kws=(), vararg=None, target=None) ['$12list_append.4.12', '$12list_append.5.13', 'a.10']
    jump 8                                   []
label 18:
    $16return_value.1.14 = $phi16.0.3        ['$16return_value.1.14', '$phi16.0.3']
    l = $16return_value.1.14                 ['$16return_value.1.14', 'l']
    $20binary_subscr.8 = static_getitem(value=A, index=[], index_var=l, fn=<built-in function getitem>) ['$20binary_subscr.8', 'A', 'l']
    $22return_value.9 = cast(value=$20binary_subscr.8) ['$20binary_subscr.8', '$22return_value.9']
    return $22return_value.9                 ['$22return_value.9']
```
user: ehsantn
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7590: state: open
title: Fix GUFunc.at use by automatic compilation of the required signature.
body: Following on from: https://github.com/numba/numba/pull/7403#pullrequestreview-811752860

> This patch will fix the regression of missing ufunc interface. However, requiring an invocation to GUFunc.__call__ before a GUFunc.at can be used in the case of dynamic gufunc is not very user friendly. There needs to be a follow up PR to add automatic compiling of the required signature.

This ticket is to record the outstanding task, which is to do the above comment.
user: stuartarchibald
issue_7589: state: open
title: Update simplify_CFG to handle dead blocks
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

This is partially a feature request and partially a clarification question. Within my workflow I will sometimes generate code to inline an operation and then immediately call `simplify_CFG` to merge basic blocks. I have noticed that if there are any unreachable blocks, then may fail with various error messages.

I can avoid this by deleting these blocks before calling `simplify_CFG`, but I don't see any comment in `simplify_CFG` assuming to all dead blocks have been pruned. I think ideally this could be included directly in the function. The change I'm requesting would look like this

```python
cfg = compute_cfg_from_blocks(blocks)
for dead in cfg.dead_nodes():
            del blocks[dead]
```

Alternatively I would be fine if the comments clarified these must be removed before calling `simplify_CFG`. In either situation I'm happy to submit a PR.

I'm not sure if this can be done in pure Numba, but here is a dummy compiler pass that replaces a branch with a Jump to introduce a dead block. This is mean to emulate a situation in which some stage of inlining could introduce a branch that needs to be pruned.

```python
import numba
import numpy as np
from numba.core import ir
from numba.core.compiler_machinery import FunctionPass, PassManager, register_pass
from numba.core.compiler import DefaultPassBuilder
from numba.core.typed_passes import PreLowerStripPhis

@register_pass(analysis_only=False, mutates_CFG=True)
class DummySimplifyPass(FunctionPass):
    """
        A Pipeline stage that emulates calling simplify_CFG
        when inlining before all dead branches have been pruned.
    """
    _name = "dummy_simplify_pass"

    def __init__(self):
        FunctionPass.__init__(self)

    def run_pass(self, state):
        mutated = False
        for blk in state.func_ir.blocks.values():
            # find the assignment nodes in the block and walk them
            new_body = []
            for inst in blk.body:
                if isinstance(inst, ir.Branch):
                    # Replace the branch with a jump Falsebr to introduce a dead block
                    inst = ir.Jump(inst.falsebr, inst.loc)
                new_body.append(inst)
            blk.body = new_body

        state.func_ir.blocks = numba.core.ir_utils.simplify_CFG(state.func_ir.blocks)
        return mutated


class SimplifyCFGCompiler(numba.core.compiler.CompilerBase):
    def define_pipelines(self):
        """create compiler pipeline that calls simplify_cfg before `remove_dead`"""

        name = "sort_pipeline"
        pm = DefaultPassBuilder.define_nopython_pipeline(self.state, name)
        pm._finalized = False
        idx = pm.passes.index((PreLowerStripPhis, 'remove phis nodes'))
        pm.passes.insert(idx, (DummySimplifyPass, 'Call simplify before remove_dead'))
        pm.finalize()
        return [pm]

@numba.njit(pipeline_class=SimplifyCFGCompiler)
def ex(cond):
    if cond:
        return 1
    else:
        return 0


print(ex(True))
```
user: njriasan
labels: discussion: An issue requiring discussion
issue_7579: state: open
title: Lowering error using character sequences in record types
body: After #7057 is merged, it still will not be possible to use character sequences in record types due to a lowering error. An example reproducer:

```python
import numpy as np
from numba import cuda

@cuda.jit
def f(a):
    a[0].x = 2
    a[0].y = 'OOF'

dt = np.dtype([('x', np.float32), ('y', np.dtype('<U12'))])
a = np.zeros(1, dt)
f[1, 1](a)
```

results in:

```
blah blah blah blah...

  File "/home/gmarkall/numbadev/numba/numba/core/base.py", line 716, in cast
    raise errors.NumbaNotImplementedError(
numba.core.errors.NumbaNotImplementedError: Failed in cuda mode pipeline (step: native lowering)
Cannot cast Literal[str](OOF) to [unichr x 12]: i8* null
During: lowering "($18binary_subscr.7).y = $const12.4" at /home/gmarkall/numbadev/issues/charseq-in-record/repro.py (8)
```
user: gmarkall
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7574: state: open
title: Add support for non-constant boundaries for numba.stencil
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request


I'm interested in implementing the following stencil corresponding to the 1D Poisson stencil:

```python
def poisson_stencil_1d(u, b):
    u_new = np.zeros_like(u)
    N = u.shape[0]
    for i in range(N):
        u_new[i] = 0.5*b[i]
        if i > 1:
            u_new[i] += 0.5*u[i-1]
        if i < N-1:
            u_new[i] += 0.5*u[i+1]
    return u_new
```

My initial attempt using `@numba.stencil` was 

```python
@numba.stencil
def poisson_stencil_1d(u, b):
    return 0.5*(b[0] + u[-1] + u[1])
```

However this does not do any "special" handling of the endpoints thus leading to an incorrect solution. I'm not exactly sure what the API should look like in this case, but it would be nice to support something like this. My current solution is to just decorate my working stencil with `@njit` which is OK, but feels less pure.

user: erip
labels: stencil: Issue involving stencils
issue_7572: state: open
title: Object mode code fails to load from cache
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Object mode code below fails to load from cache. The problem is that the objmode dispatcher is serialized and compiled during runtime (see [here](https://github.com/numba/numba/blob/5fc9d3c56da4e4c6aef7189e588ce9c44263d4a6/numba/core/pythonapi.py#L1641)).
However, the function IR saved is invalid. The issue is that func_ir.copy() is used to avoid compiler's mutations, but this doesn't copy the IR nodes, which are modified in places like [here](https://github.com/numba/numba/blob/5fc9d3c56da4e4c6aef7189e588ce9c44263d4a6/numba/core/ir_utils.py#L476). Avoiding these copy() calls before dispatcher compilation but adding remove_dels after compilation solves the problem. Are these copy() calls necessary?

```python
import numba
import pandas as pd

@numba.njit(cache=True)
def f():

  with numba.objmode(T="int64"):
    typemap = {}
    typemap.update({i:"Int64" for i in range(3)})
    df = pd.DataFrame()
    arrs = []
    for i in range(df.shape[1]):
      arrs.append(df.iloc[:, i].values)
    T = len(arrs)
  return (T,)


f()
```
```
 ✗ python ../tmp/objmode_test.py
 ✗ python ../tmp/objmode_test.py
Traceback (most recent call last):
  File "/Users/ehsan/dev/bodo/../tmp/objmode_test.py", line 18, in <module>
    f()
  File "/Users/ehsan/dev/numba/numba/core/pythonapi.py", line 1682, in _call_objmode_dispatcher
    entrypt = dispatcher.compile(argtypes)
  File "/Users/ehsan/dev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/ehsan/dev/numba/numba/core/dispatcher.py", line 1329, in compile
    return super().compile(sig)
  File "/Users/ehsan/dev/numba/numba/core/dispatcher.py", line 1210, in compile
    cres = compiler.compile_ir(typingctx=self.typingctx,
  File "/Users/ehsan/dev/numba/numba/core/compiler.py", line 724, in compile_ir
    norw_cres = compile_local(func_ir.copy(), norw_flags)
  File "/Users/ehsan/dev/numba/numba/core/compiler.py", line 720, in compile_local
    return pipeline.compile_ir(func_ir=the_ir, lifted=lifted,
  File "/Users/ehsan/dev/numba/numba/core/compiler.py", line 438, in compile_ir
    return self._compile_ir()
  File "/Users/ehsan/dev/numba/numba/core/compiler.py", line 499, in _compile_ir
    return self._compile_core()
  File "/Users/ehsan/dev/numba/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/Users/ehsan/dev/numba/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/ehsan/dev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/ehsan/dev/numba/numba/core/typed_passes.py", line 794, in run_pass
    post_proc.run(emit_dels=False)
  File "/Users/ehsan/dev/numba/numba/core/postproc.py", line 78, in run
    self.func_ir.blocks = transforms.canonicalize_cfg(self.func_ir.blocks)
  File "/Users/ehsan/dev/numba/numba/core/transforms.py", line 315, in canonicalize_cfg
    return canonicalize_cfg_single_backedge(blocks)
  File "/Users/ehsan/dev/numba/numba/core/transforms.py", line 244, in canonicalize_cfg_single_backedge
    cfg = compute_cfg_from_blocks(blocks)
  File "/Users/ehsan/dev/numba/numba/core/analysis.py", line 243, in compute_cfg_from_blocks
    cfg.add_edge(k, target)
  File "/Users/ehsan/dev/numba/numba/core/controlflow.py", line 112, in add_edge
    raise ValueError("Cannot add edge as dest node %s not in nodes %s" %
ValueError: Failed in object mode pipeline (step: remove phis nodes)
Cannot add edge as dest node 119 not in nodes {102, 70, 72, 12, 14, 112}
```
user: ehsantn
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7569: state: open
title: for-with-break construct fails on Pythons 3.7 and 3.8
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

The for-with-break case does not succeed through bytecode interpretation.

```
from numba import njit, objmode

@njit
def liftcall5():
    for i in range(10):
        with objmode:
            if i == 5:
                print("A")
                break
    return 10

liftcall5()
```

On 3.7:

```
Traceback (most recent call last):
  File "forwithbreak.py", line 12, in <module>
    liftcall5()
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 487, in _compile_for_args
    raise e
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 965, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 125, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 139, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 157, in _compile_core
    pipeline_class=self.pipeline_class)
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 690, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 496, in _compile_bytecode
    return self._compile_core()
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 342, in run
    raise e
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/vhaenel/git/numba/numba/core/untyped_passes.py", line 86, in run_pass
    func_ir = interp.interpret(bc)
  File "/Users/vhaenel/git/numba/numba/core/interpreter.py", line 358, in interpret
    flow.run()
  File "/Users/vhaenel/git/numba/numba/core/byteflow.py", line 104, in run
    first_encounter[state.pc_initial] = state
  File "/Users/vhaenel/git/numba/numba/core/utils.py", line 375, in __setitem__
    raise AssertionError("key already in dictionary: %r" % (key,))
AssertionError: key already in dictionary: 54
```

on 3.8

```
Traceback (most recent call last):
  File "forwithbreak.py", line 12, in <module>
    liftcall5()
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 487, in _compile_for_args
    raise e
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 965, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 125, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 139, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 152, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 690, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 496, in _compile_bytecode
    return self._compile_core()
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 475, in _compile_core
    raise e
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 346, in run
    raise patched_exception
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/vhaenel/git/numba/numba/core/untyped_passes.py", line 86, in run_pass
    func_ir = interp.interpret(bc)
  File "/Users/vhaenel/git/numba/numba/core/interpreter.py", line 358, in interpret
    flow.run()
  File "/Users/vhaenel/git/numba/numba/core/byteflow.py", line 104, in run
    first_encounter[state.pc_initial] = state
  File "/Users/vhaenel/git/numba/numba/core/utils.py", line 375, in __setitem__
    raise AssertionError("key already in dictionary: %r" % (key,))
AssertionError: Failed in nopython mode pipeline (step: analyzing bytecode)
key already in dictionary: 62
```

On 3.9, the correct error will be raised:

```
Traceback (most recent call last):
  File "/Users/vhaenel/git/numba/forwithbreak.py", line 12, in <module>
    liftcall5()
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 487, in _compile_for_args
    raise e
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 965, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 125, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 139, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/Users/vhaenel/git/numba/numba/core/dispatcher.py", line 152, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 690, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 496, in _compile_bytecode
    return self._compile_core()
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 475, in _compile_core
    raise e
  File "/Users/vhaenel/git/numba/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 346, in run
    raise patched_exception
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/vhaenel/git/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/vhaenel/git/numba/numba/core/untyped_passes.py", line 253, in run_pass
    main, withs = transforms.with_lifting(
  File "/Users/vhaenel/git/numba/numba/core/transforms.py", line 353, in with_lifting
    _legalize_withs_cfg(withs, cfg, blocks)
  File "/Users/vhaenel/git/numba/numba/core/transforms.py", line 499, in _legalize_withs_cfg
    raise errors.CompilerError(msg, loc=loc)
numba.core.errors.CompilerError: Failed in nopython mode pipeline (step: Handle with contexts)
Does not support with-context that contain branches (i.e. break/return/raise) that can leave the with-context. Details: exit of with-context not post-dominating the entry.

File "forwithbreak.py", line 6:
def liftcall5():
    <source elided>
    for i in range(10):
        with objmode:
```
user: esc
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7568: state: open
title: Using literally suppresses info in compilation failure traceback
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi,

This is regarding `numba.literally` which is working normally itself, but has a shortcoming of masking the real compilation error when it is applied before compilation reaches some non-supported code, i.e. the compilation failure traceback only references to 'Repeated literal typing request', but not to the root cause of compilation failure, which complicates the debugging. Here's the example that demonstrates the problem:

```
import numba
from numba import njit, literally
from numba.core import types
from numba.extending import overload
from numba.core.errors import TypingError

def foo(x):
    pass

def bar(y):
    pass

@overload(bar)
def bar_ovld(y):

    # consider this is the only impl that is currently provided, and reject others with TypingError
    if not isinstance(y, types.NoneType):
        raise TypingError("bar only supported arg is None")

    return lambda y: 43

@overload(foo)
def foo_ovld(x):
    if not isinstance(x, types.Literal):
        return lambda x: literally(x)

    x_literal_val = x.literal_value
    def foo_impl(x):
        if x_literal_val == 1:
            return 42
        else:
            return bar(x)

    return foo_impl

@njit
def test_impl(x):
    return foo(x)

val = 'sdf'
print(test_impl(val))
```

This prints the following huge traceback, that has no references to `bar`'s TypingError message (in case of some LoweringError from the bar_impl it would be suppressed too, so it becomes difficult to understand what went wrong):

> (NUMBA_MASTER_4) C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba>python test_literally_err.py
> Traceback (most recent call last):
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 979, in compile
>     cres = self._compiler.compile(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 141, in compile
>     status, retval = self._compile_cached(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 155, in _compile_cached
>     retval = self._compile_core(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 173, in _compile_core
>     pipeline_class=self.pipeline_class)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 686, in compile_extra
>     return pipeline.compile_extra(func)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 428, in compile_extra
>     return self._compile_bytecode()
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 492, in _compile_bytecode
>     return self._compile_core()
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 471, in _compile_core
>     raise e
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 462, in _compile_core
>     pm.run(self.state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 343, in run
>     raise patched_exception
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 334, in run
>     self._runPass(idx, pass_inst, state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 289, in _runPass
>     mutated |= check(pss.run_pass, internal_state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 262, in check
>     mangled = func(compiler_state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\untyped_passes.py", line 430, in run_pass
>     find_literally_calls(state.func_ir, state.args)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\analysis.py", line 620, in find_literally_calls
>     raise errors.ForceLiteralArg(marked_args, loc=loc)
> numba.core.errors.ForceLiteralArg: Failed in nopython mode pipeline (step: find literally calls)
> Pseudo-exception to force literal arguments in the dispatcher
> 
> File "test_literally_err.py", line 28:
> def foo_ovld(x):
>     <source elided>
>     if not isinstance(x, types.Literal):
>         return lambda x: literally(x)
>         ^
> 
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 589, in resolve
>     sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 1541, in resolve_call
>     return self.context.resolve_function_type(fnty, pos_args, kw_args)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typing\context.py", line 195, in resolve_function_type
>     res = self._resolve_user_function_type(func, args, kws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typing\context.py", line 247, in _resolve_user_function_type
>     return func.get_call_type(self, args, kws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\types\functions.py", line 348, in get_call_type
>     failures.raise_error()
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\types\functions.py", line 226, in raise_error
>     raise fail.error
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\types\functions.py", line 329, in get_call_type
>     sig = temp.apply(nolitargs, nolitkws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typing\templates.py", line 351, in apply
>     sig = generic(args, kws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typing\templates.py", line 605, in generic
>     disp, new_args = self._get_impl(args, kws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typing\templates.py", line 704, in _get_impl
>     impl, args = self._build_impl(cache_key, args, kws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typing\templates.py", line 805, in _build_impl
>     disp_type.get_call_type(self.context, args, kws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\types\functions.py", line 555, in get_call_type
>     self.dispatcher.get_call_template(args, kws)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 377, in get_call_template
>     self.compile(tuple(args))
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 984, in compile
>     raise e.bind_fold_arguments(folded)
> numba.core.errors.ForceLiteralArg: Pseudo-exception to force literal arguments in the dispatcher
> 
> File "test_literally_err.py", line 28:
> def foo_ovld(x):
>     <source elided>
>     if not isinstance(x, types.Literal):
>         return lambda x: literally(x)
>         ^
> 
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 979, in compile
>     cres = self._compiler.compile(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 141, in compile
>     status, retval = self._compile_cached(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 155, in _compile_cached
>     retval = self._compile_core(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 173, in _compile_core
>     pipeline_class=self.pipeline_class)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 686, in compile_extra
>     return pipeline.compile_extra(func)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 428, in compile_extra
>     return self._compile_bytecode()
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 492, in _compile_bytecode
>     return self._compile_core()
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 471, in _compile_core
>     raise e
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 462, in _compile_core
>     pm.run(self.state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 343, in run
>     raise patched_exception
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 334, in run
>     self._runPass(idx, pass_inst, state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 289, in _runPass
>     mutated |= check(pss.run_pass, internal_state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 262, in check
>     mangled = func(compiler_state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typed_passes.py", line 112, in run_pass
>     raise_errors=self._raise_errors)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typed_passes.py", line 83, in type_inference_stage
>     errs = infer.propagate(raise_errors=raise_errors)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 1076, in propagate
>     raise reduce(operator.or_, force_lit_args)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 154, in propagate
>     constraint(typeinfer)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 566, in __call__
>     self.resolve(typeinfer, typevars, fnty)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 607, in resolve
>     raise ForceLiteralArg(requested, loc=self.loc)
> numba.core.errors.ForceLiteralArg: Failed in nopython mode pipeline (step: nopython frontend)
> Pseudo-exception to force literal arguments in the dispatcher
> 
> File "test_literally_err.py", line 43:
> def test_impl(x):
>     return foo(x)
>     ^
> 
> During: resolving callee type: Function(<function foo at 0x000001AAD5AACA68>)
> During: typing of call at test_literally_err.py (43)
> 
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 434, in _compile_for_args
>     return_val = self.compile(tuple(argtypes))
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 984, in compile
>     raise e.bind_fold_arguments(folded)
> numba.core.errors.ForceLiteralArg: Pseudo-exception to force literal arguments in the dispatcher
> 
> File "test_literally_err.py", line 43:
> def test_impl(x):
>     return foo(x)
>     ^
> 
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 979, in compile
>     cres = self._compiler.compile(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 141, in compile
>     status, retval = self._compile_cached(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 155, in _compile_cached
>     retval = self._compile_core(args, return_type)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 173, in _compile_core
>     pipeline_class=self.pipeline_class)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 686, in compile_extra
>     return pipeline.compile_extra(func)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 428, in compile_extra
>     return self._compile_bytecode()
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 492, in _compile_bytecode
>     return self._compile_core()
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 471, in _compile_core
>     raise e
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 462, in _compile_core
>     pm.run(self.state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 343, in run
>     raise patched_exception
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 334, in run
>     self._runPass(idx, pass_inst, state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 289, in _runPass
>     mutated |= check(pss.run_pass, internal_state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 262, in check
>     mangled = func(compiler_state)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typed_passes.py", line 112, in run_pass
>     raise_errors=self._raise_errors)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typed_passes.py", line 83, in type_inference_stage
>     errs = infer.propagate(raise_errors=raise_errors)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 1076, in propagate
>     raise reduce(operator.or_, force_lit_args)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 154, in propagate
>     constraint(typeinfer)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 566, in __call__
>     self.resolve(typeinfer, typevars, fnty)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 607, in resolve
>     raise ForceLiteralArg(requested, loc=self.loc)
> numba.core.errors.ForceLiteralArg: Failed in nopython mode pipeline (step: nopython frontend)
> Pseudo-exception to force literal arguments in the dispatcher
> 
> File "test_literally_err.py", line 43:
> def test_impl(x):
>     return foo(x)
>     ^
> 
> During: resolving callee type: Function(<function foo at 0x000001AAD5AACA68>)
> During: typing of call at test_literally_err.py (43)
> 
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 434, in _compile_for_args
>     return_val = self.compile(tuple(argtypes))
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 984, in compile
>     raise e.bind_fold_arguments(folded)
> numba.core.errors.ForceLiteralArg: Pseudo-exception to force literal arguments in the dispatcher
> 
> File "test_literally_err.py", line 43:
> def test_impl(x):
>     return foo(x)
>     ^
> 
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "test_literally_err.py", line 47, in <module>
>     print(test_impl(val))
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 457, in _compile_for_args
>     return_val = self._compile_for_args(*args)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 450, in _compile_for_args
>     raise errors.CompilerError(m.format(info))
> numba.core.errors.CompilerError: Repeated literal typing request.
> Arg #0 is Literal[str](sdf).
> This is likely caused by an error in typing. Please see nested and suppressed exceptions.
> 

Best Regards,
Alexey.
user: kozlov-alexey
labels: discussion: An issue requiring discussion
issue_7566: state: open
title: Support nested tuples as tuples of literal elements
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi, 

I recently encountered a case when type-inference tends to 'unliteral' tuple elements (more precisely nested tuples elements), which seems quite odd because similar code expressed differently may work or not work. Here's the reproducer:
```
from numba import njit
from numba.core import types
from numba.extending import overload


def bar(x):
    pass

@overload(bar, prefer_literal=True)
def bar_ovld(x):
    assert (isinstance(x, types.BaseTuple)
            and isinstance(x[0], types.BaseTuple)
            and isinstance(x[0][0], types.StringLiteral)), \
            f"bar only supported with literal first values in tuple elements, given: {x}"

    return lambda x: 42


b = ('A', 1)

@njit()
def test_impl_1():
    a = (b, )
    return bar(a)


@njit()
def test_impl_2():
    b = ('A', 1)
    a = (b, )
    return bar(a)


@njit()
def test_impl_3():
    a = (('A', 1), )
    return bar(a)


# tested = test_impl_2    # this works
tested = test_impl_3    # this fails due to non-literal tuple received by bar

print(tested())
tested.inspect_types()
```

In this case both capturing a tuple as a global variable or creating an inner tuple a separate variable works, so that `bar` compiles and runs with signature: `(UniTuple(Tuple(Literal[str](A), Literal[int](1)) x 1),) -> Literal[int](42)`. But `test_impl_3` fails with:
> There are 2 candidate implementations:
>   - Of which 2 did not match due to:
>   Overload in function 'bar_ovld': File: ..\..\..\..\..\hpat\test_numba_1.py: Line 9.
>     With argument(s): '(UniTuple(Tuple(unicode_type, int64) x 1))':
>    Rejected as the implementation raised a specific error:
>      AssertionError: bar only supported with literal first values in tuple elements, given: UniTuple(Tuple(unicode_type, int64) x 1)
>   raised from test_numba_1.py:14

because the IR in this case has a `const_('A', 1)` node, which is type-inferred via `typeof_const`, that attempts to find `Literal` ctor for tuples and fails:
```
>>> self.func_ir.dump()
label 0:
    $const_('A', 1) = const(tuple, ('A', 1)) ["$const_('A', 1)"]
    a = build_tuple(items=[Var($const_('A', 1), test_numba_1.py:99)]) ["$const_('A', 1)", 'a']
    $6load_global.1 = global(bar: <function bar at 0x0000014780D9ADC8>) ['$6load_global.1']
    $10call_function.3 = call $6load_global.1(a, func=$6load_global.1, args=[Var(a, test_numba_1.py:99)], kws=(), vararg=None, target=None) ['$10call_function.3', '$6load_global.1', 'a']
    $12return_value.4 = cast(value=$10call_function.3) ['$10call_function.3', '$12return_value.4']
    return $12return_value.4                 ['$12return_value.4']

>>> str(inst)
"$const_('A', 1) = const(tuple, ('A', 1))"
>>> inst.value
const(tuple, ('A', 1))
>>> inst.value.use_literal_type
True
>>> ty
<class 'tuple'>
>>> Literal.ctor_map[ty]
Traceback (most recent call last):
  File "C:\Users\akozlov\eclipse\cpp-2020-03\eclipse\plugins\org.python.pydev.core_8.0.0.202009061309\pysrc\_pydevd_bundle\pydevd_exec2.py", line 3, in Exec
    exec(exp, global_vars, local_vars)
  File "<console>", line 1, in <module>
KeyError: <class 'tuple'>
```

I was wondering if it's possible (or would be a good thing) to extend the `types.misc.literal` so that it will type-infer tuples as literal types as well? At first glance it seems beneficial to align the behavior, as well as preserve literality of tuple elements as long as possible. What do you think?

Best Regards,
Alexey.

user: kozlov-alexey
labels: bug - incorrect behavior: Bugs: incorrect behavior
bug - typing: Bugs: occuring at typing time
issue_7565: state: open
title: Frozenset support
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Would it be possible to have support for `frozenset`s in numba in nopython mode?  This way they could, for instance, be members of other sets or keys in dicts.

user: hroskes
issue_7542: state: open
title: [Docs] Wrong link to `np_shape` source code in docs
body: Hello,

It appears that the link to the implementation of `np_shape` function is not correct [here](https://numba.pydata.org/numba-doc/dev/developer/autogen_numpy_listing.html#numpy.shape). The lines should be [L2077-L2083](https://github.com/numba/numba/blob/master/numba/np/arrayobj.py#L2077-L2083).

If you want, I can propose a PR with a fix.
user: jeertmans
labels: good second issue: A good issue for second time contributors
bug - documentation incorrect: documentation is incorrect or missing something important
issue_7541: state: open
title: [Idea] A less verbose @jitclass interface with type hints
body: Hello everyone,

### Context
I really like the power that Numba offers for rapidly developing ideas, and I think that the compilation of Python classes is a complex but great feature that can be further developed. Until now, I have not used that feature a lot, mainly due to its limitations, but from time to time it appears to be very useful.

However, the steps that are required to jit a class are, in my opinion, quite verbose, and are not placed at the best spot.
I think that the beauty of Numba resides in its simplicity: you can leverage a lot by just putting the `jit` decorator before a function definition. As well, Python's development seems to improve, versions after versions, the use of type hints.

### Idea
Therefore, I propose to extend the current `jitclass` decorator to detect and infer types from attributes that are defined in the `__init__` function (and it could be extended to other methods too).

Here I show an idea (based on the example from the [docs](https://numba.pydata.org/numba-doc/dev/user/jitclass.html#basic-usage)) of how it could look:

```python
import numpy as np
from numba import int32, float32    # import the types
from numba.experimental import jitclass

# Old way #######################################
spec = [
    ('value', int32),               # a simple scalar field
    ('array', float32[:]),          # an array field
]

@jitclass(spec)
class Bag(object):
    def __init__(self, value):
        self.value = value
        self.array = np.zeros(value, dtype=np.float32)

# New way #######################################
@jitclass
class Bag(object):
    def __init__(self, value):
        self.value: int32 = value
        self.array: float32[:] = np.zeros(value, dtype=np.float32)
```

### Similarities with #5609

I am aware that a similar feature has been developed. However, it seems weird to declare instance attributes if they were class attributes, which they are not as it raises an AttributeError and, to my knowledge, Numba does not support jitting class attributes yet.
```python
@jitclass
class Bag(object):
    value: int32
    array: float32[:]
    def __init__(self, value):
        self.value: int32 = value
        self.array = np.zeros(value, dtype=np.float32)

Bag.value  # Raises `AttributeError: type object 'Bag' has no attribute 'value'`
```

### Implementation

I think a working implementation may be to overload current decorator to first search for attributes and, then, extend the (possibly empty) list of specs.

If you want, I would be glad to give it a try and propose a PR when I am ready!

### Pros
1. Backward-compatibility should be easily maintained
2. Less verbose
3. Could also be used for Class attributes (when supported)
4. Should work with static type checkers (MyPy, ...)

Of course, I am open to any comment.
Hopefully, this is not a duplicate. In other cases, I will close this issue ;)
user: jeertmans
labels: discussion: An issue requiring discussion
issue_7534: state: open
title: Include non-temporal JIT annotations to speed up memory-bound codes filling big arrays
body: Hello everyone, 

x86/x86-64 processors have [non-temporal store instructions](https://stackoverflow.com/questions/37070/what-is-the-meaning-of-non-temporal-memory-accesses-in-x86) that can be used to avoid a cache-line allocation when memory writes are performed. They are very useful to speed up memory-bound kernels filling huge arrays that do not fit in the CPU cache. Indeed, in such a case, most x86 processors will load the entire arrays from memory to actually fill them while no load are actually needed. This is unfortunate as half of the bandwidth is consume for reading unnecessary data to be fetched. The memory bandwidth is a scarce resource (and it is getting more and more scarce over the past two decades). Non-temporal store help to avoid such a waste.

Numba do not currently generate non-temporal store one x86-like platforms for `np.fill` as opposed to the default Numpy implementation. This results in a significant performance gap. Here is an example:

```python
import numpy as np
import numba as nb

@nb.njit('void(float64[::1])')
def fillArr(arr):
    assert arr.size == 128*1024*1024  # May help the JIT to generate a more efficient code (but not much in practice)
    arr.fill(0.0)

arr = np.full(128*1024*1024, 0.0, dtype=np.float64)
%timeit arr.fill(0.0)
%timeit fillArr(arr)
```

And here is the result on my machine (with a i5-9600KF processor and a 2-channels DDR4 RAM capable of achieving up to ~40 GiB/s):

```
Numpy: 32.2 ms ± 1.83 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)  => 31.1 GiB/s
Numba: 60.3 ms ± 339 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)   => 16.6 GiB/s
```

Numba is close to two time slower than Numpy. Note that using a loop is only slightly faster (3%) and using multiple threads with Numba clearly does not help (a bit slower in practice) since the RAM is mainly the limiting resource. Note that Numpy should be a bit faster in parallel since using 1 core is not enough to saturate the bandwidth of my RAM (but mostly).

I think `np.fill` can be sped up a lot by just using the memset JIT function internally.

However, while speeding up the `np.fill` call would be great, it would be even better to also speed up all user codes filling big buffers. However, it is probably better to expose a low-level JIT annotation to advanced users (and Numba developers) since choosing either non-temporal instructions are beneficial or not for a given user code is far from being easy for the JIT (since it often do not have the array size at compile time and often do not know if the arrays will be reused soon). Such an annotation has been added for example in OpenMP 5. I think there are plenty of application that could benefit from such a feature (like physic applications or big data analytics).

The version used for the tests is 0.53.1.
user: zephyr111
labels: performance: performance related issue
discussion: An issue requiring discussion
performance - run time: Performance issue occurring at run time.
issue_7533: state: open
title: Missed optimization on typed lists
body: Hello everyone,

Numba generate JIT calls for lists that are not optimized out by LLVM-Lite in practice. This include reference counting calls and especially function calls to check the size of the list in the following example. The fact that the functions related to the list are not inlined is a missing optimization (especially because of the `alwaysinline` and `readonly` JIT tags). This can have a relatively huge impact on the performance of codes using lists intensively. A detailled analysis (including the generated assembly code) can be found on: https://stackoverflow.com/questions/69738653/why-is-element-access-for-typed-lists-so-much-slower-than-for-arrays-with-numba.

```python
import numpy as np
import numba as nb

@nb.njit
def only_rand(N):
    s = 0
    for _ in range(10000):
        i = np.random.randint(N)
        j = np.random.randint(N)
        s += i + j
    return s

@nb.njit
def foo(pos, N):
    s = 0
    for _ in range(10000):
        i = np.random.randint(N)
        j = np.random.randint(N)
        
        dx = pos[i][0] - pos[j][0]
        dy = pos[i][1] - pos[j][1]
        dz = pos[i][2] - pos[j][2]
        s += dx + dy + dz
    return s

N = 100

Array = np.random.rand(N,3)
List = nb.typed.List(Array)

print('Random number generation:')
%timeit only_rand(N)
print('Numpy Array:')
%timeit foo(Array, N)
print('Typed List:')
%timeit foo(List, N)
```

Here is the result on my machine (i5-9600KF):

```
Random number generation:
109 µs ± 2.55 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
Numpy Array:
119 µs ± 566 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
Typed List:
739 µs ± 4.54 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

The version of Numba tested is 0.53.1 (on Windows with CPython 3.8.1).

user: zephyr111
labels: performance: performance related issue
discussion: An issue requiring discussion
performance - run time: Performance issue occurring at run time.
issue_7532: state: open
title: Move numba.experimental to numba-extras
body: **Edit by @gmarkall (2022-01-17):** This issue records that we need to move functionality from the `numba.experimental` package to the [numba-extras](https://github.com/numba/numba-extras) repo. Some discussion around related issues is also captured here.

---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
Hello all. I am opening this issue as a follow up to this: https://numba.discourse.group/t/numba-core-cpu-importing-stuff-from-numba-experimental/995

I am wondering if there is a better way to handle `install_registry` calls given. here:
https://github.com/numba/numba/blob/6c95d38d945bb5ee77e52662bed416e24a2770ef/numba/core/cpu.py#L86

This is particularly causing a problem to me when I am bundling my package with pyinstaller(while having numba as a dependency). "_box" shared library file in numba.experimental.jitclass particularly causing trouble but I do not depend on any experimental feature and I am manually dropping experimental submodule to save the day. This is how I am handling things currently but I want to discuss here to see if we can have cleaner solutions on both end. 

As far as I understood, experimental features meant to be for the users who want to use them and shouldn't affect the stable API experience in the rest of the codebase. Aside from the inconvenience I am facing with pyinstaller, it can be useful to not import anything experimental unless user asks for it IMHO.

I can appreciate that this can be hard to resolve and I am happy to contribute as much as I can.
user: AhmetCanSolak
labels: discussion: An issue requiring discussion
issue_7528: state: open
title: Implement array reshape for CUDA
body: The following:

```python
from numba import cuda
import numpy as np


@cuda.jit('void()')
def f():
    x = cuda.shared.array(0, dtype=np.int32)
    x.reshape(2, 2)
```

Gives:

```
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 2222, in complete
    driver.cuLinkComplete(self.handle, byref(cubin), byref(size))
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 303, in safe_cuda_api_call
    self._check_error(fname, retcode)
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 343, in _check_error
    raise CudaAPIError(retcode, msg)
numba.cuda.cudadrv.driver.CudaAPIError: [300] Call to cuLinkComplete results in CUDA_ERROR_INVALID_SOURCE

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/gabri94/repro.py", line 6, in <module>
    def f():
  File "/home/gmarkall/numbadev/numba/numba/cuda/decorators.py", line 109, in kernel_jit
    return Dispatcher(func, [func_or_sig], targetoptions=targetoptions)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 938, in __init__
    self.compile(sigs[0])
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 1117, in compile
    kernel.bind()
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 628, in bind
    self._codelibrary.get_cufunc()
  File "/home/gmarkall/numbadev/numba/numba/cuda/codegen.py", line 201, in get_cufunc
    cubin = self.get_cubin(cc=device.compute_capability)
  File "/home/gmarkall/numbadev/numba/numba/cuda/codegen.py", line 178, in get_cubin
    cubin_buf, size = linker.complete()
  File "/home/gmarkall/numbadev/numba/numba/cuda/cudadrv/driver.py", line 2224, in complete
    raise LinkerError("%s\n%s" % (e, self.error_log))
numba.cuda.cudadrv.driver.LinkerError: [300] Call to cuLinkComplete results in CUDA_ERROR_INVALID_SOURCE
error   : Undefined reference to 'numba_attempt_nocopy_reshape' in '<cudapy-ptx>'
```

Given that we got through typing and lowering and ended up with a linker error, it might not be too difficult to fix up the implementation for CUDA.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7527: state: open
title: Incorrect result of info locals and info args commands when debugging w/ GDB
body: - [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I used Numba(master) with the last commit on October 28(Merge pull request 7499) because #7177 and #7421  will be in the next release.

**Issues:**
1. The `info args` command shows an incorrect value if we change the function argument inside the function.

2. Numba generates a new local variable if we change the argument of the function.

Python code:
```
from numba import njit

@njit(debug=True)
def foo(a):
    a = a + 1
    return a

print(foo(1))
```

Annotations:
```
NUMBA_DUMP_ANNOTATION=1 gdb -q --args python njit_basic.py
def foo(a):

    # --- LINE 5 --- 
    # label 0
    #   a = arg(0, name=a)  :: int64
    #   $const4.1 = const(int, 1)  :: Literal[int](1)
    #   a.1 = a + $const4.1  :: int64
    #   del a
    #   del $const4.1

    a = a + 1

    # --- LINE 6 --- 
    #   $12return_value.4 = cast(value=a.1)  :: int64
    #   del a.1
    #   return $12return_value.4

    return a
```

Debug session:
```
NUMBA_OPT=0 NUMBA_EXTEND_VARIABLE_LIFETIMES=1 gdb -q --args python njit_basic.py
(gdb) break njit_basic.py:5
(gdb) run
. . .
Breakpoint 1, __main__::foo_241[abi:cwMlCA14ZNiCIlNHAS2FoIpipAeoNNArYJYmAA_3d_3d](long long) (a=1) at njit_basic.py:5
5           a = a + 1
(gdb) info args
a = 1
(gdb) info locals
a$1 = 0
(gdb) n
6           return a
(gdb) info args
a = 1
(gdb) info locals
a$1 = 2
```

Expected output:
```
5       a = a + 1
(gdb) info args
a = 1
(gdb) info locals
a = 1
(gdb) next
6       return a
(gdb) info args
a = 2
(gdb) info locals
a = 2
``` 
There should be just one variable named **a**, and at **line 6** its value should be **2**.
user: vlad-perevezentsev
labels: bug - DWARF: Bugs related to debugging support
issue_7523: state: open
title: Lowering error in parallel loop
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.


```python
import numpy as np
import numba
from numba import njit, prange
from numba.typed import List


@njit(nogil=True, parallel=True)
def iter_axis(arrays):
    # numba.set_num_threads(6)
    for i in range(100):
        temp = np.empty((100, 100))
        for j in prange(100):
            temp[j] = arrays[j][i]
        yield temp


data = List([np.random.randn(100, 100) for i in range(100)])
_ = list(iter_axis(data))
```
The above code iters through a list of arrays of the same shape. With `parallel=True`, it throws out this error:
```
OMP: Info #271: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
Traceback (most recent call last):
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/errors.py", line 776, in new_error_context
    yield
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 235, in lower_block
    self.lower_inst(inst)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 380, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 586, in lower_assign
    res = self.lower_yield(ty, value)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 596, in lower_yield
    y.lower_yield_suspend()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/generators.py", line 326, in lower_yield_suspend
    self.context.nrt.incref(self.builder, ty, val)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/runtime/context.py", line 221, in incref
    self._call_incref_decref(builder, typ, value, "NRT_incref")
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/runtime/context.py", line 206, in _call_incref_decref
    meminfos = self.get_meminfos(builder, typ, value)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/runtime/context.py", line 194, in get_meminfos
    field = getter(val)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/datamodel/models.py", line 709, in getter
    raise TypeError("expecting {0} but got {1}".format(*args))
TypeError: expecting {i8*, i8*, i64, i64, double*, [2 x i64], [2 x i64]} but got {i8*, i8*}
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/IPython/core/interactiveshell.py", line 3441, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-2-7043b82b7f8e>", line 18, in <module>
    _ = list(iter_axis(data))
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 501, in _compile_for_args
    raise e
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 434, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 979, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 141, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 155, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 168, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 686, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 492, in _compile_bytecode
    return self._compile_core()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/typed_passes.py", line 396, in run_pass
    lower.lower()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 144, in lower
    self.genlower.lower_next_func(self)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/generators.py", line 152, in lower_next_func
    entry_block_tail = lower.lower_function_body()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 221, in lower_function_body
    self.lower_block(block)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 235, in lower_block
    self.lower_inst(inst)
  File "/home/auderson/miniconda3/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/errors.py", line 786, in new_error_context
    raise newerr.with_traceback(tb)
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
expecting {i8*, i8*, i64, i64, double*, [2 x i64], [2 x i64]} but got {i8*, i8*}
File "<ipython-input-2-7043b82b7f8e>", line 14:
def iter_axis(arrays):
    <source elided>
            temp[j] = arrays[j][i]
        yield temp
        ^
During: lowering "$56yield_value.2 = yield temp" at <ipython-input-2-7043b82b7f8e> (14)
```
It can run with `parallel=False`.
My numba version is 0.54.1


user: auderson
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7509: state: open
title: astype not support datetime64 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ √] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ √] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.


```
    import numpy as np
    import numba as nb

    np_dt64_type = np.dtype('datetime64[s]')
    nb_dt64_type = nb.from_dtype(np_dt64_type)


    # @nb.njit()  # <<<---switch comment when testing
    def test_astype_datetime64():
        arr_unix_timestamp = np.array([1634917500, 1634922000, 1634925600], 'i8')
        arr_dt64 = arr_unix_timestamp.astype(np_dt64_type)  # for pure python without numba decorator <<<---switch comment when testing
        # arr_dt64 = arr_unix_timestamp.astype(nb_dt64_type)  # <<<---switch comment when testing ,given error msg:
        # for numba njit---raise error:astype(datetime64[s]) not supported on array(int64, 1d, C): cannot convert from int64 to datetime64[s]
        print(arr_dt64)
        pass


    test_astype_datetime64()
```



user: guzuomuse
issue_7505: state: open
title: cudasim breaks ufunc. missing is_cuda_array
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Reproducer:

```python
import numpy as np
from numba import guvectorize
from numba import cuda


@guvectorize(["(float64, float64[:])"], "()->()", target="cuda")
def foo(inp, out):
    out[0] = inp


a = np.arange(10, dtype=np.float64)
da = cuda.to_device(a)

out = foo(da)
print(out.copy_to_host())
```

Works in actual CUDA but fail in CUDASIM with:

```pytb
Traceback (most recent call last):
  File "/path/to/dev/numba/cudasim_ufunc.py", line 14, in <module>
    out = foo(da)
  File "/path/to/dev/numba/numba/np/ufunc/deviceufunc.py", line 644, in __call__
    callsteps = self._call_steps(self.engine.nin, self.engine.nout,
  File "/path/to/dev/numba/numba/np/ufunc/deviceufunc.py", line 757, in __init__
    self._is_device_array = [self.is_device_array(a) for a in self.args]
  File "/path/to/dev/numba/numba/np/ufunc/deviceufunc.py", line 757, in <listcomp>
    self._is_device_array = [self.is_device_array(a) for a in self.args]
  File "/path/to/dev/numba/numba/cuda/dispatcher.py", line 98, in is_device_array
    return cuda.is_cuda_array(obj)
AttributeError: module 'numba.cuda' has no attribute 'is_cuda_array'
```
user: sklam
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_7501: state: open
title: aot omitted argument 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [√ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ √] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```
@nb.njit()
@cc.export('test_omitted_argument', nb.void(nb.int64, nb.int64, nb.types.Omitted(None)))
def test_omitted_argument(a, b, c=None):
    print('a:', a, 'b:', b, 'c:', c)
    pass
```
after compiled. 

call this function raise error when given 2 arguments
`test_omitted_argument(1, 3)`
_**TypeError: test_omitted_argument expected 3 arguments, got 2**_

when fill the last argument what ever the value of c it allways print None

`test_omitted_argument(1, 3, 'wtf?')`

**_a: 1 b: 3 c: None_**
`test_omitted_argument(1, 3, 'holey!')`

**_a: 1 b: 3 c: None_**
user: guzuomuse
labels: AOT: ahead of time compilation issue
bug - miscompile: Bugs: miscompile
issue_7495: state: open
title: nb.prange returns int64 in sequential mode but uint64 in parallel mode
body: I believe this is undocumented behaviour.

```
import numba as nb


@nb.njit
def f1():
    for i in nb.prange(1):
        print(type(i))  # >>> int64


@nb.njit(parallel=True)
def f2():
    for i in nb.prange(1):
        print(type(i))  # >>> uint64


f1()
f2()
```

This caused a nasty bug in my own code that was hard to debug as the problem did not exist without `parallel=True`.

user: juliusbierk
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7494: state: open
title: CUDA Simulator IndexError when using @jit instead of @cuda.jit(device=True) functions inside of kernels
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Here is a MWE:
```python
"""Test IndexError Bug with CUDA Simulator."""
import os
import numpy as np

os.environ["NUMBA_ENABLE_CUDASIM"] = "1"

from numba import cuda, jit  # noqa

# @cuda.jit(device=True)  # works fine
@jit  # causes IndexError
def device(u):
    return u[0]


@cuda.jit("void(float32[:,:])")
def kernel(U):
    d = device(U[0])


def gen_kernel(U):
    stream = cuda.stream()
    cU = cuda.to_device(np.asarray(U, dtype=np.float32), stream=stream)
    kernel[(7, 7), (16, 16)](cU)


arr = np.random.rand(100, 50)
gen_kernel(arr)
```
Here is the stack trace:

> ```python
> Exception has occurred: IndexError       (note: full exception trace is shown but execution is paused at: kernel)
> only integers, slices (`:`), ellipsis (`...`), numpy.newaxis (`None`) and integer or boolean arrays are valid indices
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\cuda\simulator\cudadrv\devicearray.py", line 111, in __getitem__
>     ret = self._ary.__getitem__(idx)
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\cuda\simulator\cudadrv\devicearray.py", line 56, in __getattr__
>     return self.__wrap_if_fake(self._item.__getitem__(attrname))
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\core\typing\typeof.py", line 57, in typeof_impl
>     return getattr(val, "_numba_type_", None)
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\functools.py", line 877, in wrapper
>     return dispatch(args[0].__class__)(*args, **kw)
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\core\typing\typeof.py", line 31, in typeof
>     ty = typeof_impl(val, c)
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\core\dispatcher.py", line 747, in typeof_pyval
>     tp = typeof(val, Purpose.argument)
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\core\dispatcher.py", line 430, in _compile_for_args
>     argtypes.append(self.typeof_pyval(a))
>   File "C:\Users\sterg\Documents\GitHub\sparks-baird\numba-cuda-debug-scripts\scripts\IndexError\CUDASIM_IndexError_MWE.py", line 17, in kernel (Current frame)
>     d = device(U[0])
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\cuda\simulator\kernel.py", line 259, in target
>     self._f(*args)
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\threading.py", line 910, in run
>     self._target(*self._args, **self._kwargs)
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\site-packages\numba\cuda\simulator\kernel.py", line 175, in run
>     super(BlockThread, self).run()
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\threading.py", line 973, in _bootstrap_inner
>     self.run()
>   File "C:\Users\sterg\anaconda3\envs\mat_discover_test\Lib\threading.py", line 930, in _bootstrap
>     self._bootstrap_inner()
> ```

In the offending line of code:
```python
ret = self._ary.__getitem__(idx)
```
`self._ary` -->

> ```python
> array([0.17953342, 0.73834676, 0.802956  , 0.98596686, 0.0774815 ,
>        0.3511663 , 0.20920427, 0.06519137, 0.31637678, 0.1460998 ,
>        0.23470978, 0.77812034, 0.858728  , 0.00955263, 0.1732667 ,
>        0.45566723, 0.5210016 , 0.48739114, 0.6702702 , 0.27059707,
>        0.7008004 , 0.55280524, 0.89537793, 0.6885215 , 0.11849781,
>        0.9781991 , 0.7028517 , 0.6557897 , 0.46919635, 0.7266405 ,
>        0.538878  , 0.94278204, 0.7235465 , 0.8540385 , 0.20287855,
>        0.334921  , 0.01500198, 0.12158039, 0.9749173 , 0.2157117 ,
>        0.96577096, 0.37241337, 0.41551125, 0.63361496, 0.6186    ,
>        0.20904963, 0.06881329, 0.44958228, 0.307583  , 0.20893794],
>       dtype=float32)
> ```
> 

`type(self._ary)` -->

> ```python
> <class 'numpy.ndarray'>
> ```

`idx` -->

> ```python
> '_numba_type_'
> ```

So, naturally something like `np.array([0,1,2,3])['_numba_type_']` would give the error about indices.

`type(val._item)` (`dispatcher.py`: L747)-->
```python
<class 'numba.cuda.simulator.cudadrv.devicearray.FakeCUDAArray'>
```
Call stack:
<img src=https://user-images.githubusercontent.com/45469701/137849022-60ff530a-6856-4519-b5fd-9332c18e2274.png width=425>

I've been interested in having a set of device functions that can be used for either CUDA/Numba or njit/Numba, and in another issue @seibert mentioned that `@jit` automatically recompiles to `@cuda.jit(device=True)`. I dug around a bit into this error (boiled ~1000 lines of code down to get the MWE above), but I have very little clue on how this would be fixed directly.

For now, I'll probably just have one file with CUDA device functions and another with `@jit` or `@njit` functions, but the repeated code starts to get unwieldy, esp. trying to keep multiple files consistent with each other.

Here is a MWE plus a CUDATestCase if of interest:
```python
"""Test IndexError Bug with CUDA Simulator."""
import os
import numpy as np

os.environ["NUMBA_ENABLE_CUDASIM"] = "1"

from numba import cuda, jit  # noqa
from numba.cuda.testing import unittest, CUDATestCase  # noqa

np.random.seed(42)
U = np.random.rand(100, 50)


@cuda.jit(device=True)  # works fine
def cuda_device(u):
    return u[0]


@jit  # causes IndexError
def jit_device(u):
    return u[0]


@cuda.jit("void(float32[:,:], int32)")
def kernel(U, flag):
    if flag == 0:
        d = jit_device(U[0])
    elif flag == 1:
        d = cuda_device(U[0])


def gen_kernel(U, flag):
    stream = cuda.stream()
    cU = cuda.to_device(np.asarray(U, dtype=np.float32), stream=stream)
    kernel[(7, 7), (16, 16)](cU, flag)


class TestCUDASimJitIndexing(CUDATestCase):
    def test_jit_indexing(self):
        gen_kernel(U, 0)

    def test_cuda_indexing(self):
        gen_kernel(U, 1)


if __name__ == "__main__":
    unittest.main()
```

I think this is related to https://github.com/numba/numba/pull/7107.
user: sgbaird
labels: CUDA: CUDA related issue/PR
bug - documentation incorrect: documentation is incorrect or missing something important
issue_7492: state: open
title: partial type inference stores the wrong type when a PHI node is involved
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

While working on #7204, I notice the partial typemap algorithm stores wrong information when a PHI node is involved. Although the code below doesn't fully compile, it reproduces the error:

```python
from numba import njit
from numba.core.compiler import Compiler, DefaultPassBuilder
from numba.core.compiler_machinery import FunctionPass, register_pass
from numba.core.untyped_passes import ReconstructSSA

@register_pass(mutates_CFG=False, analysis_only=False)
class MyPass(FunctionPass):
    _name = "debug pass"

    def __init__(self):
        FunctionPass.__init__(self)

    def run_pass(self, state):
        from numba.core.compiler_machinery import PassManager
        from numba.core.typed_passes import PartialTypeInference
        pm = PassManager("subpipeline")
        pm.add_pass(PartialTypeInference, "performs partial type inference")
        pm.finalize()
        pm.run(state)

        print(state.typemap)
        state.func_ir.dump()
        return False

class TestCompiler(Compiler):

    def define_pipelines(self):
        pm = DefaultPassBuilder.define_nopython_pipeline(self.state)
        pm.add_pass_after(MyPass, ReconstructSSA)
        pm.finalize()
        return [pm]


@njit(pipeline_class=TestCompiler)
def foo(x):
    if x > 0:
        z = 123
    else:
        z = 'hello world'
    return z

foo(100)
```

Below is a dump of `typemap` and `func_ir` for `foo`. The return var `z` is named `z.2` in the IR and its type is inferred as `Literal[str](hello world)`, which is wrong! I'd say the correct type here would be an undefined type. As a note, in other tests I did, the type inferred seems to be the type of the last incoming variable in the PHI node.

```
state.typemap = {
    'arg.x': int64,
    'bool8': Function(<class 'bool'>),
    'x': int64,
    'z': Literal[int](123),
    'z.1': Literal[str](hello world),
    'z.2': Literal[str](hello world),
    '$22return_value.1': Literal[str](hello world),
    '$6compare_op.2': bool,
    '$8pred': bool,
    '$const4.1': Literal[int](0)
}

==========================
func_ir:

label 0:
    x = arg(0, name=x)                       ['x']
    $const4.1 = const(int, 0)                ['$const4.1']
    $6compare_op.2 = x > $const4.1           ['$6compare_op.2', '$const4.1', 'x']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, a.py:37),), kws=(), vararg=None, target=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 16                    ['$8pred']
label 10:
    z = const(int, 123)                      ['z']
    jump 20                                  []
label 16:
    z.1 = const(str, hello world)            ['z.1']
    jump 20                                  []
label 20:
    z.2 = phi(incoming_values=[Var(z.1, a.py:40), Var(z, a.py:38)], incoming_blocks=[16, 10]) ['z', 'z.1', 'z.2']
    $22return_value.1 = cast(value=z.2)      ['$22return_value.1', 'z.2']
    return $22return_value.1                 ['$22return_value.1']
```

Related discussion: https://github.com/numba/numba/pull/7244#discussion_r727020676
user: guilhermeleobas
labels: bug - miscompile: Bugs: miscompile
issue_7491: state: open
title: support for set and arrays of str type
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request
Hi,
I found codes like following is not runnable currently:
```python
@njit
def test_str_array():
    return np.array(['a'])

@njit
def test_str_set():
    return set(['a'])
```
Can we have supports for str array/set in the future?

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: auderson
labels: Effort - long: Long size effort needed
issue_7488: state: open
title: A case where type inference does not halt.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This from #3070 causes type inference to get stuck in a loop:
```python
import numpy as np
from numba import jit

@jit(nopython=True)
def median(arr):
    return np.median(arr)

x = np.random.random(100)
x.setflags(write=False)

median(x)
```
seems like it's going around in a loop with `_partition_factory.<locals>._partition` in it and some variable keeps swapping between a `Literal[int](0)` and an `int64`.
user: stuartarchibald
labels: bug - ice: Bugs: internal compiler error
issue_7487: state: open
title: Random shuffle error in structured array
body: Hello,
My runing enviroment is as below:
- python 3.7
- numba 0.54.1
- numpy 1.19.5
- windows 10 64bit os

Please consider the following code:

```
import numpy as np
from numba import njit

def vector_shuffle(v):
    """ without jit """
    print("before shuffle:", v)
    np.random.shuffle(v)
    print("after shuffle:", v)

@njit
def jit_vector_shuffle(v):
    """ with jit """
    print("before shuffle:", v)
    np.random.shuffle(v)
    print("after shuffle:", v)

A = np.random.default_rng(42).random((2,1))
# v is a structrued array, and its element like (i, j, value)
v = np.array([(i, j, A[i, j]) for i in range(A.shape[0]) for j in range(A.shape[1]) if not np.isnan(A[i, j])],dtype=[("i","i4"),("j","i4"),("x","f8")]) 
print("without jit")
vector_shuffle(v)
print("with jit")
jit_vector_shuffle(v)
```
It run as follows, however, using shuffle with jit make different element to be same:
```
withoout jit
before shuffle: [(0, 0, 0.77395605) (1, 0, 0.43887844)]
after shuffle: [(1, 0, 0.43887844) (0, 0, 0.77395605)]
with jit
before shuffle: [(1, 0, 0.43887844) (0, 0, 0.77395605)]
after shuffle: [(1, 0, 0.43887844) (1, 0, 0.43887844)] # I mean this row may reflect a bug.
```
user: dxzenghan
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7485: state: open
title: Validate values on assignment in `numba.config`
body: `numba.config` is used to store the compiler configuration options, the variables can be set by environment variables, a yaml file, or directly. In the majority of cases, nothing verifies that the values are valid in type or value, for example:
```pycon
In [1]: from numba import config

In [2]: config.GDB_BINARY=2j
```
the `GDB_BINARY` needs to be a file path to the gdb binary not a complex number. This error would not be caught until it's used, the effect here would be noticeable as `2j` isn't a binary, errors with other config values are not necessarily so obvious.

The task: write validators for types and values for each environment variable and assert that they are valid on point of assignment regardless of how they have been set (programmatic assignment/env var/yaml file).

Further thought... I think certain values should be immutable for the lifetime of the program. For example, the threading layer choice and maximum number of threads in use. Could this be incorporated?
user: stuartarchibald
labels: Effort - long: Long size effort needed
issue_7482: state: open
title: Failed in nopython mode pipeline len(none)
body: I'm on the latest build of numba:
```bash
$ conda list numba
# packages in environment at /path/to/my/env:
#
# Name                    Version                   Build  Channel
numba                     0.54.1           py37h2d894fd_0    conda-forge
```

Small reproducible example:
```python
$ cat bug.py 
import math
import numba

@numba.jit(nopython=True, fastmath=True)
def compute(smth, weights, default=0.0):

    if weights is None:
        return None

    if len(weights) == 0:
        return default

    idx = smth > 0
    weights = weights[idx]

    return default*weights

compute(smth=1, weights=None)
```

The problem:
```bash
$ python bug.py 
Traceback (most recent call last):
  File "bug.py", line 19, in <module>
    compute(smth=1, weights=None)
  File "/path/to/my/env/lib/python3.7/site-packages/numba/core/dispatcher.py", line 482, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/path/to/my/env/lib/python3.7/site-packages/numba/core/dispatcher.py", line 423, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function len>) found for signature:
 
 >>> len(none)
 
There are 16 candidate implementations:
  - Of which 16 did not match due to:
  Overload of function 'len': File: <numerous>: Line N/A.
    With argument(s): '(none)':
   No match.

During: resolving callee type: Function(<built-in function len>)
During: typing of call at bug.py (10)


File "bug.py", line 10:
def compute(smth, weights, default=0.0):
    <source elided>

    if len(weights) == 0:
    ^
```

This diff resolves the problem, but I didn't need it with `numba=0.43.1`
```diff
--- bug.py	2021-10-13 16:14:49.090431600 -0400
+++ /tmp/bug.py	2021-10-13 16:17:51.534177904 -0400
@@ -11,9 +11,9 @@
         return default
 
     idx = smth > 0
-    weights = weights[idx]
+    weight = weights[idx]
 
-    return default*weights
+    return default*weight
 
 
 compute(smth=1, weights=None)
 ```
user: nehaljwani
labels: SSA: Problem due to SSA (or lack of)
bug - failure to compile: Bugs: failed to compile valid code
issue_7480: state: open
title: Need common util to handle Optional types in comparator
body: Can we avoid writing the optional handling logic for every comparator?
For example: https://github.com/numba/numba/pull/7477/files#diff-822a3d4f266dfaf793bb8ffab446e5bcd3718853d6443f133cc04e3031689533R454-R474

Related: 

- https://github.com/numba/numba/issues/7474

Remaining problems:
- [int-optional `==` from 7474](https://github.com/numba/numba/issues/7474#issuecomment-940213269)

user: sklam
issue_7478: state: open
title: Incorrect silent conversion from float64 to float32 in cuda jitted function
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (version 0.54.1).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
When calling a cuda jitted kernel with the wrong input type, numba silently converts it and this conversion yields bugs. For example, this kernel correctly print all elements of an array (in any order):
```
import numpy as np
from numba import cuda

@cuda.jit()
def kernel(a):
    i = cuda.grid(1)
    if i < len(a):
        print(a[i])

a = np.array([1, 2, 3], dtype=np.float64)
kernel[1, 3](a)

```
Output:
```
1.000000
2.000000
3.000000
```
However, when demanding the input to be float32 but still passing a float64 array, something goes wrong during conversion (it appears to convert to zeros).
```
import numpy as np
from numba import cuda
from numba.types import void, float32

@cuda.jit(void(float32[:]))
def kernel(a):
    i = cuda.grid(1)
    if i < len(a):
        print(a[i])

a = np.array([1, 2, 3], dtype=np.float64)
kernel[1, 3](a)
```
Output:
```
0.000000
0.000000
0.000000
```
An even more unexpected result appears when explicitly demanding a contiguous array as input. Strange because non-contigous arrays aren't supported anyways in cuda.jitted functions:
```
import numpy as np
from numba import cuda
from numba.types import void, float32

@cuda.jit(void(float32[::1]))
def kernel(a):
    i = cuda.grid(1)
    if i < len(a):
        print(a[i])

a = np.array([1, 2, 3], dtype=np.float64)
kernel[1, 3](a)
```
Output:
```
0.000000
1.875000
0.000000
```
I think the intended behavior is (and should be, because there is a copy anyway) that numba correctly allocates a contiguous float32 array on the gpu and copies and converts the data from the float64 array. However, just throwing an error saying the input array should be float32 (just like for numba.jit) would be fine as well, currently no error or warning is given.
user: RendersJens
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_7470: state: open
title: Array-then-scalar chained indexing into an array fails
body: ## Reporting a bug

- [ x ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ x ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Indexing into an array using first an array then a scalar fails within an njit-ed function. I looked into this due to discussion by @polakowo in [this GItter discussion](https://gitter.im/numba/numba?at=615f8212fb3dcd4e881427bd) 

```python
import numba

@numba.njit
def array2_scalar_0(records):
    return records[np.array([0, 1])][0]

@numba.njit
def array2_scalar_m1(records):
    return records[np.array([0, 1])][-1]

@numba.njit
def array2_scalar_i(records, i):
    return records[np.array([0, 1])][i]

@numba.njit
def array2_array1(records):
    return records[np.array([0, 1])][np.array([0])]

@numba.njit
def array2_array2(records):
    return records[np.array([0, 1])][np.array([0, 1])]

dt = [('id', np.int64), ('col', np.int64)]
records = np.array([(1, 2), (3, 4)], dtype=dt)

print(f"{array2_scalar_0(records)=}")
print(f"{array2_scalar_m1(records)=}")
print(f"{array2_scalar_i(records, 0)=}")
print()
print(f"{array2_array1(records)=}")
print(f"{array2_array2(records)=}")
```
Output:
```
array2_scalar_0(records)=(-2387225703656530210, -2387225703656530210)
array2_scalar_m1(records)=(-2387225703656530210, -2387225703656530210)
array2_scalar_i(records, 0)=(-2387225703656530210, -2387225703656530210)

array2_array1(records)=array([(1, 2)], dtype=[('id', '<i8'), ('col', '<i8')])
array2_array2(records)=array([(1, 2), (3, 4)], dtype=[('id', '<i8'), ('col', '<i8')])
```

* All functions return values of the correct `dtype`
* _BUT_ the first three functions (where the final indexing operation uses a scalar, statically- or dynamically specified) return incorrect values; I expect the return values to be (1, 2),  (1, 2), and (3, 4), respectively
user: jllanfranchi
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7469: state: open
title: Selection of records already indexed with other array returns unexpected values
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```python
import numpy as np
from numba import njit

@njit
def f(records, idxs):
    return records[idxs][-1]

records = np.array([(1, 2), (3, 4)], dtype="i, i")

f(records, np.array([0, 1]))
(-555819298, -555819298)
```

Passing a slice works as well as replacing -1 with `np.array([-1])`.

user: polakowo
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7467: state: open
title: `np.nditer` won't broadcast 1D arrays
body: Here's a MWE run on 8d4559a83:
```python
import numpy as np

import numba


idx_val = np.array([0, 0])
y_val = np.array([1])
for i, j in np.nditer((idx_val, y_val)):
    print(i, j)
# 0 1
# 0 1


@numba.njit
def test():
    idx_val = np.array([0, 0])
    y_val = np.array([1])
    for i, j in np.nditer((idx_val, y_val)):
        print(i, j)


test()
# ValueError: nditer(): operands could not be broadcast together
```
user: brandonwillard
issue_7466: state: open
title: numpy.select won't compile if the `choicelist` contains non-vector numbers
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Numba version: 0.54.0

The code below explains the issue:

```python
import numba
import numpy as np

def test_select(x):
    return np.select([np.greater(x, 5), np.less_equal(x, 5)],
                     [x, 2], default=np.nan)

def test_select_vec(x):
    return np.select([np.greater(x, 5), np.less_equal(x, 5)],
                     [x, 2 * np.ones_like(x)], default=np.nan)

jit_test = numba.jit(test_select, nopython=True)

jit_test_vec = numba.jit(test_select_vec, nopython=True)
```

The only difference is the second element in the `choicelist` of `select`.

```python
aa = np.arange(10)

jit_test_vec(aa) 
```
works fine.

But 

```python
jit_test(aa)
```

generates an error:

```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
/var/folders/45/yt95k1qd4cj0wt64977wkb8w0000gn/T/ipykernel_58741/2430320953.py in <module>
----> 1 jit_test(aa)

~/mambaforge/envs/aa/lib/python3.9/site-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    418                 e.patch_message(msg)
    419 
--> 420             error_rewrite(e, 'typing')
    421         except errors.UnsupportedError as e:
    422             # Something unsupported is present in the user code, add help info

~/mambaforge/envs/aa/lib/python3.9/site-packages/numba/core/dispatcher.py in error_rewrite(e, issue_type)
    359                 raise e
    360             else:
--> 361                 raise e.with_traceback(None)
    362 
    363         argtypes = []

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function select at 0x11ab2c430>) found for signature:
 
 >>> select(list(array(bool, 1d, C))<iv=None>, LiteralList((array(int64, 1d, C), Literal[int](2))), default=float64)
 
There are 2 candidate implementations:
    - Of which 1 did not match due to:
    Overload in function 'np_select': File: numba/np/arraymath.py: Line 4153.
      With argument(s): '(list(array(bool, 1d, C))<iv=None>, Poison<LiteralList((array(int64, 1d, C), Literal[int](2)))>, default=float64)':
     Rejected as the implementation raised a specific error:
       TypingError: Poison type used in arguments; got Poison<LiteralList((array(int64, 1d, C), Literal[int](2)))>
  raised from /Users/hcui7/mambaforge/envs/aa/lib/python3.9/site-packages/numba/core/types/functions.py:238
    - Of which 1 did not match due to:
    Overload in function 'np_select': File: numba/np/arraymath.py: Line 4153.
      With argument(s): '(list(array(bool, 1d, C))<iv=None>, LiteralList((array(int64, 1d, C), Literal[int](2))), default=float64)':
     Rejected as the implementation raised a specific error:
       TypeError: choicelist must be a List or a Tuple
  raised from /Users/hcui7/mambaforge/envs/aa/lib/python3.9/site-packages/numba/np/arraymath.py:4172

During: resolving callee type: Function(<function select at 0x11ab2c430>)
During: typing of call at /var/folders/45/yt95k1qd4cj0wt64977wkb8w0000gn/T/ipykernel_58741/1839979159.py (5)


File "../../../../../../var/folders/45/yt95k1qd4cj0wt64977wkb8w0000gn/T/ipykernel_58741/1839979159.py", line 5:
<source missing, REPL/exec in use?>

```

Is the intended behavior, a not-yet supported feature, or a bug? Thanks in advance!
user: cuihantao
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7462: state: open
title: numba.pndindex accepts negative integers
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug/discussion point!

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using https://github.com/numba/numba/pull/7398
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Since https://github.com/numba/numba/pull/7398 adds support for integers as the arg to `pndindex`, it turns out that negative integers are also accepted both under `njit` and `njit(parallel=True)`, the NumPy equivalent `np.ndindex` raises a `ValueError` in such a case.

```python
@njit(parallel=True)
def test_impl(x, sz):
    for i in pndindex(sz):
        x[i] = 1
    return x

print(test_impl(np.zeros((10, 10)), -3))
```

user: stuartarchibald
labels: discussion: An issue requiring discussion
bug - incorrect behavior: Bugs: incorrect behavior
issue_7452: state: open
title: LLVM ERROR: Symbol not found: __sync_fetch_and_add_4 running tests on armv7l,armv8l (armel)
body: - [No ] I have tried using the latest released version of Numba  (0.52 tested, not 0.54).
- [Yes] I have included a self contained code sample to reproduce the problem.
`python3 -m numba.runtests --log -lv`


numba 0.52 is crashing on armv7l (armel). The error message is 
```
LLVM ERROR: Symbol not found: __sync_fetch_and_add_4
```
It 's the same error message as reported in #3052 , but that instance was supposed to have been fixed already.

This is on a debian unstable armel build with python3-numba 0.52.0-4, llvm-9 1:9.0.1-20.

A detailed test log reports
```
experimental_armel-dchroot$ python3 -m numba.runtests --log -lv
DEBUG:numba.core.byteflow:bytecode dump:
>          0	NOP(arg=None, lineno=38)
           2	LOAD_FAST(arg=0, lineno=38)
           4	LOAD_FAST(arg=1, lineno=38)
           6	BINARY_ADD(arg=None, lineno=38)
           8	RETURN_VALUE(arg=None, lineno=38)
DEBUG:numba.core.byteflow:pending: deque([State(pc_initial=0 nstack_initial=0)])
DEBUG:numba.core.byteflow:stack: []
DEBUG:numba.core.byteflow:dispatch pc=0, inst=NOP(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack []
DEBUG:numba.core.byteflow:dispatch pc=2, inst=LOAD_FAST(arg=0, lineno=38)
DEBUG:numba.core.byteflow:stack []
DEBUG:numba.core.byteflow:dispatch pc=4, inst=LOAD_FAST(arg=1, lineno=38)
DEBUG:numba.core.byteflow:stack ['$a2.0']
DEBUG:numba.core.byteflow:dispatch pc=6, inst=BINARY_ADD(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack ['$a2.0', '$b4.1']
DEBUG:numba.core.byteflow:dispatch pc=8, inst=RETURN_VALUE(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack ['$6binary_add.2']
DEBUG:numba.core.byteflow:end state. edges=[]
DEBUG:numba.core.byteflow:-------------------------Prune PHIs-------------------------
DEBUG:numba.core.byteflow:Used_phis: defaultdict(<class 'set'>, {State(pc_initial=0 nstack_initial=0): set()})
DEBUG:numba.core.byteflow:defmap: {}
DEBUG:numba.core.byteflow:phismap: defaultdict(<class 'set'>, {})
DEBUG:numba.core.byteflow:changing phismap: defaultdict(<class 'set'>, {})
DEBUG:numba.core.byteflow:keep phismap: {}
DEBUG:numba.core.byteflow:new_out: defaultdict(<class 'dict'>, {})
DEBUG:numba.core.byteflow:----------------------DONE Prune PHIs-----------------------
DEBUG:numba.core.byteflow:block_infos State(pc_initial=0 nstack_initial=0):
AdaptBlockInfo(insts=((0, {}), (2, {'res': '$a2.0'}), (4, {'res': '$b4.1'}), (6, {'lhs': '$a2.0', 'rhs': '$b4.1', 'res': '$6binary_add.2'}), (8, {'retval': '$6binary_add.2', 'castval': '$8return_value.3'})), outgoing_phis={}, blockstack=(), active_try_block=None, outgoing_edgepushed={})
DEBUG:numba.core.interpreter:label 0:
    a = arg(0, name=a)                       ['a']
    b = arg(1, name=b)                       ['b']
    $6binary_add.2 = a + b                   ['$6binary_add.2', 'a', 'b']
    $8return_value.3 = cast(value=$6binary_add.2) ['$6binary_add.2', '$8return_value.3']
    return $8return_value.3                  ['$8return_value.3']

DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:Running <numba.core.ssa._GatherDefsHandler object at 0xae297c70>
DEBUG:numba.core.ssa:on stmt: a = arg(0, name=a)
DEBUG:numba.core.ssa:on stmt: b = arg(1, name=b)
DEBUG:numba.core.ssa:on stmt: $6binary_add.2 = a + b
DEBUG:numba.core.ssa:on stmt: $8return_value.3 = cast(value=$6binary_add.2)
DEBUG:numba.core.ssa:on stmt: return $8return_value.3
DEBUG:numba.core.ssa:defs defaultdict(<class 'list'>,
            {'$6binary_add.2': [<numba.core.ir.Assign object at 0xae29d0a0>],
             '$8return_value.3': [<numba.core.ir.Assign object at 0xae29d118>],
             'a': [<numba.core.ir.Assign object at 0xae29d298>],
             'b': [<numba.core.ir.Assign object at 0xae29d6d0>]})
DEBUG:numba.core.ssa:SSA violators set()
LLVM ERROR: Symbol not found: __sync_fetch_and_add_4
```
So the error seems to be happening in numba.core.ssa.


user: drew-parsons
labels: ISA: ARM: Issue related to ARM ISA
issue_7446: state: open
title: Support arbitrary fixed-size integers
body: ## Feature request

LLVM supports arbitrary (but fixed) bit-size integers, for example you can create 1234-bit integer. Clang also supports arbitrary size integers, just do `using u1234 = unsigned _ExtInt(1234);` to create 1234-bit integer type `u1234`.

Would be great if Numba can use this LLVM/Clang feature of defining any-size integers, so that you can write something like `dtype = numba.ext_int(1234); value = dtype(789)` inside `@njit`-ed function.

I understand that Numpy doesn't support int128 or anything larger than int64, but still Numba can use any-sized int for non-Numpy arrays/structures, such as list/set/dict.

For example if I do `a = []; a.append(numba.ext_int(1234)(789))` then Numba can convert it to C++ version like `std::vector<_ExtInt(1234)> a; a.push_back(789);` (BTW, am I right that you're converting Python code to C++? or you're using C as backand?).

Same for dict `d = {numba.ext_int(123)(456) : numba.ext_int(789)(100)}` can be converted to `std::unordered_map<_ExtInt(123), _ExtInt(789)> d; d[456] = 100;`. Similarly for `set()`.

So to conclude - for Numpy you can disallow `_ExtInt()`, but for list/dict/set you can allow `_ExtInt()`.

Implementing such arbitrary-sized integer types as a consequence will result in a long-awaited feature `int128`, of course not within Numpy arrays but at least in list/dict/set.

Also maybe you can suggest some temporary work-around? I expect that Numba can have some low-level support for creating any type, for example through `@intrinsic` or IRBuilder or other ways of injecting LLVM IR assembly. Maybe Numba gurus can give ready-made example of implementing such feature as `_ExtInt()` support within current capabilities of Numba at least as `@intrinsic`?

user: polkovnikov
issue_7445: state: open
title: Compile Slowdown 0.50 -> 0.55, CUDA and NJIT
body: I have a useful but difficult to compile design pattern in which I set both a value and a sum value, passing in the sum target and the value name. I've demonstrated it below. This used to be pretty low cost, but every time we use it, it needs to compile again and really slows things down a good bit.

We're seeing considerable gradual slowdowns in compile times; this affects both CUDA and njit, but CUDA more. Any advice?

```
CUDA:
0.50 = 0.72
0.51 = 1.94
0.52 = 2.13
0.53 = 2.13
0.54 = 2.13
0.55.0.dev0+318.g6849adb57 = 2.31

NJIT:
0.50 = 0.52
0.51 = 0.57
0.52 = 0.54
0.53 = 0.57
0.54 = 0.67
0.55.0.dev0+318.g6849adb57 = 0.74
```
Sample Code:
```
import numpy as np
import numba as nb
from numba import cuda
import time

sample_typ = [('A', np.float64, 32),
              ('B', np.float64, 32),
              ('C', np.float64, 32),
              ('SUM', np.float64, 32)]

ledger_holder = [('LEFT_LEDGER', sample_typ),
                 ('RIGHT_LEDGER', sample_typ)]

sample_wrap = [('LEDGERS', ledger_holder),
               ('EXISTS', np.int8, 32)]

NP_SAMP = np.dtype(sample_wrap, align=True)
NB_SAMP = nb.from_dtype(NP_SAMP)


start = time.time()


@cuda.jit(device=True)
def set_ledger(ledgers, side, sumname, val_name, amt, lane):
    amt_bef = ledgers[side][val_name][lane]
    ledgers[side][val_name][lane] += (amt - amt_bef)
    if val_name != sumname:
        ledgers[side][sumname][lane] += (amt - amt_bef)


@cuda.jit(device=True)
def set_left_and_right_vals(s_vars, val_name, amt_left, amt_right, lane):
    set_ledger(s_vars['LEDGERS'], 'LEFT_LEDGER', 'SUM', val_name, amt_left, lane)
    set_ledger(s_vars['LEDGERS'], 'RIGHT_LEDGER', 'SUM', val_name, amt_right, lane)


@cuda.jit(nb.void(NB_SAMP[:], nb.float64))
def run_val(state, val):
    threadid = cuda.threadIdx.x + cuda.blockIdx.x * cuda.blockDim.x
    warp = threadid >> 5
    lane = warp & 31
    my_state = state[warp]
    set_left_and_right_vals(my_state, 'A', val+1, val, lane)

end = time.time()

print(end-start)
samp_dta = np.zeros(10, dtype=NP_SAMP)
run_val[5, 64](samp_dta, 11)
```

user: c200chromebook
labels: performance - compile time: Performance issue occurring at compile time.
issue_7434: state: open
title: TypeError when calling jitclass method with optional type member
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
numba version : 0.54.0
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
import numba
from numba.experimental import jitclass

spec=[("_a", numba.optional(numba.int32))]
@jitclass(spec=spec)
class A:
    def __init__(self, a):
        self._a = a

    def test(self, a):
        return self._a == a

a = A(None)
a.test(1)
```

This produces below errors.
```python
Traceback (most recent call last):
  File "/opt/test/test.py", line 14, in <module>
    a.test(1)
  File "/opt/python/py3.9/lib/python3.9/site-packages/numba/experimental/jitclass/boxing.py", line 59, in wrapper
    return method(*args, **kwargs)
TypeError: expected int32, got None
```
user: hn-sl
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7427: state: open
title: iter(Dict()) shows odd behavior + iter(List()) breaks
body: Using Numba 0.54.0
They following minimal reproduction shows unusual behavior when callig iter() on an instance of Dict(). It seems like iter() instances are replacing each other on instantiation.

```python
from numba import njit, i8
from numba.typed import Dict, List

@njit(cache=True)
def make_dicts(n=3,m=3):
    l = List()
    for j in range(1,n+1):
        d = Dict.empty(i8,i8)
        for i in range(1,m+1):
            d[i*j] = i+10
        l.append(d)
    return l

@njit(cache=True)
def test_iters(iterables):
    iters = [iter(iterable) for iterable in iterables]
    out = [next(it) for it in iters]
    print(":", out)

print(make_dicts()) # [{1: 11, 2: 12, 3: 13}, {2: 11, 4: 12, 6: 13}, {3: 11, 6: 12, 9: 13}]
test_iters.py_func(make_dicts()) # Python : [1,2,3]
test_iters(make_dicts()) # Numba : [3,6,9] <- wrong seems like reusing same iterator
```

And for good measure this also fails
```python
@njit(cache=True)
def make_lists(n=3,m=3):
    l = List()
    for j in range(1,n+1):
        l2 = List.empty_list(i8)
        for i in range(1,m+1):
            l2.append(i*j)
        l.append(l2)
    return l

print(make_lists()) # [[1, 2, 3], [2, 4, 6], [3, 6, 9]]

test_iters.py_func(make_lists()) # Python : [1,2,3]
test_iters(make_lists()) # Numba : Error

```
user: DannyWeitekamp
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7424: state: open
title: numba.jit strips away function type annotations, breaking mypy's analysis
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

**Context:** Python 3.9, macOS Big Sur 11.5, x86_64

`numba.jit` decorator strips away function's type annotations. This is problematic when using `mypy` for static analysis.

Example:

```python
import numba as nb
import numpy as np

@nb.jit(nb.float64(nb.float64, nb.float64), nopython=True, nogil=True, inline="always")
def my_function(a: float, b: float) -> float:
    return 0.5 if np.isnan(a) or np.isnan(b) else 1.0
```

Mypy's error:
```
/path/to/bug.py:4: error: Untyped decorator makes function "my_function" untyped
```

user: castarco
issue_7417: state: open
title: [Feature Request] Support for Python collections.deque
body: ---
## Feature request
[The official Python 3.9.7 documentation](https://docs.python.org/3/library/collections.html) shows a few containers and their descriptions

Being specific, `deque` is still a popular FIFO implementation option for its robustness and performance, as in this [StackOverflow thread](https://stackoverflow.com/a/49800160/4913389).

I searched Numba forums and issues for deque support, but I didn't find any clue about it. Are there intentions to support it? Are there technical difficulties in implementing it?

The only mention of an attempt at creating a FIFO with Numba JIT is from [this other SO question](https://stackoverflow.com/questions/62312844/what-is-a-good-approach-for-a-fast-fifo-queue), but it's definitely not robust and performant as `collections.deque`.

I first found about this problem when trying to learn how to use `@jitclass` with a very simple `delayed_adder` class which uses a `deque` as a FIFO to output addition results delayed by a few cycles (function calls).



user: danilo-bc
issue_7413: state: open
title: Default constructor of jitclass not useable from jitted code
body: ## Reporting a bug

During a discussion on Gitter I noticed that a jitclass instance cannot be created from default arguments inside jitted code.

:point_up: [Gitter September 17, 2021 3:17 PM](https://gitter.im/numba/numba?at=6144957b4c7be06b79c20b06)

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
from numba.experimental import jitclass
from numba import njit
from numba.types import int32


@jitclass
class A:
    a: int32

    def __init__(self, a=3):
        self.a = a

def a_explicit():
    return A(1)

def a_default():
    return A()


print("Explicit from python:", a_explicit())
print("Explicit from numba:", njit(a_explicit)())
print("Default from python:", a_default())
print("Default from numba:", njit(a_default)())

```

Output 
```
Explicit from python: <numba.experimental.jitclass.boxing.A object at 0x7f8e6d104ad0>
Explicit from numba: <numba.experimental.jitclass.boxing.A object at 0x7f8e6a080a10>
Default from python: <numba.experimental.jitclass.boxing.A object at 0x7f8e69eceb10>
Traceback (most recent call last):
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/errors.py", line 776, in new_error_context
    yield
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 235, in lower_block
    self.lower_inst(inst)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 380, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 556, in lower_assign
    return self.lower_expr(ty, value)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 1084, in lower_expr
    res = self.lower_call(resty, expr)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 815, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 1055, in _lower_call_normal
    res = impl(self.builder, argvals, self.loc)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/base.py", line 1194, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/base.py", line 1224, in wrapper
    return fn(*args, **kwargs)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/experimental/jitclass/base.py", line 581, in ctor_impl
    call(builder, realargs)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/base.py", line 1194, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/base.py", line 1224, in wrapper
    return fn(*args, **kwargs)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/imputils.py", line 195, in imp
    status, retval = context.call_conv.call_function(
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/callconv.py", line 570, in call_function
    args = list(arginfo.as_arguments(builder, args))
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/datamodel/packer.py", line 91, in as_arguments
    raise TypeError("invalid number of args: expected %d, got %d"
TypeError: invalid number of args: expected 2, got 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "jitclass_default_constructor.py", line 23, in <module>
    print("Default from numba:", njit(a_default)())
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 501, in _compile_for_args
    raise e
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 434, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 979, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 141, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 155, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 168, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 686, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 492, in _compile_bytecode
    return self._compile_core()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/typed_passes.py", line 396, in run_pass
    lower.lower()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 138, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 192, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 221, in lower_function_body
    self.lower_block(block)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 235, in lower_block
    self.lower_inst(inst)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/errors.py", line 786, in new_error_context
    raise newerr.with_traceback(tb)
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
invalid number of args: expected 2, got 1

File "jitclass_default_constructor.py", line 17:
def a_default():
    return A()
    ^

During: lowering "$4call_function.1 = call $2load_global.0(func=$2load_global.0, args=[], kws=(), vararg=None, target=None)" at jitclass_default_constructor.py (17)
```


`numba -s`
<details>
System info:
--------------------------------------------------------------------------------
__Time Stamp__
Report started (local time)                   : 2021-09-17 18:26:09.738632
UTC start time                                : 2021-09-17 16:26:09.738637
Running time (s)                              : 4.969007

__Hardware Information__
Machine                                       : x86_64
CPU Name                                      : skylake
CPU Count                                     : 8
Number of accessible CPUs                     : 8
List of accessible CPUs cores                 : 0 1 2 3 4 5 6 7
CFS Restrictions (CPUs worth of runtime)      : None

CPU Features                                  : 64bit adx aes avx avx2 bmi bmi2
                                                clflushopt cmov cx16 cx8 f16c fma
                                                fsgsbase fxsr invpcid lzcnt mmx
                                                movbe pclmul popcnt prfchw rdrnd
                                                rdseed rtm sahf sgx sse sse2 sse3
                                                sse4.1 sse4.2 ssse3 xsave xsavec
                                                xsaveopt xsaves

Memory Total (MB)                             : 15885
Memory Available (MB)                         : 7265

__OS Information__
Platform Name                                 : Linux-5.10.61-1-MANJARO-x86_64-with-glibc2.10
Platform Release                              : 5.10.61-1-MANJARO
OS Name                                       : Linux
OS Version                                    : #1 SMP PREEMPT Thu Aug 26 20:36:54 UTC 2021
OS Specific Version                           : ?
Libc Version                                  : glibc 2.33

__Python Information__
Python Compiler                               : GCC 7.3.0
Python Implementation                         : CPython
Python Version                                : 3.8.5
Python Locale                                 : en_GB.UTF-8

__Numba Toolchain Versions__
Numba Version                                 : 0.54.0
llvmlite Version                              : 0.37.0

__LLVM Information__
LLVM Version                                  : 11.1.0

__CUDA Information__
CUDA Device Initialized                       : False
CUDA Driver Version                           : ?
CUDA Runtime Version                          : ?
CUDA Detect Output:
None
CUDA Libraries Test Output:
None

__SVML Information__
SVML State, config.USING_SVML                 : True
SVML Library Loaded                           : True
llvmlite Using SVML Patched LLVM              : True
SVML Operational                              : True

__Threading Layer Information__
TBB Threading Layer Available                 : True
+-->TBB imported successfully.
OpenMP Threading Layer Available              : True
+-->Vendor: GNU
Workqueue Threading Layer Available           : True
+-->Workqueue imported successfully.

__Numba Environment Variable Information__
None found.

__Conda Information__
Conda Build                                   : 3.17.1
Conda Env                                     : 4.9.2
Conda Platform                                : linux-64
Conda Python Version                          : 3.7.4.final.0
Conda Root Writable                           : True

__Installed Packages__
_anaconda_depends         2020.07                  py38_0  
_libgcc_mutex             0.1                        main  
_openmp_mutex             4.5                       1_gnu  
alabaster                 0.7.12                     py_0  
anaconda                  custom                   py38_1  
anaconda-client           1.7.2                    py38_0  
anaconda-project          0.8.4                      py_0  
appdirs                   1.4.4              pyh9f0ad1d_0    conda-forge
argh                      0.26.2                   py38_0  
argon2-cffi               20.1.0           py38h7b6447c_1  
asn1crypto                1.4.0                      py_0  
asteval                   0.9.23             pyhd8ed1ab_0    conda-forge
astroid                   2.4.2                    py38_0  
astropy                   4.0.2            py38h7b6447c_0  
async_generator           1.10                       py_0  
atomicwrites              1.4.0                      py_0  
attrs                     20.3.0             pyhd3eb1b0_0  
autopep8                  1.5.4                      py_0  
babel                     2.8.1              pyhd3eb1b0_0  
backcall                  0.2.0                      py_0  
backports                 1.0                        py_2  
backports.shutil_get_terminal_size 1.0.0                    py38_2  
beautifulsoup4            4.9.3              pyhb0f4dca_0  
bibtexparser              1.2.0                    pypi_0    pypi
bitarray                  1.6.1            py38h27cfd23_0  
bkcharts                  0.2                      py38_0  
blas                      1.0                         mkl  
bleach                    3.2.1                      py_0  
blosc                     1.20.1               hd408876_0  
bokeh                     2.2.3                    py38_0  
boto                      2.49.0                   py38_0  
bottleneck                1.3.2            py38heb32a55_1  
brotli-python             1.0.9            py38heb0550a_2  
brotlipy                  0.7.0           py38h7b6447c_1000  
build                     0.6.0.post1              pypi_0    pypi
bzip2                     1.0.8                h7b6447c_0  
ca-certificates           2021.7.5             h06a4308_1  
cairo                     1.14.12              h8948797_3  
certifi                   2021.5.30        py38h06a4308_0  
cffi                      1.14.3           py38he30daa8_0  
cfgv                      3.2.0                      py_0    conda-forge
chardet                   3.0.4                 py38_1003  
click                     7.1.2                      py_0  
cloudpickle               1.6.0                      py_0  
clyent                    1.2.2                    py38_1  
colorama                  0.4.4                      py_0  
contextlib2               0.6.0.post1                py_0  
cryptography              3.1.1            py38h1ba5d50_0  
curl                      7.71.1               hbc83047_1  
cycler                    0.10.0                   py38_0  
cython                    0.29.21          py38he6710b0_0  
cytoolz                   0.11.0           py38h7b6447c_0  
dash                      1.19.0             pyhd3eb1b0_0  
dash-core-components      1.3.1                      py_0  
dash-html-components      1.0.1                      py_0  
dash-renderer             1.1.2                      py_0  
dash-table                4.4.1                      py_0  
dask                      2.30.0                     py_0  
dask-core                 2.30.0                     py_0  
dbus                      1.13.18              hb2f20db_0  
decorator                 4.4.2                      py_0  
defusedxml                0.6.0                      py_0  
diff-match-patch          20200713                   py_0  
distlib                   0.3.1              pyh9f0ad1d_0    conda-forge
distributed               2.30.1           py38h06a4308_0  
docutils                  0.16                     py38_1  
ebisim                    0.2.0                     dev_0    <develop>
editdistance              0.5.3            py38h950e882_2    conda-forge
entrypoints               0.3                      py38_0  
et_xmlfile                1.0.1                   py_1001  
expat                     2.2.10               he6710b0_2  
fastcache                 1.1.0            py38h7b6447c_0  
filelock                  3.0.12                     py_0  
flake8                    3.8.4                      py_0  
flask                     1.1.2                      py_0  
flask-compress            1.8.0              pyhd3eb1b0_0  
fontconfig                2.13.0               h9420a91_0  
freetype                  2.10.4               h5ab3b9f_0  
fribidi                   1.0.10               h7b6447c_0  
fsspec                    0.8.3                      py_0  
future                    0.18.2                   py38_1  
get_terminal_size         1.0.0                haa9412d_0  
gevent                    20.9.0           py38h7b6447c_0  
glib                      2.66.1               h92f7085_0  
glob2                     0.7                        py_0  
gmp                       6.1.2                h6c8ec71_1  
gmpy2                     2.0.8            py38hd5f6e3b_3  
graphite2                 1.3.14               h23475e2_0  
greenlet                  0.4.17           py38h7b6447c_0  
gst-plugins-base          1.14.0               hbbd80ab_1  
gstreamer                 1.14.0               hb31296c_0  
h5py                      2.10.0           py38h7918eee_0  
harfbuzz                  2.4.0                hca77d97_1  
hdf5                      1.10.4               hb1b8bf9_0  
heapdict                  1.0.1                      py_0  
html5lib                  1.1                        py_0  
icc_rt                    2020.2                intel_254    numba
icu                       58.2                 he6710b0_3  
identify                  1.5.13             pyh44b312d_0    conda-forge
idna                      2.10                       py_0  
imageio                   2.9.0                      py_0  
imagesize                 1.2.0                      py_0  
importlib-metadata        2.0.0                      py_1  
importlib_metadata        2.0.0                         1  
iniconfig                 1.1.1                      py_0  
intel-openmp              2021.3.0          h06a4308_3350  
intervaltree              3.1.0                      py_0  
ipykernel                 5.3.4            py38h5ca1d4c_0  
ipython                   7.19.0           py38hb070fc8_0  
ipython_genutils          0.2.0                    py38_0  
ipywidgets                7.5.1                      py_1  
isort                     5.6.4                      py_0  
itsdangerous              1.1.0                      py_0  
jbig                      2.1                  hdba287a_0  
jdcal                     1.4.1                      py_0  
jedi                      0.17.1                   py38_0  
jeepney                   0.5.0              pyhd3eb1b0_0  
jinja2                    2.11.2                     py_0  
joblib                    1.0.0              pyhd3eb1b0_0  
jpeg                      9b                   h024ee3a_2  
json5                     0.9.5                      py_0  
jsonschema                3.2.0                      py_2  
jupyter                   1.0.0                    py38_7  
jupyter_client            6.1.7                      py_0  
jupyter_console           6.2.0                      py_0  
jupyter_core              4.6.3                    py38_0  
jupyterlab                2.2.6                      py_0  
jupyterlab_pygments       0.1.2                      py_0  
jupyterlab_server         1.2.0                      py_0  
keyring                   21.4.0                   py38_1  
kiwisolver                1.3.0            py38h2531618_0  
krb5                      1.18.2               h173b8e3_0  
lazy-object-proxy         1.4.3            py38h7b6447c_0  
lcms2                     2.11                 h396b838_0  
ld_impl_linux-64          2.33.1               h53a641e_7  
libarchive                3.4.2                h62408e4_0  
libcurl                   7.71.1               h20c2e04_1  
libedit                   3.1.20191231         h14c3975_1  
libffi                    3.3                  he6710b0_2  
libgcc-ng                 9.3.0               h9cbead1_17  
libgfortran-ng            7.3.0                hdf63c60_0  
libgomp                   9.3.0               h9cbead1_17  
liblief                   0.10.1               he6710b0_0  
libllvm10                 10.0.1               hbcb73fb_5  
libllvm9                  9.0.1                h4a3c616_1  
libpng                    1.6.37               hbc83047_0  
libsodium                 1.0.18               h7b6447c_0  
libspatialindex           1.9.3                he6710b0_0  
libssh2                   1.9.0                h1ba5d50_1  
libstdcxx-ng              9.3.0               hd4cf53a_17  
libtiff                   4.1.0                h2733197_1  
libtool                   2.4.6             h7b6447c_1005  
libuuid                   1.0.3                h1bed415_2  
libxcb                    1.14                 h7b6447c_0  
libxml2                   2.9.10               hb55368b_3  
libxslt                   1.1.34               hc22bd24_0  
llvmlite                  0.37.0           py38he1b5a44_0    numba
lmfit                     1.0.2              pyhd8ed1ab_0    conda-forge
locket                    0.2.0                    py38_1  
lxml                      4.6.1            py38hefd8a0e_0  
lz4-c                     1.9.2                heb0550a_3  
lzo                       2.10                 h7b6447c_2  
markupsafe                1.1.1            py38h7b6447c_0  
matplotlib                3.3.2                         0  
matplotlib-base           3.3.2            py38h817c723_0  
mccabe                    0.6.1                    py38_1  
mistune                   0.8.4           py38h7b6447c_1000  
mkl                       2021.3.0           h06a4308_520  
mkl-service               2.4.0            py38h7f8727e_0  
mkl_fft                   1.3.0            py38h42c9631_2  
mkl_random                1.2.2            py38h51133e4_0  
mock                      4.0.2                      py_0  
more-itertools            8.6.0              pyhd3eb1b0_0  
mpc                       1.1.0                h10f8cd9_1  
mpfr                      4.0.2                hb69a4c5_1  
mpmath                    1.1.0                    py38_0  
msgpack-python            1.0.0            py38hfd86e86_1  
multipledispatch          0.6.0                    py38_0  
mypy                      0.800              pyhd3eb1b0_0  
mypy_extensions           0.4.3                    py38_0  
nbclient                  0.5.1                      py_0  
nbconvert                 6.0.7                    py38_0  
nbformat                  5.0.8                      py_0  
ncurses                   6.2                  he6710b0_1  
nest-asyncio              1.4.2              pyhd3eb1b0_0  
networkx                  2.5                        py_0  
nltk                      3.5                        py_0  
nodeenv                   1.5.0              pyh9f0ad1d_0    conda-forge
nose                      1.3.7                    py38_2  
notebook                  6.1.4                    py38_0  
numba                     0.54.0          np1.11py3.8hc13618b_g5888895d3_0    numba
numexpr                   2.7.3            py38h22e1b3c_1  
numpy                     1.20.3           py38hf144106_0  
numpy-base                1.20.3           py38h74d4b33_0  
numpydoc                  1.1.0              pyhd3eb1b0_1  
olefile                   0.46                       py_0  
openpyxl                  3.0.5                      py_0  
openssl                   1.1.1k               h27cfd23_0  
packaging                 20.4                       py_0  
pandas                    1.1.3            py38he6710b0_0  
pandoc                    2.11                 hb0f4dca_0  
pandocfilters             1.4.3            py38h06a4308_1  
pango                     1.45.3               hd140c19_0  
parso                     0.7.0                      py_0  
partd                     1.1.0                      py_0  
patchelf                  0.12                 he6710b0_0  
path                      15.0.0                   py38_0  
path.py                   12.5.0                        0  
pathlib2                  2.3.5                    py38_0  
pathtools                 0.1.2                      py_1  
patsy                     0.5.1                    py38_0  
pbr                       5.5.1                      py_0  
pcre                      8.44                 he6710b0_0  
pep517                    0.11.0                   pypi_0    pypi
pep8                      1.7.1                    py38_0  
pexpect                   4.8.0                    py38_0  
pickleshare               0.7.5                 py38_1000  
pillow                    8.0.1            py38he98fc37_0  
pip                       20.2.4           py38h06a4308_0  
pixman                    0.40.0               h7b6447c_0  
pkginfo                   1.6.1            py38h06a4308_0  
plotly                    4.14.3             pyhd3eb1b0_0  
pluggy                    0.13.1                   py38_0  
ply                       3.11                     py38_0  
pre-commit                2.10.1           py38h578d9bd_0    conda-forge
prometheus_client         0.8.0                      py_0  
prompt-toolkit            3.0.8                      py_0  
prompt_toolkit            3.0.8                         0  
psutil                    5.7.2            py38h7b6447c_0  
ptyprocess                0.6.0                    py38_0  
py                        1.9.0                      py_0  
py-lief                   0.10.1           py38h403a769_0  
pycodestyle               2.6.0                      py_0  
pycosat                   0.6.3            py38h7b6447c_1  
pycparser                 2.20                       py_2  
pycurl                    7.43.0.6         py38h1ba5d50_0  
pydocstyle                5.1.1                      py_0  
pyflakes                  2.2.0                      py_0  
pygments                  2.7.2              pyhd3eb1b0_0  
pylint                    2.6.0                    py38_0  
pyodbc                    4.0.30           py38he6710b0_0  
pyopenssl                 19.1.0                     py_1  
pyparsing                 2.4.7                      py_0  
pyqt                      5.9.2            py38h05f1152_4  
pyrsistent                0.17.3           py38h7b6447c_0  
pysocks                   1.7.1                    py38_0  
pytables                  3.6.1            py38h9fd0a39_0  
pytest                    6.1.1                    py38_0  
python                    3.8.5                h7579374_1  
python-dateutil           2.8.1                      py_0  
python-jsonrpc-server     0.4.0                      py_0  
python-language-server    0.35.1                     py_0  
python-libarchive-c       2.9                        py_0  
python_abi                3.8                      1_cp38    conda-forge
pytz                      2020.1                     py_0  
pywavelets                1.1.1            py38h7b6447c_2  
pyxdg                     0.27               pyhd3eb1b0_0  
pyyaml                    5.3.1            py38h7b6447c_1  
pyzmq                     19.0.2           py38he6710b0_1  
qdarkstyle                2.8.1                      py_0  
qt                        5.9.7                h5867ecd_1  
qtawesome                 1.0.1                      py_0  
qtconsole                 4.7.7                      py_0  
qtpy                      1.9.0                      py_0  
readline                  8.0                  h7b6447c_0  
regex                     2020.10.15       py38h7b6447c_0  
requests                  2.24.0                     py_0  
retrying                  1.3.3                      py_2  
ripgrep                   12.1.1                        0  
rope                      0.18.0                     py_0  
rtree                     0.9.4                    py38_1  
ruamel_yaml               0.15.87          py38h7b6447c_1  
scikit-image              0.17.2           py38hdf5156a_0  
scikit-learn              0.23.2           py38h0573a6f_0  
scipy                     1.6.2            py38had2a1c9_1  
seaborn                   0.11.0                     py_0  
secretstorage             3.1.2                    py38_0  
send2trash                1.5.0                    py38_0  
setuptools                50.3.1           py38h06a4308_1  
simplegeneric             0.8.1                    py38_2  
singledispatch            3.4.0.3                 py_1001  
sip                       4.19.13          py38he6710b0_0  
six                       1.15.0           py38h06a4308_0  
snappy                    1.1.8                he6710b0_0  
snowballstemmer           2.0.0                      py_0  
sortedcollections         1.2.1                      py_0  
sortedcontainers          2.2.2                      py_0  
soupsieve                 2.0.1                      py_0  
sphinx                    3.2.1                      py_0  
sphinx-autodoc-typehints  1.11.1                   pypi_0    pypi
sphinx_rtd_theme          0.5.1              pyhd3deb0d_0    conda-forge
sphinxcontrib             1.0                      py38_1  
sphinxcontrib-apidoc      0.3.0                      py_1    conda-forge
sphinxcontrib-applehelp   1.0.2                      py_0  
sphinxcontrib-devhelp     1.0.2                      py_0  
sphinxcontrib-htmlhelp    1.0.3                      py_0  
sphinxcontrib-jsmath      1.0.1                      py_0  
sphinxcontrib-qthelp      1.0.3                      py_0  
sphinxcontrib-serializinghtml 1.1.4                      py_0  
sphinxcontrib-websupport  1.2.4                      py_0  
spyder                    4.1.5                    py38_0  
spyder-kernels            1.9.4                    py38_0  
sqlalchemy                1.3.20           py38h7b6447c_0  
sqlite                    3.33.0               h62c20be_0  
statsmodels               0.12.0           py38h7b6447c_0  
sympy                     1.6.2            py38h06a4308_1  
tbb                       2021.2.0             hff7bd54_0  
tblib                     1.7.0                      py_0  
tct                       0.1.0                     dev_0    <develop>
terminado                 0.9.1                    py38_0  
testpath                  0.4.4                      py_0  
threadpoolctl             2.1.0              pyh5ca1d4c_0  
tifffile                  2020.10.1        py38hdd07704_2  
tk                        8.6.10               hbc83047_0  
toml                      0.10.1                     py_0  
tomli                     1.2.1                    pypi_0    pypi
toolz                     0.11.1                     py_0  
tornado                   6.0.4            py38h7b6447c_1  
tqdm                      4.50.2                     py_0  
traitlets                 5.0.5                      py_0  
typed-ast                 1.4.2            py38h27cfd23_1  
typing_extensions         3.7.4.3                    py_0  
ujson                     4.0.1            py38he6710b0_0  
uncertainties             3.1.5              pyhd8ed1ab_0    conda-forge
unicodecsv                0.14.1                   py38_0  
unixodbc                  2.3.9                h7b6447c_0  
urllib3                   1.25.11                    py_0  
virtualenv                20.4.2           py38h578d9bd_0    conda-forge
watchdog                  0.10.3                   py38_0  
wcwidth                   0.2.5                      py_0  
webencodings              0.5.1                    py38_1  
werkzeug                  1.0.1                      py_0  
wheel                     0.35.1                     py_0  
widgetsnbextension        3.5.1                    py38_0  
wrapt                     1.11.2           py38h7b6447c_0  
wurlitzer                 2.0.1                    py38_0  
xlrd                      1.2.0                      py_0  
xlsxwriter                1.3.7                      py_0  
xlwt                      1.3.0                    py38_0  
xz                        5.2.5                h7b6447c_0  
yaml                      0.2.5                h7b6447c_0  
yapf                      0.30.0                     py_0  
zeromq                    4.3.3                he6710b0_3  
zict                      2.0.0                      py_0  
zipp                      3.4.0              pyhd3eb1b0_0  
zlib                      1.2.11               h7b6447c_3  
zope                      1.0                      py38_1  
zope.event                4.5.0                    py38_0  
zope.interface            5.1.2            py38h7b6447c_0  
zstd                      1.4.5                h9ceee32_0  

No errors reported.


__Warning log__
Warning (cuda): CUDA driver library cannot be found or no CUDA enabled devices are present.
Exception class: <class 'numba.cuda.cudadrv.error.CudaSupportError'>
Warning (no file): /sys/fs/cgroup/cpuacct/cpu.cfs_quota_us
Warning (no file): /sys/fs/cgroup/cpuacct/cpu.cfs_period_us
--------------------------------------------------------------------------------
If requested, please copy and paste the information between
the dashed (----) lines, or from a given specific section as
appropriate.

=============================================================
IMPORTANT: Please ensure that you are happy with sharing the
contents of the information present, any information that you
wish to keep private you should remove before sharing.
=============================================================


</details>
user: HPLegion
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7412: state: open
title: Strange bug when combining jitclass, type annotation and TypedList
body: 
## Reporting a bug

During a discussion on Gitter I ran into some strange issues when using a certain combination of jitclasses with Typed List fields and using them in a type annotation.

:point_up: [Gitter September 17, 2021 3:17 PM](https://gitter.im/numba/numba?at=6144957b4c7be06b79c20b06)

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

In the following code sample I marked the crucial line in `B`. If the type annotation is present the code still prints `"STILL RUNNING"` and then crashes. If I remove the annotation `: A` the code terminates successfully. Unfortunately I could not simplify the sample further.

```python
from numba.experimental import jitclass
from numba import typed
from numba.types import ListType, int32


@jitclass
class A:
    a: int32

    def __init__(self, a):
        self.a = a


@jitclass
class B:
    a_inst: A.class_type.instance_type

    def __init__(self, a_inst: A): # If I remove the 'a_inst: A' type annotation the code runs without issues
        self.a_inst = a_inst


@jitclass
class C:
    b_list: ListType(B.class_type.instance_type)

    def __init__(self, b_list: list):
        self.b_list = b_list

a = A(0)
b = B(a)
print("STILL RUNNING")
c = C(typed.List([b]))
print("FINISHED")
```
Output (long traceback)
<details>
STILL RUNNING
Traceback (most recent call last):
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/pythonapi.py", line 1375, in serialize_object
    gv = self.module.__serialized[obj]
KeyError: ListType[instance.jitclass.B#7ffb5c1f4ca0<a_inst:instance.jitclass.A#7ffb716aa490<a:int32>>]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "jitclass_type_annotation.py", line 32, in <module>
    c = C(typed.List([b]))
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/experimental/jitclass/base.py", line 124, in __call__
    return cls._ctor(*bind.args[1:], **bind.kwargs)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 501, in _compile_for_args
    raise e
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 434, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 979, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 141, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 155, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 168, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 686, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 492, in _compile_bytecode
    return self._compile_core()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/typed_passes.py", line 398, in run_pass
    lower.create_cpython_wrapper(flags.release_gil)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 247, in create_cpython_wrapper
    self.context.create_cpython_wrapper(self.library, self.fndesc,
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/cpu.py", line 183, in create_cpython_wrapper
    builder.build()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/callwrapper.py", line 123, in build
    self.build_wrapper(api, builder, closure, args, kws)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/callwrapper.py", line 188, in build_wrapper
    obj = api.from_native_return(retty, retval, env_manager)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/pythonapi.py", line 1402, in from_native_return
    out = self.from_native_value(typ, val, env_manager)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/pythonapi.py", line 1416, in from_native_value
    return impl(typ, val, c)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/experimental/jitclass/boxing.py", line 139, in _box_class_instance
    box_subclassed = _specialize_box(typ)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/experimental/jitclass/boxing.py", line 122, in _specialize_box
    fast_fget = fget.compile((typ,))
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 979, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 141, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 155, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 168, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 686, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 492, in _compile_bytecode
    return self._compile_core()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/typed_passes.py", line 398, in run_pass
    lower.create_cpython_wrapper(flags.release_gil)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/lowering.py", line 247, in create_cpython_wrapper
    self.context.create_cpython_wrapper(self.library, self.fndesc,
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/cpu.py", line 183, in create_cpython_wrapper
    builder.build()
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/callwrapper.py", line 123, in build
    self.build_wrapper(api, builder, closure, args, kws)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/callwrapper.py", line 188, in build_wrapper
    obj = api.from_native_return(retty, retval, env_manager)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/pythonapi.py", line 1402, in from_native_return
    out = self.from_native_value(typ, val, env_manager)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/pythonapi.py", line 1416, in from_native_value
    return impl(typ, val, c)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/typed/typedlist.py", line 477, in box_lsttype
    lsttype_obj = c.pyapi.unserialize(c.pyapi.serialize_object(typ))
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/pythonapi.py", line 1377, in serialize_object
    struct = self.serialize_uncached(obj)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/pythonapi.py", line 1348, in serialize_uncached
    data = serialize.dumps(obj)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/serialize.py", line 57, in dumps
    p.dump(obj)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/cloudpickle/cloudpickle_fast.py", line 563, in dump
    return Pickler.dump(self, obj)
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/serialize.py", line 185, in reducer_override
    _no_pickle(obj)  # noreturn
  File "/home/hpahl/anaconda3/envs/py38/lib/python3.8/site-packages/numba/core/serialize.py", line 164, in _no_pickle
    raise pickle.PicklingError(f"Pickling of {type(obj)} is unsupported")
_pickle.PicklingError: Failed in nopython mode pipeline (step: native lowering)
Failed in nopython mode pipeline (step: native lowering)
Pickling of <class 'numba.experimental.jitclass.base.JitClassType'> is unsupported

</details>

`numba -s`
<details>
System info:
--------------------------------------------------------------------------------
__Time Stamp__
Report started (local time)                   : 2021-09-17 18:26:09.738632
UTC start time                                : 2021-09-17 16:26:09.738637
Running time (s)                              : 4.969007

__Hardware Information__
Machine                                       : x86_64
CPU Name                                      : skylake
CPU Count                                     : 8
Number of accessible CPUs                     : 8
List of accessible CPUs cores                 : 0 1 2 3 4 5 6 7
CFS Restrictions (CPUs worth of runtime)      : None

CPU Features                                  : 64bit adx aes avx avx2 bmi bmi2
                                                clflushopt cmov cx16 cx8 f16c fma
                                                fsgsbase fxsr invpcid lzcnt mmx
                                                movbe pclmul popcnt prfchw rdrnd
                                                rdseed rtm sahf sgx sse sse2 sse3
                                                sse4.1 sse4.2 ssse3 xsave xsavec
                                                xsaveopt xsaves

Memory Total (MB)                             : 15885
Memory Available (MB)                         : 7265

__OS Information__
Platform Name                                 : Linux-5.10.61-1-MANJARO-x86_64-with-glibc2.10
Platform Release                              : 5.10.61-1-MANJARO
OS Name                                       : Linux
OS Version                                    : #1 SMP PREEMPT Thu Aug 26 20:36:54 UTC 2021
OS Specific Version                           : ?
Libc Version                                  : glibc 2.33

__Python Information__
Python Compiler                               : GCC 7.3.0
Python Implementation                         : CPython
Python Version                                : 3.8.5
Python Locale                                 : en_GB.UTF-8

__Numba Toolchain Versions__
Numba Version                                 : 0.54.0
llvmlite Version                              : 0.37.0

__LLVM Information__
LLVM Version                                  : 11.1.0

__CUDA Information__
CUDA Device Initialized                       : False
CUDA Driver Version                           : ?
CUDA Runtime Version                          : ?
CUDA Detect Output:
None
CUDA Libraries Test Output:
None

__SVML Information__
SVML State, config.USING_SVML                 : True
SVML Library Loaded                           : True
llvmlite Using SVML Patched LLVM              : True
SVML Operational                              : True

__Threading Layer Information__
TBB Threading Layer Available                 : True
+-->TBB imported successfully.
OpenMP Threading Layer Available              : True
+-->Vendor: GNU
Workqueue Threading Layer Available           : True
+-->Workqueue imported successfully.

__Numba Environment Variable Information__
None found.

__Conda Information__
Conda Build                                   : 3.17.1
Conda Env                                     : 4.9.2
Conda Platform                                : linux-64
Conda Python Version                          : 3.7.4.final.0
Conda Root Writable                           : True

__Installed Packages__
_anaconda_depends         2020.07                  py38_0  
_libgcc_mutex             0.1                        main  
_openmp_mutex             4.5                       1_gnu  
alabaster                 0.7.12                     py_0  
anaconda                  custom                   py38_1  
anaconda-client           1.7.2                    py38_0  
anaconda-project          0.8.4                      py_0  
appdirs                   1.4.4              pyh9f0ad1d_0    conda-forge
argh                      0.26.2                   py38_0  
argon2-cffi               20.1.0           py38h7b6447c_1  
asn1crypto                1.4.0                      py_0  
asteval                   0.9.23             pyhd8ed1ab_0    conda-forge
astroid                   2.4.2                    py38_0  
astropy                   4.0.2            py38h7b6447c_0  
async_generator           1.10                       py_0  
atomicwrites              1.4.0                      py_0  
attrs                     20.3.0             pyhd3eb1b0_0  
autopep8                  1.5.4                      py_0  
babel                     2.8.1              pyhd3eb1b0_0  
backcall                  0.2.0                      py_0  
backports                 1.0                        py_2  
backports.shutil_get_terminal_size 1.0.0                    py38_2  
beautifulsoup4            4.9.3              pyhb0f4dca_0  
bibtexparser              1.2.0                    pypi_0    pypi
bitarray                  1.6.1            py38h27cfd23_0  
bkcharts                  0.2                      py38_0  
blas                      1.0                         mkl  
bleach                    3.2.1                      py_0  
blosc                     1.20.1               hd408876_0  
bokeh                     2.2.3                    py38_0  
boto                      2.49.0                   py38_0  
bottleneck                1.3.2            py38heb32a55_1  
brotli-python             1.0.9            py38heb0550a_2  
brotlipy                  0.7.0           py38h7b6447c_1000  
build                     0.6.0.post1              pypi_0    pypi
bzip2                     1.0.8                h7b6447c_0  
ca-certificates           2021.7.5             h06a4308_1  
cairo                     1.14.12              h8948797_3  
certifi                   2021.5.30        py38h06a4308_0  
cffi                      1.14.3           py38he30daa8_0  
cfgv                      3.2.0                      py_0    conda-forge
chardet                   3.0.4                 py38_1003  
click                     7.1.2                      py_0  
cloudpickle               1.6.0                      py_0  
clyent                    1.2.2                    py38_1  
colorama                  0.4.4                      py_0  
contextlib2               0.6.0.post1                py_0  
cryptography              3.1.1            py38h1ba5d50_0  
curl                      7.71.1               hbc83047_1  
cycler                    0.10.0                   py38_0  
cython                    0.29.21          py38he6710b0_0  
cytoolz                   0.11.0           py38h7b6447c_0  
dash                      1.19.0             pyhd3eb1b0_0  
dash-core-components      1.3.1                      py_0  
dash-html-components      1.0.1                      py_0  
dash-renderer             1.1.2                      py_0  
dash-table                4.4.1                      py_0  
dask                      2.30.0                     py_0  
dask-core                 2.30.0                     py_0  
dbus                      1.13.18              hb2f20db_0  
decorator                 4.4.2                      py_0  
defusedxml                0.6.0                      py_0  
diff-match-patch          20200713                   py_0  
distlib                   0.3.1              pyh9f0ad1d_0    conda-forge
distributed               2.30.1           py38h06a4308_0  
docutils                  0.16                     py38_1  
ebisim                    0.2.0                     dev_0    <develop>
editdistance              0.5.3            py38h950e882_2    conda-forge
entrypoints               0.3                      py38_0  
et_xmlfile                1.0.1                   py_1001  
expat                     2.2.10               he6710b0_2  
fastcache                 1.1.0            py38h7b6447c_0  
filelock                  3.0.12                     py_0  
flake8                    3.8.4                      py_0  
flask                     1.1.2                      py_0  
flask-compress            1.8.0              pyhd3eb1b0_0  
fontconfig                2.13.0               h9420a91_0  
freetype                  2.10.4               h5ab3b9f_0  
fribidi                   1.0.10               h7b6447c_0  
fsspec                    0.8.3                      py_0  
future                    0.18.2                   py38_1  
get_terminal_size         1.0.0                haa9412d_0  
gevent                    20.9.0           py38h7b6447c_0  
glib                      2.66.1               h92f7085_0  
glob2                     0.7                        py_0  
gmp                       6.1.2                h6c8ec71_1  
gmpy2                     2.0.8            py38hd5f6e3b_3  
graphite2                 1.3.14               h23475e2_0  
greenlet                  0.4.17           py38h7b6447c_0  
gst-plugins-base          1.14.0               hbbd80ab_1  
gstreamer                 1.14.0               hb31296c_0  
h5py                      2.10.0           py38h7918eee_0  
harfbuzz                  2.4.0                hca77d97_1  
hdf5                      1.10.4               hb1b8bf9_0  
heapdict                  1.0.1                      py_0  
html5lib                  1.1                        py_0  
icc_rt                    2020.2                intel_254    numba
icu                       58.2                 he6710b0_3  
identify                  1.5.13             pyh44b312d_0    conda-forge
idna                      2.10                       py_0  
imageio                   2.9.0                      py_0  
imagesize                 1.2.0                      py_0  
importlib-metadata        2.0.0                      py_1  
importlib_metadata        2.0.0                         1  
iniconfig                 1.1.1                      py_0  
intel-openmp              2021.3.0          h06a4308_3350  
intervaltree              3.1.0                      py_0  
ipykernel                 5.3.4            py38h5ca1d4c_0  
ipython                   7.19.0           py38hb070fc8_0  
ipython_genutils          0.2.0                    py38_0  
ipywidgets                7.5.1                      py_1  
isort                     5.6.4                      py_0  
itsdangerous              1.1.0                      py_0  
jbig                      2.1                  hdba287a_0  
jdcal                     1.4.1                      py_0  
jedi                      0.17.1                   py38_0  
jeepney                   0.5.0              pyhd3eb1b0_0  
jinja2                    2.11.2                     py_0  
joblib                    1.0.0              pyhd3eb1b0_0  
jpeg                      9b                   h024ee3a_2  
json5                     0.9.5                      py_0  
jsonschema                3.2.0                      py_2  
jupyter                   1.0.0                    py38_7  
jupyter_client            6.1.7                      py_0  
jupyter_console           6.2.0                      py_0  
jupyter_core              4.6.3                    py38_0  
jupyterlab                2.2.6                      py_0  
jupyterlab_pygments       0.1.2                      py_0  
jupyterlab_server         1.2.0                      py_0  
keyring                   21.4.0                   py38_1  
kiwisolver                1.3.0            py38h2531618_0  
krb5                      1.18.2               h173b8e3_0  
lazy-object-proxy         1.4.3            py38h7b6447c_0  
lcms2                     2.11                 h396b838_0  
ld_impl_linux-64          2.33.1               h53a641e_7  
libarchive                3.4.2                h62408e4_0  
libcurl                   7.71.1               h20c2e04_1  
libedit                   3.1.20191231         h14c3975_1  
libffi                    3.3                  he6710b0_2  
libgcc-ng                 9.3.0               h9cbead1_17  
libgfortran-ng            7.3.0                hdf63c60_0  
libgomp                   9.3.0               h9cbead1_17  
liblief                   0.10.1               he6710b0_0  
libllvm10                 10.0.1               hbcb73fb_5  
libllvm9                  9.0.1                h4a3c616_1  
libpng                    1.6.37               hbc83047_0  
libsodium                 1.0.18               h7b6447c_0  
libspatialindex           1.9.3                he6710b0_0  
libssh2                   1.9.0                h1ba5d50_1  
libstdcxx-ng              9.3.0               hd4cf53a_17  
libtiff                   4.1.0                h2733197_1  
libtool                   2.4.6             h7b6447c_1005  
libuuid                   1.0.3                h1bed415_2  
libxcb                    1.14                 h7b6447c_0  
libxml2                   2.9.10               hb55368b_3  
libxslt                   1.1.34               hc22bd24_0  
llvmlite                  0.37.0           py38he1b5a44_0    numba
lmfit                     1.0.2              pyhd8ed1ab_0    conda-forge
locket                    0.2.0                    py38_1  
lxml                      4.6.1            py38hefd8a0e_0  
lz4-c                     1.9.2                heb0550a_3  
lzo                       2.10                 h7b6447c_2  
markupsafe                1.1.1            py38h7b6447c_0  
matplotlib                3.3.2                         0  
matplotlib-base           3.3.2            py38h817c723_0  
mccabe                    0.6.1                    py38_1  
mistune                   0.8.4           py38h7b6447c_1000  
mkl                       2021.3.0           h06a4308_520  
mkl-service               2.4.0            py38h7f8727e_0  
mkl_fft                   1.3.0            py38h42c9631_2  
mkl_random                1.2.2            py38h51133e4_0  
mock                      4.0.2                      py_0  
more-itertools            8.6.0              pyhd3eb1b0_0  
mpc                       1.1.0                h10f8cd9_1  
mpfr                      4.0.2                hb69a4c5_1  
mpmath                    1.1.0                    py38_0  
msgpack-python            1.0.0            py38hfd86e86_1  
multipledispatch          0.6.0                    py38_0  
mypy                      0.800              pyhd3eb1b0_0  
mypy_extensions           0.4.3                    py38_0  
nbclient                  0.5.1                      py_0  
nbconvert                 6.0.7                    py38_0  
nbformat                  5.0.8                      py_0  
ncurses                   6.2                  he6710b0_1  
nest-asyncio              1.4.2              pyhd3eb1b0_0  
networkx                  2.5                        py_0  
nltk                      3.5                        py_0  
nodeenv                   1.5.0              pyh9f0ad1d_0    conda-forge
nose                      1.3.7                    py38_2  
notebook                  6.1.4                    py38_0  
numba                     0.54.0          np1.11py3.8hc13618b_g5888895d3_0    numba
numexpr                   2.7.3            py38h22e1b3c_1  
numpy                     1.20.3           py38hf144106_0  
numpy-base                1.20.3           py38h74d4b33_0  
numpydoc                  1.1.0              pyhd3eb1b0_1  
olefile                   0.46                       py_0  
openpyxl                  3.0.5                      py_0  
openssl                   1.1.1k               h27cfd23_0  
packaging                 20.4                       py_0  
pandas                    1.1.3            py38he6710b0_0  
pandoc                    2.11                 hb0f4dca_0  
pandocfilters             1.4.3            py38h06a4308_1  
pango                     1.45.3               hd140c19_0  
parso                     0.7.0                      py_0  
partd                     1.1.0                      py_0  
patchelf                  0.12                 he6710b0_0  
path                      15.0.0                   py38_0  
path.py                   12.5.0                        0  
pathlib2                  2.3.5                    py38_0  
pathtools                 0.1.2                      py_1  
patsy                     0.5.1                    py38_0  
pbr                       5.5.1                      py_0  
pcre                      8.44                 he6710b0_0  
pep517                    0.11.0                   pypi_0    pypi
pep8                      1.7.1                    py38_0  
pexpect                   4.8.0                    py38_0  
pickleshare               0.7.5                 py38_1000  
pillow                    8.0.1            py38he98fc37_0  
pip                       20.2.4           py38h06a4308_0  
pixman                    0.40.0               h7b6447c_0  
pkginfo                   1.6.1            py38h06a4308_0  
plotly                    4.14.3             pyhd3eb1b0_0  
pluggy                    0.13.1                   py38_0  
ply                       3.11                     py38_0  
pre-commit                2.10.1           py38h578d9bd_0    conda-forge
prometheus_client         0.8.0                      py_0  
prompt-toolkit            3.0.8                      py_0  
prompt_toolkit            3.0.8                         0  
psutil                    5.7.2            py38h7b6447c_0  
ptyprocess                0.6.0                    py38_0  
py                        1.9.0                      py_0  
py-lief                   0.10.1           py38h403a769_0  
pycodestyle               2.6.0                      py_0  
pycosat                   0.6.3            py38h7b6447c_1  
pycparser                 2.20                       py_2  
pycurl                    7.43.0.6         py38h1ba5d50_0  
pydocstyle                5.1.1                      py_0  
pyflakes                  2.2.0                      py_0  
pygments                  2.7.2              pyhd3eb1b0_0  
pylint                    2.6.0                    py38_0  
pyodbc                    4.0.30           py38he6710b0_0  
pyopenssl                 19.1.0                     py_1  
pyparsing                 2.4.7                      py_0  
pyqt                      5.9.2            py38h05f1152_4  
pyrsistent                0.17.3           py38h7b6447c_0  
pysocks                   1.7.1                    py38_0  
pytables                  3.6.1            py38h9fd0a39_0  
pytest                    6.1.1                    py38_0  
python                    3.8.5                h7579374_1  
python-dateutil           2.8.1                      py_0  
python-jsonrpc-server     0.4.0                      py_0  
python-language-server    0.35.1                     py_0  
python-libarchive-c       2.9                        py_0  
python_abi                3.8                      1_cp38    conda-forge
pytz                      2020.1                     py_0  
pywavelets                1.1.1            py38h7b6447c_2  
pyxdg                     0.27               pyhd3eb1b0_0  
pyyaml                    5.3.1            py38h7b6447c_1  
pyzmq                     19.0.2           py38he6710b0_1  
qdarkstyle                2.8.1                      py_0  
qt                        5.9.7                h5867ecd_1  
qtawesome                 1.0.1                      py_0  
qtconsole                 4.7.7                      py_0  
qtpy                      1.9.0                      py_0  
readline                  8.0                  h7b6447c_0  
regex                     2020.10.15       py38h7b6447c_0  
requests                  2.24.0                     py_0  
retrying                  1.3.3                      py_2  
ripgrep                   12.1.1                        0  
rope                      0.18.0                     py_0  
rtree                     0.9.4                    py38_1  
ruamel_yaml               0.15.87          py38h7b6447c_1  
scikit-image              0.17.2           py38hdf5156a_0  
scikit-learn              0.23.2           py38h0573a6f_0  
scipy                     1.6.2            py38had2a1c9_1  
seaborn                   0.11.0                     py_0  
secretstorage             3.1.2                    py38_0  
send2trash                1.5.0                    py38_0  
setuptools                50.3.1           py38h06a4308_1  
simplegeneric             0.8.1                    py38_2  
singledispatch            3.4.0.3                 py_1001  
sip                       4.19.13          py38he6710b0_0  
six                       1.15.0           py38h06a4308_0  
snappy                    1.1.8                he6710b0_0  
snowballstemmer           2.0.0                      py_0  
sortedcollections         1.2.1                      py_0  
sortedcontainers          2.2.2                      py_0  
soupsieve                 2.0.1                      py_0  
sphinx                    3.2.1                      py_0  
sphinx-autodoc-typehints  1.11.1                   pypi_0    pypi
sphinx_rtd_theme          0.5.1              pyhd3deb0d_0    conda-forge
sphinxcontrib             1.0                      py38_1  
sphinxcontrib-apidoc      0.3.0                      py_1    conda-forge
sphinxcontrib-applehelp   1.0.2                      py_0  
sphinxcontrib-devhelp     1.0.2                      py_0  
sphinxcontrib-htmlhelp    1.0.3                      py_0  
sphinxcontrib-jsmath      1.0.1                      py_0  
sphinxcontrib-qthelp      1.0.3                      py_0  
sphinxcontrib-serializinghtml 1.1.4                      py_0  
sphinxcontrib-websupport  1.2.4                      py_0  
spyder                    4.1.5                    py38_0  
spyder-kernels            1.9.4                    py38_0  
sqlalchemy                1.3.20           py38h7b6447c_0  
sqlite                    3.33.0               h62c20be_0  
statsmodels               0.12.0           py38h7b6447c_0  
sympy                     1.6.2            py38h06a4308_1  
tbb                       2021.2.0             hff7bd54_0  
tblib                     1.7.0                      py_0  
tct                       0.1.0                     dev_0    <develop>
terminado                 0.9.1                    py38_0  
testpath                  0.4.4                      py_0  
threadpoolctl             2.1.0              pyh5ca1d4c_0  
tifffile                  2020.10.1        py38hdd07704_2  
tk                        8.6.10               hbc83047_0  
toml                      0.10.1                     py_0  
tomli                     1.2.1                    pypi_0    pypi
toolz                     0.11.1                     py_0  
tornado                   6.0.4            py38h7b6447c_1  
tqdm                      4.50.2                     py_0  
traitlets                 5.0.5                      py_0  
typed-ast                 1.4.2            py38h27cfd23_1  
typing_extensions         3.7.4.3                    py_0  
ujson                     4.0.1            py38he6710b0_0  
uncertainties             3.1.5              pyhd8ed1ab_0    conda-forge
unicodecsv                0.14.1                   py38_0  
unixodbc                  2.3.9                h7b6447c_0  
urllib3                   1.25.11                    py_0  
virtualenv                20.4.2           py38h578d9bd_0    conda-forge
watchdog                  0.10.3                   py38_0  
wcwidth                   0.2.5                      py_0  
webencodings              0.5.1                    py38_1  
werkzeug                  1.0.1                      py_0  
wheel                     0.35.1                     py_0  
widgetsnbextension        3.5.1                    py38_0  
wrapt                     1.11.2           py38h7b6447c_0  
wurlitzer                 2.0.1                    py38_0  
xlrd                      1.2.0                      py_0  
xlsxwriter                1.3.7                      py_0  
xlwt                      1.3.0                    py38_0  
xz                        5.2.5                h7b6447c_0  
yaml                      0.2.5                h7b6447c_0  
yapf                      0.30.0                     py_0  
zeromq                    4.3.3                he6710b0_3  
zict                      2.0.0                      py_0  
zipp                      3.4.0              pyhd3eb1b0_0  
zlib                      1.2.11               h7b6447c_3  
zope                      1.0                      py38_1  
zope.event                4.5.0                    py38_0  
zope.interface            5.1.2            py38h7b6447c_0  
zstd                      1.4.5                h9ceee32_0  

No errors reported.


__Warning log__
Warning (cuda): CUDA driver library cannot be found or no CUDA enabled devices are present.
Exception class: <class 'numba.cuda.cudadrv.error.CudaSupportError'>
Warning (no file): /sys/fs/cgroup/cpuacct/cpu.cfs_quota_us
Warning (no file): /sys/fs/cgroup/cpuacct/cpu.cfs_period_us
--------------------------------------------------------------------------------
If requested, please copy and paste the information between
the dashed (----) lines, or from a given specific section as
appropriate.

=============================================================
IMPORTANT: Please ensure that you are happy with sharing the
contents of the information present, any information that you
wish to keep private you should remove before sharing.
=============================================================


</details>
user: HPLegion
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7410: state: open
title: Support for Record type in jitclass
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request
It would be great if it was possible to have Record type member in jitclass.

```python
import numpy as np
import numba
from numba.experimental import jitclass
my_type = np.dtype([("age", np.int32), ("height", np.int32)])
a = np.zeros(1, dtype=my_type)[0]

spec=[
    ("_a", numba.typeof(a))
]
@jitclass(spec=spec)
class A:
    def __init__(self, a):
        self._a = a
        
A(a) # This throw below exception
```
```python
Traceback (most recent call last):
  File "/opt/test/test.py", line 15, in <module>
    A(a) # This throw below exception
  File "/opt/python/py3.9/lib/python3.9/site-packages/numba/experimental/jitclass/base.py", line 124, in __call__
    return cls._ctor(*bind.args[1:], **bind.kwargs)
  File "/opt/python/py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py", line 482, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/opt/python/py3.9/lib/python3.9/site-packages/numba/core/dispatcher.py", line 423, in error_rewrite
    raise e.with_traceback(None)

numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x7f42aef1b280>.
Failed in nopython mode pipeline (step: native lowering)
use load_from_data_pointer() instead

File "test.py", line 13:
    def __init__(self, a):
        self._a = a
        ^

During: lowering "(self)._a = a" at /opt/test/test.py (13)
During: resolving callee type: jitclass.A#7f4306358400<_a:Record(age[type=int32;offset=0],height[type=int32;offset=4];8;False)>
During: typing of call at <string> (3)

Enable logging at debug level for details.

File "<string>", line 3:
<source missing, REPL/exec in use?>
```
This was tested on latest numba version (0.54.0)

user: hn-sl
issue_7401: state: open
title: FEAT: add np.moveaxis support
body: Closes: https://github.com/numba/numba/issues/7369

This PR adds support for `np.moveaxis`. I've modified the following files:

- added `moveaxis` implementation to `arraymath.py`
- added an entry in the documentation of `numpysupported.rst`
- added unit tests for `moveaxis` matching the unit tests currently used by numpy (with exception of one variant that passed in a `range` iterable into `moveaxis`, which numba doesn't support)

I did not check for full coverage of the unit tests; hence, some paths that lead to raising the correct exception may not be covered.
user: FirefoxMetzger
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_7400: state: open
title: Allow `pyobject` annotation on outgoing variables in `objmode`
body: ## Feature request

Would be great if outgoing variable type of objmode could be also pyobject. Imagine following toy example:

```
import numba, gmpy2

@numba.njit(cache = True)
def f():
    with numba.objmode(r = 'pyobject', n = 'pyobject'):
        n, r = gmpy2.mpz(97), gmpy2.mpz(1)
    m = 3
    for i in range(1, 15):
        with numba.objmode(r = 'pyobject'):
            r = (r * i) % n
        m += i
        for j in range(m):
            with numba.objmode(r = 'pyobject'):
                r = (r + j) % n
    with numba.objmode(res = 'i8'):
        res = int(r)
    return res

print(f())
```

Here [gmpy2](https://gmpy2.readthedocs.io/en/latest/) is big integer artithmetics library for Python (based on well known GMP).

The main idea in this code is to allow `pyobject` outgoing types for objmode with main exception that all pyobject outgoing variables can be used later in njit-ed function only within other with-objmode blocks.

So pyobject variable can leave with-objmode block but can't be used outside, it is just passively stored for later use. It can be used later only within other with-objmode blocks.

This way you will allow usage and mix of any Python object within njit-ed function.

BTW, code like above will allow to have long integer arithmetics within njit-ed function, feature which is missing currently from Numba (there is no long integers in Numba).

Currently it is allowed to use pyobject within just single with-objmode block, it is allowed for this object to leave this block only as being converted to some numba native type, this conversion back and forth will be a huge overhead for code above.

My suggestion is to allow pyobject to leave with block, but only to store it passively in memory, without allowing to use (read) or modify it unless you enter another with-objmode block.

Also you can see that very last with block converts gmpy2's long int back to regular integer with native Numba's type i8 which will allow to return result from function.

user: polkovnikov
issue_7399: state: open
title: Allow getting pointer (address) to Numba's int/float variables
body: Feature Request

-----------

For example I have some cffi or ctypes function that has a pointer `int64_t *` as one of its argument. I need to call this function passing pointer (address) of single-value `np.int64` variable. I found a way how to get and pass a pointer to any element of Numpy array, using `.ctypes` property. But didn't find any way of passing a pointer to int64 (`np.int64` or `numba.int64`). Example code:

```
import numba, numpy as np

@numba.njit(cache = True)
def f():
    a = np.zeros((10,), dtype = np.int64)
    aptr = a[1:3].ctypes
    b = np.int64
    bptr = b.ctypes
    c = numba.int64
    cptr = c.ctypes
    
f()
```

In code above Numpy array has `.ctypes` property, returning `aptr` that can be easily passed as cffi function's `int64_t *` argument. But single-value variables `b` and `c` don't have same `.ctypes` property to get pointer of type `int64_t *` (compile error `Unknown attribute 'ctypes' of type class(int64)`). Neither I found any special function to get such pointer.

Maybe such address-getting special function exists somewhere in Numba's library, can anyone point me please to such function? Otherwise it would be nice to implement such.

As a workaround I was creating single-element Numpy array, copying int value into this element and then passing `arr[0:1].ctypes` to function. After function completes I copy value from array back to single-value variable. But this workaround is very inefficient especially if to create array every time.

user: polkovnikov
issue_7389: state: open
title: lowering error in certain conditions
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi,
I wonder if this is a bug:
```python

@njit(nogil=True)
def inner_open(arr, kind='mergesort'):
    if kind == 'mergesort':
        return np.argsort(arr, kind='mergesort')
    if kind == 'quicksort':
        return np.argsort(arr, kind='quicksort')


@njit(nogil=True)
def inner_closed(arr, kind='mergesort'):
    if kind == 'mergesort':
        return np.argsort(arr, kind='mergesort')
    else:
        return np.argsort(arr, kind='quicksort')
```
the difference of these 2 inner functions is the way of using `if-else`, the first one is not closed.

### no errors
```python
@njit(parallel=True)
def outer_close_div(matrix):
    result = matrix.copy()
    for i, mat in enumerate(matrix):
        result[i] = inner_closed(mat) / (i + 1)
    return result

outer_close_div(np.random.randn(10, 10))
```
```python
@njit(parallel=True)
def outer_open(matrix):
    result = matrix.copy()
    for i, mat in enumerate(matrix):
        result[i] = inner_open(mat)
    return result

outer_open(np.random.randn(10, 10))
```
### error:
It's strange that `inner_open` can be used alone but can't be used with other operations including itself:

```python
@njit(parallel=True)
def outer_open_div(matrix):
    result = matrix.copy()
    for i, mat in enumerate(matrix):
        result[i] = inner_open(mat) / (i + 1)
    return result

outer_open_div(np.random.randn(10, 10))

@njit(parallel=True)
def outer_open_open(matrix):
    result = matrix.copy()
    for i, mat in enumerate(matrix):
        result[i] = inner_open(mat) + inner_open(mat)
    return result

outer_open_open(np.random.randn(10, 10))
```

```
Traceback (most recent call last):
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/errors.py", line 776, in new_error_context
    yield
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 235, in lower_block
    self.lower_inst(inst)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 497, in lower_inst
    func(self, inst)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/parfors/parfor_lowering.py", line 90, in _lower_parfor_parallel
    lowerer.lower_inst(instr)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 380, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 556, in lower_assign
    return self.lower_expr(ty, value)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 1084, in lower_expr
    res = self.lower_call(resty, expr)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 815, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 1037, in _lower_call_normal
    argvals = self.fold_call_args(
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 754, in fold_call_args
    argvals = typing.fold_arguments(pysig,
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/typing/templates.py", line 243, in fold_arguments
    ba.arguments[name] = normal_handler(i, param, ba.arguments[name])
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 741, in normal_handler
    return self._cast_var(var, signature.args[index])
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 719, in _cast_var
    val = self.loadvar(var.name)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 1327, in loadvar
    ptr = self.getvar(name)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 1319, in getvar
    return self.varmap[name]
KeyError: '$38binary_true_divide.11_size0.6936'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/IPython/core/interactiveshell.py", line 3441, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-49-66d3935fd7b7>", line 8, in <module>
    outer_open_div(np.random.randn(10, 10))
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 501, in _compile_for_args
    raise e
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 434, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 979, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 141, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 155, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 168, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 686, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 492, in _compile_bytecode
    return self._compile_core()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/typed_passes.py", line 396, in run_pass
    lower.lower()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 138, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 192, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 221, in lower_function_body
    self.lower_block(block)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/lowering.py", line 235, in lower_block
    self.lower_inst(inst)
  File "/home/auderson/miniconda3/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/errors.py", line 786, in new_error_context
    raise newerr.with_traceback(tb)
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
'$38binary_true_divide.11_size0.6936'
File "<ipython-input-49-66d3935fd7b7>", line 5:
def outer_open_div(matrix):
    <source elided>
    for i, mat in enumerate(matrix):
        result[i] = inner_open(mat) / (i + 1)
        ^
During: lowering "id=60[LoopNest(index_variable = parfor_index.6937, range = (0, $38binary_true_divide.11_size0.6936, 1))]{2596: <ir.Block at <ipython-input-49-66d3935fd7b7> (5)>}Var(parfor_index.6937, <ipython-input-49-66d3935fd7b7>:5)" at <ipython-input-49-66d3935fd7b7> (5)
```

user: auderson
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7387: state: open
title: Potential race condition in CUDA initialization
body: In: https://github.com/numba/numba/blob/f03b742f08bdfff98d9d7962838d14ce2b866403/numba/cuda/cudadrv/driver.py#L226-L241

Because `self.is_initialized` is set to `True` before any initialization is attempted, two threads can race:

- Thread 1 sees that `is_initialized` is `False`, enters `initialize()`, sets `is_initialized` to `True`, then starts logging and going into `cuInit()`
- Thread 2 meanwhile, after Thread 1 set `is_initialized()` to `True` but before it has done `cuInit()`, checks the value of `is_initialized`, sees it is `True`, then tries to make a CUDA API call prior to the initialization of CUDA.

Noted by @stuartarchibald as part of reviewing #7360 - the fix is likely to involve adding a lock around initialization. As there doesn't seem to be much evidence of this manifesting as a practical problem, and fiddling with threading things is always a little risky, resolution is targeted for 0.55 rather than 0.54.1.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_7379: state: open
title: try .. finally construct throws AssertionError when try block throws exception
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
numba version : 0.53.1 and 0.54.0
```python
import numba

@numba.njit
def test1():
    try:
        print('main block')
    finally:
        print('final block')

        
@numba.njit
def test2():
    try:
        print('main block')
        raise ValueError("")
    finally:
        print('final block')
        
@numba.njit
def test3(a):
    try:
        print('main block')
        if a:
            raise ValueError("")
    finally:
        print('final block')

```

```test1()``` success but ```test2()``` and ```test3(True)``` throw below error.

AssertionError: Unreachable condition reached (op code RERAISE executed)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.54.0.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!

user: hn-sl
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7378: state: open
title: Type annotations are not handled well by @overload signature validation
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit
from numba.extending import overload
import numpy as np

def bar(): ...

@overload(bar)
def ol_bar(x: int):
    def impl(x):
        pass
    return impl

@njit
def foo():
    bar(1)

foo()
```
does this:
```
No implementation of function Function(<function bar at 0x7fdaa918b310>) found for signature:
 
 >>> bar(Literal[int](1))
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'ol_bar': File: elided.py: Line 7.
    With argument(s): '(int64)':
   Rejected as the implementation raised a specific error:
     InternalError: Typing and implementation arguments differ in argument names.
   Typing signature:         (x: int)
   Implementation signature: (x)
   Difference: {<Parameter "x: int">, <Parameter "x">}
       Traceback (most recent call last):
         File "<path>/numba/core/types/functions.py", line 329, in get_call_type
           sig = temp.apply(nolitargs, nolitkws)
         File "<path>/numba/core/typing/templates.py", line 351, in apply
           sig = generic(args, kws)
         File "<path>/numba/core/typing/templates.py", line 605, in generic
           disp, new_args = self._get_impl(args, kws)
         File "<path>/numba/core/typing/templates.py", line 704, in _get_impl
           impl, args = self._build_impl(cache_key, args, kws)
         File "<path>/numba/core/typing/templates.py", line 799, in _build_impl
           self._validate_sigs(self._overload_func, pyfunc)
         File "<path>/numba/core/typing/templates.py", line 583, in _validate_sigs
           raise InternalError(err_prefix + specialized)
       numba.core.errors.InternalError: Typing and implementation arguments differ in argument names.
       Typing signature:         (x: int)
       Implementation signature: (x)
       Difference: {<Parameter "x: int">, <Parameter "x">}
  raised from <path>/numba/core/typing/templates.py:583

During: resolving callee type: Function(<function bar at 0x7fdaa918b310>)
During: typing of call at <path>/elided.py (15)


File "elided.py", line 15:
def foo():
    bar(1)
```
Context xref: https://gitter.im/numba/numba?at=6130029afd7409696eeb35f7
user: stuartarchibald
labels: good second issue: A good issue for second time contributors
bug - incorrect behavior: Bugs: incorrect behavior
issue_7376: state: open
title: Instances of undefined behaviour
body: I've been going through the output of the numba test suite for undefined behaviour sanitizer errors. There are a couple of trivial ones that I'll add PRs for, but this one is a bit more complex (and worrying):

```
SUMMARY: UndefinedBehaviorSanitizer: nullptr-with-offset numba/np/ufunc/workqueue.c:441:48 in 
```

Which is correct given the 4th args value (nil) below.

```
$ NUMBA_THREADING_LAYER=workqueue python runtests.py -v numba/tests/test_stencils.py                                                                                                                                         

test_basic00 (numba.tests.test_stencils.TestManyStencils)                                                                                    
...
inner_ndim: 3                                                                                                                                
arg_len: 4                                                                                                                                   
total: 16                                                                                                                                    
count: 1                                                              
dimensions: 16, 4, 3, 4,                                                                                                                     
steps: 32, 0, 0, 8,                     
*args: 0x7ffc02b9d768, 0x558ff02327d0, 0x558ff0975da0, (nil),      
...
```

The calling code does:
```
    # Array count is input signature plus 1 (due to output array)
    array_count = len(sig.args) + 1    
```

which looks suspicious, but I haven't been able to follow the logic quickly enough to say what's going on here. Hopefully this will be more transparent to someone more familiar with the code.
user: folded
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7374: state: open
title: Add np.putmask support.
body: ## Feature request

Similar to https://github.com/numba/numba/issues/7369. I can do a PR, but I will need help with writing tests. Here is a draft implementation:

```python
@overload(np.putmask)
def putmask(a:np.ndarray, mask: ArrayLike, values: ArrayLike) -> None:
    """Changes elements of an array based on conditional and input values.

    Sets ``a.flat[n] = values[n]`` for each n where ``mask.flat[n]==True``.
    
    If `values` is not the same size as `a` and `mask` then it will repeat.
    This gives behavior different from ``a[mask] = values``.

    Parameters
    ----------
    a : ndarray
        Target array.
    mask : array_like
        Boolean mask array. It has to be the same shape as `a`.
    values : array_like
        Values to put into `a` where `mask` is True. If `values` is smaller
        than `a` it will be repeated.

    See Also
    --------
    np.place, np.put, np.take, np.copyto

    Examples
    --------
    >>> x = np.arange(6).reshape(2, 3)
    >>> np.putmask(x, x>2, x**2)
    >>> x
    array([[ 0,  1,  2],
           [ 9, 16, 25]])
    If `values` is smaller than `a` it is repeated:
    >>> x = np.arange(5)
    >>> np.putmask(x, x>1, [-33, -44])
    >>> x
    array([  0,   1, -33, -44, -33])
    """

    def impl(a:np.ndarray, mask: ArrayLike, values: ArrayLike) -> None:
        mask = np.asarray(mask)
        values = np.atleast_1d(np.asarray(values))
        
        for idx in range(a.size):
            if mask.flat[idx]:
                a.flat[idx] = values.flat[idx % len(values)]

    return impl
```
user: FirefoxMetzger
issue_7373: state: open
title: Support for `where=` kwarg in ufuncs
body: A lot of ufuncs have a explicit version (e.g. [`np.divide`](https://numpy.org/doc/stable/reference/generated/numpy.divide.html)), which extends the basic `a / b` with additional features. I am particularly interested in one of those features: the `where=` argument. A large portion of the AVX/SEE instruction set supports masked operation, which - assuming I understand correctly - `where=` caters to. Is there any plan of supporting this?

In my particular use case, I am computing the angle between two vectors using triangles (for accuracy, see: https://scicomp.stackexchange.com/a/27694) and if the two vectors have an angle of 180° this results in 0/0. Since I'm doing this computation batched, I'm using `where=` to avoid the 0/0 and later overwrite it with `np.pi`, i.e.

```python
...
mask = denominator > eps
angle = np.divide(numerator, denominator, where=mask)
...
np.putmask(angle, ~mask, np.pi)
```
now, I'm turning this into numba code; hence the question.
user: FirefoxMetzger
issue_7371: state: open
title: Support inlining C and C++ (or even LLVM IR) code into nopython-jitted function/class
body: ## Feature request

Would be great if it was possible to inline regular C or C++ code into nopython-jitted function. Something like following:

```
@numba.njit
def f(a):
    c_funcs = numba.c_func("""
        inline int add(int a, int b) { return a + b; }
        inline int mul(int a, int b) { return a * b; }
    """)
    b = 3
    for i in range(5):
        a = c_funcs.mul(c_funcs.add(a, a), b)
    return a
```

Main idea here that C functions (add, mul) code should be inlined into f() and optimized by LLVM.

Of cause there is CFFI support that allows to compile any C functions as `.pyd` module and then use them inside njited-function. But drawback that these C functions are not inlined (they are called by address) into njited code hence not optmized by LLVM as a whole.

I think there should be some way to mix Numba Python's code and C/C++ code directly, because not everything can be done in pure Python.

For example if I want to do multiplication of `u64 x u64 -> u128` then there is no such single-instruction operation in Python and Numba, while in C/C++ it can be done by `unsigned __int128 c = uint64_t(a) * uint64_t(b);` in Clang or `uint64_t hi, lo = _umul128(a, b, &hi);` in MSVC. Which results in single Assembler `mul` instruction using several CPU cycles. In python you can't do this as one CPU instruction.

Of course one can make array u128-multiplication C function using CFFI then non-inlined function call overhead will be small. But it is not always possible to act on whole array - for example I want to implement jitclass that emulates u128 and use this u128 class everywhere for single-value variables in some njitted mathematical code, where there is no work on array at all.

Another use-case is to implement jitclass that emulates BigInteger so that BigInteger (similar like python's `int`) will be available in nopython-function. Of cause efficient single-value (non-array) BigInteger is not possible to implement without inlineable C/C++ functions.

Why C/C++ inlining is crucial? Because it often happens that Numba's Python is lacking some operation and in C/C++ (or even Assembler) this operation can be done as 1-3 CPU instructions. Non-inlined function call that does 1-3 instructions will have too huge overhead.

Also as Numba is LLVM-based then would be great to also be possible to inline LLVM IR (LLVM Intermediate Representation). Or other kind of Assembler-like language. Because when Python code is jitted of cause it is converted to LLVM IR at some point, hence inlining one LLVM IR into another one looks like natural thing.

Inlining LLVM IR will allow anybody to inline any-language code. For example you don't support Rust. But Rust developer can compile Rust to LLVM IR (I think Rust is supported by some fork (or official) of LLVM) and then inline this LLVM IR into your nopython-jitted code. Hence LLVM IR inlining will allow to support any possible language that is based on LLVM.

user: polkovnikov
issue_7370: state: open
title: debugging when JIT a compiled function is derived from string exec
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

Currently, Numba does not have a good mode to debug a jitted function without source code. For example, when I have the following compiled code:

```python

import numba

code = '''
def f(a, b):
  a[0] = b
'''

scope = {}
exec(compile(code, '', 'exec'), scope)
f = numba.njit(scope['f'])
```

After I jit the compiled function and run it, 

```python
f(1, 2)
```

the code has an error, and the numba reports:

```bash

numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function setitem>) found for signature:
 
 >>> setitem(int64, Literal[int](0), int64)
 
There are 16 candidate implementations:
  - Of which 16 did not match due to:
  Overload of function 'setitem': File: <numerous>: Line N/A.
    With argument(s): '(int64, int64, int64)':
   No match.

During: typing of staticsetitem at  (3)

File "D:\codes\Projects\BrainPy\develop\test\numba", line 3:
<source missing, REPL/exec in use?>

```

Numba cannot report where the error is raised, because ``<source missing, REPL/exec in use?>``

When the compiled function is a large program, such debugging is very very difficult!!!

Can we support the error debugging for such compiled function in a more nice way? For example, when I jit the compiled function, I can provide the souce code:

```python

f = numba.njit(scope['f'], source_code=code)

```

Thank you very much!





user: chaoming0625
issue_7369: state: open
title: Add np.moveaxis support.
body: ## Feature request

I'd like to add `np.moveaxis` support to numba. It's a real swizz army knife. It allows a trivial implementation of `np.swapaxis` as `np.moveaxis(a, (axis1, axis2), (axis2, axis1))` and enables a lot of `axis=...` kwargs, e.g. for supporting it in reduction ops (https://github.com/numba/numba/issues/1269).

I'm not very familiar with numba so I didn't do extensive type handling; however, here is a working implementation for using tuples for the axes to move based on numpy's source:

```python
@overload(np.moveaxis)
def moveaxis(a:np.ndarray, source, destination) -> np.ndarray:
    """ Move axes of an array to new positions.

    Other axes remain in their original order.

    Parameters
    ----------
    a : np.ndarray
        The array whose axes should be reordered.
    source : int or sequence of int
        Original positions of the axes to move. These must be unique.
    dest : int or sequence of int
        Destination positions for each of the original axes. These must also be unique.

    Returns
    -------
    result : np.ndarray
        Array with moved axes. This array is a view of the input array.

    Notes
    -----
    If one of (source, destination) is an integer, then the other must be an integer, too.

    See Also
    --------
    `np.moveaxis <https://numpy.org/doc/stable/reference/generated/numpy.moveaxis.html>`_
    """

    @register_jitable
    def impl_array(a:np.ndarray, source, destination):
        source_work = np.atleast_1d(np.asarray(source))
        destination_work = np.atleast_1d(np.asarray(destination))

        if source_work.size != destination_work.size:
            raise ValueError(
                "`source` and `destination` arguments must have "
                "the same number of elements"
            )

        for idx in range(source_work.size):
            if abs(source_work[idx]) > a.ndim:
                raise ValueError("Invalid axis in `source`.")
            if abs(destination_work[idx]) > a.ndim:
                raise ValueError("Invalid axis in `destination`.")

        source_work = [x % a.ndim for x in source_work]
        destination_work = [x % a.ndim for x in destination_work]

        order = [n for n in range(a.ndim) if n not in source_work]
        for dest, src in sorted(zip(destination_work, source_work)):
            order.insert(dest, src)

        oder_tuple = to_fixed_tuple(np.array(order), a.ndim)
        return np.transpose(a, oder_tuple)

    @register_jitable
    def impl_int(a:np.ndarray, source, destination):
        if abs(source) > a.ndim:
            raise ValueError("Invalid axis in `source`.")
        if abs(destination) > a.ndim:
            raise ValueError("Invalid axis in `destination`.")

        source = source % a.ndim
        destination = destination % a.ndim

        order = [n for n in range(a.ndim) if n != source]
        order.insert(destination, source)

        oder_tuple = to_fixed_tuple(np.array(order), a.ndim)
        return np.transpose(a, oder_tuple)

    if isinstance(source, types.Integer) and isinstance(destination, types.Integer):
        return impl_int
    else:
        return impl_array
```

I'm happy to help with a PR; however, I don't think I can do it alone. I have no experience with numba's codebase, which means that I will likely miss any existing helpers to deal with various input types or with testing corner cases. If somebody is willing to guide me through that jungle I'm happy to get the ball rolling.

**Edit:** Replaced implementation with one that supports int or iterable for `source` and `destination` making it behave 90% like `np.moveaxis`
user: FirefoxMetzger
issue_7368: state: open
title: CUDA distance matrix (cdist, pdist, and sparse versions, Euclidean, Wasserstein, etc.)
body: ## Feature request

I'm interested in applying `@cuda.jit` decorators to calculate pairwise distance matrices. The [Wasserstein or earth mover's distance](https://en.wikipedia.org/wiki/Wasserstein_metric) is of particular interest to me, which I [mentioned on discourse](https://numba.discourse.group/t/how-to-compute-a-wasserstein-distance-matrix-via-a-numba-cuda-kernel/850). I'd like to use these matrices with [UMAP](https://github.com/lmcinnes/umap).

[`scipy.spatial.distance`](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) is probably a good reference for the type of functionality this could eventually be expanded to. For example, this has:
- `cdist` : pairwise distances between two collections of vectors
- `pdist` : pairwise distances within a single set of vectors

Another use case is to compute a sparse distance matrix using pre-specified pair indices.

Euclidean distance is fairly ubiquitous and easy to implement and can serve both as a useful metric and a debugging tool.
`scipy.stats` has a `wasserstein_distance` that has a simpler implementation than a lot of other methods in my opinion. However, I think even this one is at the higher end of complexity as far as standard distance metrics go.
user: sgbaird
labels: CUDA: CUDA related issue/PR
issue_7354: state: open
title: Clarify development instructions regarding llvmlite dev releases
body: As per Gitter:

<img width="761" alt="Screen Shot 2021-08-30 at 10 56 13" src="https://user-images.githubusercontent.com/41563/131313972-4ca1ad9e-259e-4d4e-aab1-e202ef3806a2.png">

We need to update the instructions at:

https://numba.readthedocs.io/en/latest/developer/contributing.html#build-environment?

So as to include installing an llvmlite release from. `numba/label/dev`.
user: esc
labels: bug - documentation incorrect: documentation is incorrect or missing something important
issue_7350: state: open
title: Vectorize with target parallel silently swallows exceptions
body: See https://github.com/numba/numba/issues/1206 for related concepts.

When I compile a function using `@vectorize` with `target='parallel'`, then it can silently ignore exceptions.  Compiling the same thing with `target='cpu'` behaves as expected.  I haven't tried `cuda`.

```python
import numpy as np
from numba import float64, vectorize

@vectorize([float64(float64)], target='cpu')
def x_sec_area_cpu(diam):
    if diam <= 0.0:
        raise ValueError('Diameter must be strictly positive')
    return np.pi * (diam / 2.0)**2

@vectorize([float64(float64)], target='parallel')
def x_sec_area_par(diam):
    if diam <= 0.0:
        raise ValueError('Diameter must be strictly positive')
    return np.pi * (diam / 2.0)**2

if __name__ == '__main__':
    x_sec_area_par([0.1, -4.])  # does not raise ValueError
    x_sec_area_cpu([0.1, -4.])  # raises ValueError as expected
```

I'm using Python v3.9.6 on Windows 10, with numba v0.54.0
user: DStauffman
labels: threading: Issue involving the threading layers
bug - incorrect behavior: Bugs: incorrect behavior
issue_7343: state: open
title: Numba's object mode processing closure failed
body: When I run the following code in object mode, I get an error

```python
from numba import jit

@jit(forceobj=True)
def fn():
    x = 1
    def gn():
        print(x)
    return gn

fn()
```

The error message is:
```python
Traceback (most recent call last):
  File "testnumba3.py", line 10, in <module>
    fn()()
NameError: global name 'gn' is not defined

```
user: ssili
labels: objectmode: object mode related issue
bug - failure to compile: Bugs: failed to compile valid code
issue_7342: state: open
title: CUDA implicit copy warnings do not fire for guvectorize
body: The following:

```python
from numba import guvectorize
import numpy as np

@guvectorize(['void(float32[:], float32[:], float32[:])'],
             '(n),(n)->(n)', target='cuda')
def numba_dist_cuda(a, b, dist):
    len = a.shape[0]
    for i in range(len):
        dist[i] = a[i] * b[i]

a = np.random.rand(1024 * 32).astype('float32')
b = np.random.rand(1024 * 32).astype('float32')
dist = np.zeros(a.shape[0]).astype('float32')


numba_dist_cuda(a, b, dist)
```

emits the following warnings:

```
numba/cuda/decorators.py:118: NumbaDeprecationWarning: Eager compilation of device functions is deprecated (this occurs when a signature is provided)
  warn(NumbaDeprecationWarning(msg))
/numba/cuda/compiler.py:872: NumbaPerformanceWarning: Grid size (1) < 2 * SM count (144) will likely result in GPU under utilization due to low occupancy.
  warn(NumbaPerformanceWarning(msg))
```

but does not warn about the implicit copies of `a`, `b`, and `dist`.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7341: state: open
title: Performance measurement helpers and examples
body: ## Feature request

For a library that is used to speed up the code, it seems quite essential to have an easy way to measure the result of modifications. Both for improvements, for regressions, and just for testing how things work. However, even the [Performance Tips](https://numba.readthedocs.io/en/stable/user/performance-tips.html) doesn't contain the code to repeat the performance measurements.

As a DevOps who deals with updating dependencies almost on a daily basis, because of security issues or build failures, I would appreciate if documentation contained examples with code snippets and provided helpers to profile and compare Numba performance between releases.

I found that people are using `timeit()` with custom formatters for the results.

* https://github.com/cristipurdel/python/commit/fb56f9af829d010eac9d19f26adb5169b18b8ae5#commitcomment-30853780
* https://numba.discourse.group/t/numba-performance-doesnt-scale-as-well-as-numpy-in-vectorized-max-function/782

From `timeit` execution it it not really clear how much time was spent on compiling the code, if anything was compiled at all, if the compiled code was faster of slower.

It looks like people mostly do the measurements manually, adding and removing decorators, restarting notebooks for each measurement. I would expect something more automated, maybe a modification to `@jit` decorator that will add some `profiling` mode to it, where it will be possible to rerun wrapped functions with `timeit()` and collect the data in a format suitable for comparison, with distinction between compile time and run time, maybe even analysing the data passed to functions to detect data specific problems. This behaviour in this profiling mode could then be controlled by environment variables.

Ideally as a DevOps I just want a single command to get and measure performance, which will be added into CI/CD cycle. Or at least a clear instruction how to get the fixture, where to place the files, how to run the measurement and compare the results. An instruction for a person with a zero knowledge of Numba would be ideal, meaning that it could be followed by anyone who would like to save me some time for other, no less important tasks.
user: abitrolly
issue_7338: state: open
title: Incorrectly typed as literal when variable maybe undefined.
body: I found the problem for the unexpected result. Type inference (or constant propagation) is incorrectly assuming the return type to be a constant because there is no other assignment. 


Following is output from `reproduce_bug_bool.inspect_types()`
```python
    # --- LINE 11 ---
    #   jump 10
    # label 10
    #   del $4pred
    #   $12return_value.1 = cast(value=test_var)  :: Literal[bool](True)
    #   del test_var
    #   return $12return_value.1

    return test_var
```

_Originally posted by @sklam in https://github.com/numba/numba/issues/7327#issuecomment-904070851_
user: sklam
labels: bug - miscompile: Bugs: miscompile
issue_7327: state: open
title: Numba does not error out when an if statement does not account for all conditions
body: - [Yes] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).

- [Yes] I have included a self contained code sample to reproduce the problem.
i.e. it's possible to run as 'python bug.py'.

I discovered that I had a hanging if statement which, when Numba was disabled, encountered a condition that should have been covered by an 'else' part of the conditional but wasn't, causing the function to fail. Numba, however, never threw an error, which led me to investigate why.
It turns out that Numba will implicitly assign and return the variable. I tried searching to see if this is expected/designed behavior but couldn't find anything.

I want to show that a variable will be successfully returned even in the event of a hanging if statement (incompletely enumerated conditions)


```python
import numba
from numba import njit, types
import numpy as np

@njit(parallel=False)
def reproduce_bug_bool(test_condition_bool):

    if test_condition_bool:
        test_var = True
        
    return test_var

@njit(parallel=False)
def reproduce_bug_float(test_condition_bool):

    if test_condition_bool:
        test_var = 10.0
        
    return test_var

@njit(parallel=False)
def reproduce_bug_int(test_condition_bool):

    if test_condition_bool:
        test_var = 10
        
    return test_var

num_trials = 10
test_cases = np.asarray([True, False, True, False, True, False, True, False, True, False])

for t in range(num_trials):
    print("Test case: ", test_cases[t])
    returned_bool = reproduce_bug_bool(test_cases[t])
    returned_float = reproduce_bug_float(test_cases[t])
    returned_int = reproduce_bug_int(test_cases[t])
    
    print("Returned bool var: ", returned_bool)
    print("Returned float var: ", returned_float)
    print("Returned int var: ", returned_int)
```

All results seem both arbitrary and dangerous; I would expect them to throw errors.
In test case 1 (bool), the unaccounted-for condition implicitly takes on the same value as in the accounted-for condition (True). (I originally ran my code in version 0.46, and the value came back as False, which seemed dangerous but plausibly correct.)
In test case 2 (float) the unaccounted-for condition implicitly takes on the value of 0.0, rather arbitrarily.
In test case 3 (int), the unaccounted-for condition implicitly takes on the same value as in the accounted-for condition (10).


user: e-dvl
issue_7326: state: open
title: CUDA: NVVM crash with reproducer
body: The following (from #4783, which is closed):

```python
# -*- coding: utf-8 -*-
"""
Created on Thu Aug 19 16:30:07 2021.

@author: sterg

Compute the 1-Wasserstein distance (Earth Mover's distance) via Numba/CUDA kernel.
"""

import os

# needs to appear before cuda import
os.environ["NUMBA_ENABLE_CUDASIM"] = "0"
# set to "1" for more debugging, but slower performance
os.environ["NUMBA_CUDA_DEBUGINFO"] = "1"
from numba import cuda, njit
from numba.types import int32, float32, int64, float64

from pdb import set_trace

import numpy as np

from math import sqrt

USE_64 = False

if USE_64:
    bits = 64
    nb_float = float64
    nb_int = int64
    np_float = np.float64
    np_int = np.int64
else:
    bits = 32
    nb_float = float32
    nb_int = int32
    np_float = np.float32
    np_int = np.int32

# local array shapes needs to be defined globally due to lack of dynamic array allocation support. Don't wrap with np.int32, etc. see https://github.com/numba/numba/issues/7314
rows = 10
cols = 3
cols_plus_1 = cols + 1
tot_cols = cols * 2
tot_cols_minus_1 = tot_cols - 1

np.random.seed(42)
[U, V, U_weights, V_weights] = [np.random.rand(rows, cols) for i in range(4)]

device = True
inline = True


@cuda.jit(device=device, inline=inline)
def copy(a, out):
    """
    copy a into out.

    Parameters
    ----------
    a : vector
        values to copy.
    out : vector
        values to copy into.

    Returns
    -------
    None.

    """
    for i in range(len(a)):
        i = int(i)
        out[i] = a[i]


@cuda.jit(device=device, inline=inline)
def partition(arr, ids, l, h):
    """
    Partition using pivot.

    Function takes last element as pivot, places the pivot element at its correct
    position in sorted array, and places all smaller (smaller than pivot) to left of
    pivot and all greater elements to right of pivot

    Source: Modified from https://www.geeksforgeeks.org/iterative-quick-sort/
    which was contributed by Mohit Kumra.

    Parameters
    ----------
    arr : vector of floats
        The array to be sorted.
    ids : vector of ints
        The unsorted IDs corresponding to arr, in other words range(len(arr)).
    l : int
        Starting index for sorting.
    h : int
        Ending index for sorting.

    Returns
    -------
    int
        the new pivot?

    """
    # index of smaller element
    i = l - 1

    pivot = arr[h]

    for j in range(l, h):

        # If current element is smaller than or equal to pivot
        if arr[j] <= pivot:

            # increment index of smaller element
            i += 1
            arr[i], arr[j] = arr[j], arr[i]
            ids[i], ids[j] = ids[j], ids[i]

    arr[i + 1], arr[h] = arr[h], arr[i + 1]
    ids[i + 1], ids[h] = ids[h], ids[i + 1]

    return i + 1


@cuda.jit(device=device, inline=inline)
def quickSortIterative(arr, stack, ids):
    """
    Perform iterative quicksort on array and an unsorted ID list of the array.

    Source: Modified from https://www.geeksforgeeks.org/iterative-quick-sort/
    which was contributed by Mohit Kumra.

    Parameters
    ----------
    arr : vector of floats
        The array to be sorted.
    stack : vector of ints
        Array initialized with 0's
    ids : vector of ints
        The unsorted IDs corresponding to arr, in other words range(len(arr)).

    Returns
    -------
    None.

    """
    # low and high indices.
    l, h = (0, len(arr) - 1)
    # stack = [0] * size
    # ids = list(range(len(arr)))

    # initialize top of stack
    top = -1

    # fill ids with range(len(arr))
    for i in range(len(arr)):
        ids[i] = i
        stack[i] = 0

    # push initial values of l and h to stack
    top = top + 1
    stack[top] = l
    top = top + 1
    stack[top] = h

    # Keep popping from stack while is not empty
    while top >= 0:

        # Pop h and l
        h = stack[top]
        top = top - 1
        l = stack[top]
        top = top - 1

        # Set pivot element at its correct position in
        # sorted array
        p = partition(arr, ids, l, h)

        # If there are elements on left side of pivot,
        # then push left side to stack
        if p - 1 > l:
            top = top + 1
            stack[top] = l
            top = top + 1
            stack[top] = p - 1

        # If there are elements on right side of pivot,
        # then push right side to stack
        if p + 1 < h:
            top = top + 1
            stack[top] = p + 1
            top = top + 1
            stack[top] = h


@cuda.jit(device=device, inline=inline)
def concatenate(vec, vec2, out):
    """
    Concatenate two vectors.

    Parameters
    ----------
    vec : vector
        First vector to concatenate.
    vec2 : vector
        Second vector to concatenate.
    out : vector
        Initialization of concatenated vector.

    Returns
    -------
    None.

    """
    # number of elements
    n = len(vec)
    n2 = len(vec2)
    # initialize
    # out =cuda.local.array(n+n2, nb_float) # doesn't work because of dynamic allocation
    # populate out
    for i in range(n):
        out[i] = vec[i]
    for i in range(n2):
        out[i + n2] = vec2[i]


@cuda.jit(device=device, inline=inline)
def diff(vec, out):
    """
    Compute gradient.

    Parameters
    ----------
    vec : vector of floats
        The vector for which to calculate the gradient.
    out : vector of floats
        Initialization of output vector (one less element than vec) which contains the gradient.

    Returns
    -------
    None.

    """
    # number of elements
    n = len(vec) - 1
    # progressively add next elements
    for i in range(n):
        out[i] = vec[i + 1] - vec[i]


@cuda.jit(device=device, inline=inline)
def bisect_right(a, v, ids):
    """
    Return the indices where to insert items in v in list a, assuming a is sorted.

    Parameters
    ----------
    arr : 1D array
        Array for which to perform a binary search.
    v : 1D array
        Values to perform the binary search for.
    ids : 1D array
        Initialized list of indices, same size as v.

    Returns
    -------
    None.

    The return value i is such that all e in a[:i] have e <= x, and all e in
    a[i:] have e > x.  So if x already appears in the list, a.insert(x) will
    insert just after the rightmost x already there. Optional args lo (default 0)
    and hi (default len(a)) bound the slice of a to be searched.

    Source: modified from https://github.com/python/cpython/blob/43bab0537ceb6e2ca3597f8f3a3c79733b897434/Lib/bisect.py#L15-L35
    """
    n = len(a)
    n2 = len(v)
    for i in range(n2):
        lo = 0
        mid = 0
        hi = n
        x = v[i]
        while lo < hi:
            mid = (lo + hi) // 2
            # Use __lt__ to match the logic in list.sort() and in heapq
            if x < a[mid]:
                hi = mid
            else:
                lo = mid + 1
        ids[i] = lo


@cuda.jit(device=device, inline=inline)
def sort_by_indices(v, ids, out):
    """
    Sort v by ids and assign to out, as in out = v[ids].

    Parameters
    ----------
    v : vector
        values to sort.
    ids : vector
        indices to use for sorting.
    out : vector
        preallocated vector to put sorted values into.

    Returns
    -------
    None.

    """
    for i in range(len(v)):
        idx = ids[i]
        out[i] = v[idx]


@cuda.jit(device=device, inline=inline)
def cumsum(vec, out):
    """
    Return the cumulative sum of the elements in a vector.

    Referenced https://stackoverflow.com/a/15889203/13697228

    Parameters
    ----------
    vec : 1D array
        Vector for which to compute the cumulative sum.

    out: 1D array
        Initialized vector which stores the cumulative sum.

    prepend_zero : bool
        Whether to prepend a zero (fairly specific to Wasserstein distance).

    Returns
    -------
    out : 1D array
        The cumulative sum of elements in vec (same shape as vec).

    """
    # number of elements
    n = len(vec)
    # initialize
    total = 0.0
    # progressively add next elements
    for i in range(n):
        total += vec[i]
        out[i] = total


@cuda.jit(device=device, inline=inline)
def divide(v, b, out):
    """
    Divide a vector by a scalar.

    Parameters
    ----------
    v : vector
        vector numerator.
    b : float
        scalar denominator.
    out : vector
        initialized vector to populate with divided values.

    Returns
    -------
    None.

    """
    for i in range(len(v)):
        out[i] = v[i] / b


@cuda.jit(device=device, inline=inline)
def ecdf(u, sorted_weights, cdf_indices, out):
    """
    Compute the weighted empirical cumulative density function (ECDF) for a vector.

    Parameters
    ----------
    u : vector
        Monotonically increasing vector for which to compute the ECDF.
    weights : vector
        Vector of weights, the same size as u, used to weight the ECDF.
    out : vector
        Initialized vector, same size as u, in which to place the ECDF.

    Returns
    -------
    None.

    """
    # allocate local arrays
    sorted_cumweights = cuda.local.array(cols_plus_1, nb_float)
    cdf_sorted_cumweights = cuda.local.array(tot_cols_minus_1, nb_float)

    # cumulative sum, and normalization
    sorted_cumweights[0] = 0.0
    cumsum(sorted_weights, sorted_cumweights[1:])

    sort_by_indices(sorted_cumweights, cdf_indices, cdf_sorted_cumweights)
    # sort_by_indices(sorted_cumweights, cdf_indices, cdf_sorted_cumweights)
    divide(cdf_sorted_cumweights, sorted_cumweights[-1], out)


@cuda.jit(device=device, inline=inline)
def integrate(u_cdf, v_cdf, deltas, p):
    """
    Integrate between two vectors using a p-norm.

    Parameters
    ----------
    u_cdf : numeric vector
        First CDF.
    v_cdf : numeric vector
        Second CDF of same length as a.
    deltas : numeric vector
        The differences between the original vectors a and b.
    p : int, optional
        The finite power for which to compute the p-norm. The default is 2.

    If p == 1 or p == 2, use of power is avoided, which introduces an overhead
    # of about 15% (according to https://github.com/scipy/scipy/blob/47bb6febaa10658c72962b9615d5d5aa2513fa3a/scipy/stats/stats.py#L8404-L8488)
    However, without support for math.square or np.square (2021-08-19), math.pow
    is required for p == 2.

    Returns
    -------
    out : numeric scalar
        The p-norm of a and b.

    """
    n = len(u_cdf)
    out = 0.0
    if p == 1:
        for i in range(n):
            out += abs(u_cdf[i] - v_cdf[i]) * deltas[i]
    elif p == 2:
        for i in range(n):
            out += ((u_cdf[i] - v_cdf[i]) ** p) * deltas[i]
            out = sqrt(out)
    elif p > 2:
        for i in range(n):
            out += (u_cdf[i] - v_cdf[i]) ** p * deltas[i]
            out = out ** (1 / p)
    return out


@cuda.jit(device=device, inline=inline)
def cdf_distance(u, v, u_weights, v_weights, p, out):
    r"""
    Compute distance between two one-dimensional distributions :math:`u` and :math:`v`.

    The respective CDFs are :math:`U` and :math:`V`, and the
    statistical distance is defined as:
    .. math::
        l_p(u, v) = \left( \int_{-\infty}^{+\infty} |U-V|^p \right)^{1/p}
    p is a positive parameter; p = 1 gives the Wasserstein distance, p = 2
    gives the energy distance.

    Parameters
    ----------
    u_values, v_values : array_like
        Values observed in the (empirical) distribution.
    u_weights, v_weights : array_like
        Weight for each value.
        `u_weights` (resp. `v_weights`) must have the same length as
        `u_values` (resp. `v_values`). If the weight sum differs from 1, it
        must still be positive and finite so that the weights can be normalized
        to sum to 1.

    Returns
    -------
    distance : float
        The computed distance between the distributions.

    Notes
    -----
    The input distributions can be empirical, therefore coming from samples
    whose values are effectively inputs of the function, or they can be seen as
    generalized functions, in which case they are weighted sums of Dirac delta
    functions located at the specified values.

    References
    ----------
    .. [1] Bellemare, Danihelka, Dabney, Mohamed, Lakshminarayanan, Hoyer,
           Munos "The Cramer Distance as a Solution to Biased Wasserstein
           Gradients" (2017). :arXiv:`1705.10743`.
    """
    # allocate local float arrays
    ## combined vector
    uv = cuda.local.array(tot_cols, nb_float)
    uv_deltas = cuda.local.array(tot_cols_minus_1, nb_float)

    ## CDFs and sorted weights
    u_cdf = cuda.local.array(tot_cols_minus_1, nb_float)
    v_cdf = cuda.local.array(tot_cols_minus_1, nb_float)

    u_sorted_weights = cuda.local.array(cols, nb_float)
    v_sorted_weights = cuda.local.array(cols, nb_float)
    # u_cdf_sorted = cuda.local.array(tot_cols_minus_1, nb_float)
    # v_cdf_sorted = cuda.local.array(tot_cols_minus_1, nb_float)

    # allocate local int arrays
    ## sorters and stacks
    u_sorter = cuda.local.array(cols, nb_int)
    u_stack = cuda.local.array(cols, nb_int)

    v_sorter = cuda.local.array(cols, nb_int)
    v_stack = cuda.local.array(cols, nb_int)

    uv_sorter = cuda.local.array(tot_cols, nb_int)
    uv_stack = cuda.local.array(tot_cols, nb_int)

    ## CDF indices via binary search
    u_cdf_indices = cuda.local.array(tot_cols_minus_1, nb_int)
    v_cdf_indices = cuda.local.array(tot_cols_minus_1, nb_int)

    # concatenate u and v into uv
    concatenate(u, v, uv)

    # sorting
    quickSortIterative(u, u_stack, u_sorter)
    sort_by_indices(u_weights, u_sorter, u_sorted_weights)
    quickSortIterative(v, v_stack, v_sorter)
    sort_by_indices(v_weights, v_sorter, v_sorted_weights)
    quickSortIterative(uv, uv_stack, uv_sorter)

    # Get the respective positions of the values of u and v among the values of
    # both distributions. See also np.searchsorted
    bisect_right(u, uv[:-1], u_cdf_indices)
    bisect_right(v, uv[:-1], v_cdf_indices)

    # empirical CDFs
    ecdf(u, u_sorted_weights, u_cdf_indices, u_cdf)
    ecdf(v, v_sorted_weights, v_cdf_indices, v_cdf)

    # # # set_trace()

    # sorting
    # u_cdf_sorted[0] = 0.0
    # v_cdf_sorted[0] = 0.0
    # sort_by_indices(u_cdf, u_cdf_indices, u_cdf_sorted)
    # sort_by_indices(v_cdf, v_cdf_indices, v_cdf_sorted)

    # # # copy(v_cdf_sorted, out)

    # Integration
    diff(uv, uv_deltas)  # See also np.diff
    out = integrate(u_cdf, v_cdf, uv_deltas, p)


#

# out_cols = cols_plus_1
# out_cols = tot_cols_minus_1
# out_cols = cols
# shape = (rows, out_cols)
# shape = rows


@cuda.jit(device=device, inline=inline)
def wasserstein_distance(u, v, u_weights, v_weights, out):
    r"""
    Compute the first Wasserstein distance between two 1D distributions.

    This distance is also known as the earth mover's distance, since it can be
    seen as the minimum amount of "work" required to transform :math:`u` into
    :math:`v`, where "work" is measured as the amount of distribution weight
    that must be moved, multiplied by the distance it has to be moved.

    Source: https://github.com/scipy/scipy/blob/47bb6febaa10658c72962b9615d5d5aa2513fa3a/scipy/stats/stats.py#L8245-L8319

    Parameters
    ----------
    u_values, v_values : array_like
        Values observed in the (empirical) distribution.
    u_weights, v_weights : array_like, optional
        Weight for each value. If unspecified, each value is assigned the same
        weight.
        `u_weights` (resp. `v_weights`) must have the same length as
        `u_values` (resp. `v_values`). If the weight sum differs from 1, it
        must still be positive and finite so that the weights can be normalized
        to sum to 1.

    Returns
    -------
    distance : float
        The computed distance between the distributions.

    Notes
    -----
    The input distributions can be empirical, therefore coming from samples
    whose values are effectively inputs of the function, or they can be seen as
    generalized functions, in which case they are weighted sums of Dirac delta
    functions located at the specified values.

    References
    ----------
    .. [1] Bellemare, Danihelka, Dabney, Mohamed, Lakshminarayanan, Hoyer,
           Munos "The Cramer Distance as a Solution to Biased Wasserstein
           Gradients" (2017). :arXiv:`1705.10743`.
    """
    cdf_distance(u, v, u_weights, v_weights, np_int(1), out)


@cuda.jit(
    "void(float{0}[:,:], float{0}[:,:], float{0}[:,:], float{0}[:,:], float{0}[:,:])".format(
        bits
    )
)
def distance(U, V, U_weights, V_weights, out):
    # get CUDA iterator
    idx = cuda.grid(1)

    # for debugging
    x = cuda.threadIdx.x
    bx = cuda.blockIdx.x
    bdx = cuda.blockDim.x
    # if x == 1 and bx == 3:
    #     set_trace()

    if idx < rows:
        # unpack
        u = U[idx]
        v = V[idx]
        u_weights = U_weights[idx]
        v_weights = V_weights[idx]

        # calculation
        wasserstein_distance(u, v, u_weights, v_weights, out[idx])


def driver(U, V, U_weights, V_weights):
    # block, grid
    block_dim = 1
    grid_dim = int(rows // block_dim + 1)

    # CUDA setup
    stream = cuda.stream()

    # copying/allocating to GPU
    cuda_U = cuda.to_device(np.asarray(U, dtype=np_float), stream=stream)
    cuda_V = cuda.to_device(np.asarray(V, dtype=np_float), stream=stream)
    cuda_U_weights = cuda.to_device(
        np.asarray(U_weights, dtype=np_float), stream=stream
    )
    cuda_V_weights = cuda.to_device(
        np.asarray(V_weights, dtype=np_float), stream=stream
    )
    cuda_out = cuda.device_array((rows, cols), np_float)

    # calculations
    distance[grid_dim, block_dim](
        cuda_U, cuda_V, cuda_U_weights, cuda_V_weights, cuda_out
    )

    # copy to CPU
    out = cuda_out.copy_to_host(stream=stream)

    return out


out = driver(U, V, U_weights, V_weights)
print(out[0])

"""CODE GRAVEYARD"""
"""
"""
```

causes an NVVM crash with Numba master.

cc @sgbaird
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_7310: state: open
title: LinkedList traversing and assignment fails
body: I think this is a bug that has come up in other variations (#1719 and #1718).  This seems to make traversing and then assigning left/right nodes impossible from a compiled function.  (this works fine when runme is not compiled)

```
from numba import deferred_type,optional
from numba import int64
from numba import njit
from numba.experimental import jitclass

list_type = deferred_type()

spec = [
    ('data',int64),
    ('left',optional(list_type)),
    ('right',optional(list_type))
]
@jitclass(spec)
class List(object):
    def __init__(self,data,left,right):
        self.data = data
        self.left = left
        self.right = right
        
list_type.define(List.class_type.instance_type)

@njit
def runme():
    far_left = List(1,None,None)
    middle = List(2,far_left,None)
    far_right = List(3,middle,None)
    
    far_left.right = middle
    middle.right = far_right
    
    #fails
    far_left.right.left.right = middle
    
    #fails
    far_left.right.left.right = None
    
    #works
    far_left.right = None        
    
    
if __name__ == '__main__':
    runme()
```

throws

```
No definition for lowering DeferredType#139981219980000.right = OptionalType(DeferredType#139981219980000) i.e. the type 'DeferredType#139981219980000 or None'

File "linkedlist_fail.py", line 32:
def runme():
    <source elided>
    #fails
    far_left.right.left.right = None
    ^
```
user: scottbecker
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7308: state: open
title: Compilation fails when creating dicts with lists as mapped values
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi,

As it was discussed previously I'm opening a case on this. 
Here's the reproducer:
```
import numba
from numba import types, njit
import numpy as np

@njit
def test_impl():
    aggs = {
        'one': ['mean'],
        'two': ['min', 'max', 'mean'],
        'three': ['std', 'mean']
    }
    return len(aggs)

print(test_impl())
```

That throws:

> Traceback (most recent call last):
>   File "test_numba_dicts_1.py", line 14, in <module>
>     print(test_impl())
>   File "/localdisk/work/akozlov/miniconda3/numba_master/numba/numba/core/dispatcher.py", line 420, in _compile_for_args
>     error_rewrite(e, 'typing')
>   File "/localdisk/work/akozlov/miniconda3/numba_master/numba/numba/core/dispatcher.py", line 361, in error_rewrite
>     raise e.with_traceback(None)
> numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
> list(unicode_type)<iv=None> as value is forbidden
> During: typing of dict at test_numba_dicts_1.py (7)
> 
> File "test_numba_dicts_1.py", line 7:
> def test_impl():
>     aggs = {
>     ^

And explicit use of typed.Dicts ctor with value_type requesting reflected_list as values fails too:

```
import numba
from numba import types, njit
import numpy as np
from numba.typed import Dict

dict_val_type = types.List(types.unicode_type)

@njit
def test_impl():

    aggs = Dict.empty(types.unicode_type, dict_val_type)
    return len(aggs)

print(test_impl())
```

Giving:
>    There are 2 candidate implementations:
>          - Of which 2 did not match due to:
>          Overload in function 'impl_new_dict': File: numba/typed/dictobject.py: Line 639.
>            With argument(s): '(typeref[unicode_type], typeref[list(unicode_type)<iv=None>])':
>           Rejected as the implementation raised a specific error:
>             TypingError: Failed in nopython mode pipeline (step: nopython frontend)
>           No implementation of function Function(<intrinsic _make_dict>) found for signature:
> 
>            >>> <unknown function>(typeref[unicode_type], typeref[list(unicode_type)<iv=None>], void*)
> 
>           There are 2 candidate implementations:
>                 - Of which 2 did not match due to:
>                 Intrinsic in function '_make_dict': File: numba/typed/dictobject.py: Line 598.
>                   With argument(s): '(typeref[unicode_type], typeref[list(unicode_type)<iv=None>], void*)':
>                  Rejected as the implementation raised a specific error:
>                    TypingError: list(unicode_type)<iv=None> as value is forbidden
>             raised from /localdisk/work/akozlov/miniconda3/numba_master/numba/numba/core/types/containers.py:686
> 
>           During: resolving callee type: Function(<intrinsic _make_dict>)
>           During: typing of call at /localdisk/work/akozlov/miniconda3/numba_master/numba/numba/typed/dictobject.py (655)

I think this should be support in some way, otherwise jitting function utilizing python dicts becomes quite difficult.

Best Regards,
Alexey.
user: kozlov-alexey
issue_7305: state: open
title: Refactor phi node data storage
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
When debugging updates to some passes, this oddity appeared:

```python
from numba import njit
from numba.core.compiler import CompilerBase, PassManager
from numba.core.compiler_machinery import AnalysisPass, register_pass
from numba.core.untyped_passes import IRProcessing, TranslateByteCode, FixupArgs, ReconstructSSA

@register_pass(mutates_CFG=False, analysis_only=True)
class PrintIR(AnalysisPass):
    _name = "print_ir"

    def __init__(self):
        AnalysisPass.__init__(self)

    def run_pass(self, state):
        state.func_ir.dump()
        return False

class SSACompiler(CompilerBase):

    def define_pipelines(self):
        state = self.state
        state.cr = None
        pm = PassManager('ssa')
        pm.add_pass(TranslateByteCode, "analyzing bytecode")
        pm.add_pass(FixupArgs, "fix up args")
        pm.add_pass(IRProcessing, "processing IR")
        pm.add_pass(ReconstructSSA, "ssa")
        pm.add_pass(PrintIR, "print IR")

        pm.finalize()
        return [pm]

is_integer = True
tp = types.intp
zerodiv_return = False

@njit(pipeline_class=SSACompiler)
def foo(a, b):
    # This is the numba.cpython.numbers::int_power_impl function body
    r = tp(1)
    a = tp(a)
    if b < 0:
        invert = True
        exp = -b
        if exp < 0:
            raise OverflowError
        if is_integer:
            if a == 0:
                if zerodiv_return:
                    return zerodiv_return
                else:
                    raise ZeroDivisionError("0 cannot be raised to a negative power")
            if a != 1 and a != -1:
                return 0
    else:
        invert = False
        exp = b
    if exp > 0x10000:
        return math.pow(a, float(b))
    while exp != 0:
        if exp & 1:
            r *= a
        exp >>= 1
        a *= a

    return 1.0 / r if invert else r

x, y = -2, 1
print(foo(x, y))
print(foo.py_func(x, y))
```
The IR has lines like:
```
    invert.2 = phi(incoming_values=[Var(invert, debug_ssa1.py:142), Var(invert.1, debug_ssa1.py:155), Var(invert, debug_ssa1.py:142), Var(invert, debug_ssa1.py:142)], incoming_blocks=[48, 98, 76, 84]) ['invert', 'invert', 'invert', 'invert.1', 'invert.2']
    exp.3 = phi(incoming_values=[Var(exp, debug_ssa1.py:143), Var(exp.1, debug_ssa1.py:156), Var(exp, debug_ssa1.py:143), Var(exp, debug_ssa1.py:143)], incoming_blocks=[48, 98, 76, 84]) ['exp', 'exp', 'exp', 'exp.1', 'exp.3']
```
which seems a bit strange.
user: stuartarchibald
labels: SSA: Problem due to SSA (or lack of)
issue_7300: state: open
title: Regular expressions doesn't match on nested function
body: In my project I use `get_airconditioner_type(foo)` to get some specif values by parsing the description column of a `pandas.DataFrame`. Inside such function I define a nested function with some regular expression definitions.

Happens that the nested function return different value: `"split"` when `@jit` is not actived and `None` when active, causing a wrong `return 'UNDENTIFIED_TYPE'` at last scenario.

The two `print` inside `get_airconditioner_type` return equal in the without `@jit` and different within.

The example bellow resume the approach and reproduce the error.

```python
from numba import jit
import pandas as pd
import re

@jit
def get_airconditioner_type(row: pd.DataFrame,
                            column_search: str = 'Descrição') -> str:

    def ismatch_type(pattern: str) -> re.Match:
        match = re.search(pattern, row[column_search], re.IGNORECASE)
        return match

    print('1 -->', re.search(r'(sp*lit*)', row[column_search], re.IGNORECASE)) # Always OK!
    print('2 -->', ismatch_type(r'(sp*lit*)')) # Only works without @jit

    if ismatch_type(r'(sp*lit*)'):
        return 'split'
    return 'UNDENTIFIED_TYPE'


data = {
'Área de Patrimônio': ['caism'],
'Tipo': ['split'],
'Descrição': ['CONDICIONADOR DE AR BI SPLIT CARRIER HW 2X18000 BTU\H 220']
}
database = pd.DataFrame.from_dict(data)

for idx, db_row in database.iterrows():
    result = get_airconditioner_type(db_row)
    print(result)

```

Using numba commited after https://github.com/numba/numba/pull/7272 (quite recent).
user: hildogjr
labels: bug - miscompile: Bugs: miscompile
issue_7293: state: open
title: The `|=` operator (`set.__ior__`) causes errors when used instead of `set.update`
body: I discovered this bug with the following function:

```python
import numpy as np
from numba import njit


@njit
def inverse_collatz_func(n: int, limit: int = None) -> set[int]:
    results = set()
    if n % 2 == 0 and (n - 1) % 3 == 0:
        results.add((n - 1) // 3)
    if limit is not None and 2 * n <= limit:
        results.add(2 * n)
    return results


@njit
def inverse_collatz_coordinates(number: int, limit: int = None) -> tuple[np.ndarray, np.ndarray]:
    """Construct an inverse-Collatz graph as a pair of x,y coordinate arrays that are plottable with matplotlib"""
    x = [(0, 1)]
    y = [(1, 2)]
    u_set = inverse_collatz_func(1, limit)
    for i in range(1, number):
        v_set = set()
        for u in u_set:
            inverse_collatz_results = inverse_collatz_func(u, limit)
            x += [(i, i + 1)] * len(inverse_collatz_results)
            y += [(u, v) for v in inverse_collatz_results]
            v_set.update(inverse_collatz_results)
        u_set = v_set
    x = np.array(x).T
    y = np.array(y).T
    return x, y
```

I had to wrestle with the fifth-to-last line of code for quite some time to get Numba to accept it. As it turns out, replacing that line with `v_set |= inverse_collatz_results` breaks the compilation, throwing the error `Cannot infer the type of variable 'u_set.1', have imprecise type: set(undefined).` I can't remember exactly what I did to get it to mention `IOR`, but it is apparent that Numba doesn't expect it to possess the signature `(set, set)`.
user: QuaternionsRock
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7290: state: open
title: global flag to default all numpy / numba calculations to be on float32 
body: Hi.  Is there a way to compile numba code and force all floats to be float32 precision as opposed to double globally?
This makes a big difference for programs that require a lot of memory copying - like updating arrays multiple times and where precision matters less. 

The reason the global flag is useful is because its very clunky to declare all types in python to be float32
user: dao72
labels: discussion: An issue requiring discussion
issue_7289: state: open
title: Implement np.tensordot()
body: Implementing in the hopes I can use it as basis for `np.einsum`, but seems useful on its own too.

The code was copy/pasted from NumPy and updated; this relies on #7202 for the NumPy licensing compliance, but the appropriate changes could be done here instead.

My main concern is that this isn't well enough tested, so suggestions for more tests would be appreciated.
user: itamarst
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - long: Long size effort needed
issue_7281: state: open
title: readthedocs builds of stable are failing
body: https://readthedocs.org/projects/numba/builds/

I don't know how long it has been failing. It seems the [changelog page](https://numba.readthedocs.io/en/stable/release-notes.html) is reporting version 0.53.1 as the last version, where [the changelog on latest](https://numba.readthedocs.io/en/stable/release-notes.html) shows 0.54.0

The stable docs [build failed](https://readthedocs.org/projects/numba/builds/14401764/) seems pinned to 0.53.1: `git checkout --force 97fe221b3704bd17567b57ea47f4fc6604476cf9`, is this a readthedocs config issue?
user: mattip
issue_7279: state: open
title: Errors of Ingest in scanpy which is caused by Numba.
body: orry to disturb, but it seems that the ingest method in scanpy meets some problems caused by pynndescent and numba. Here are the details:
KeyError Traceback (most recent call last)
/usr/local/lib/python3.7/dist-packages/numba/core/caching.py in save(self, key, data)
486 # If key already exists, we will overwrite the file
--> 487 data_name = overloads[key]
488 except KeyError:

KeyError: ((array(int32, 1d, C), array(int32, 1d, C), array(float32, 1d, C), array(float32, 2d, C), type(CPUDispatcher(<function squared_euclidean at 0x7fdefdb13830>)), array(int64, 1d, C), float64), ('x86_64-unknown-linux-gnu', 'broadwell', '+64bit,+adx,+aes,+avx,+avx2,-avx512bf16,-avx512bitalg,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vbmi2,-avx512vl,-avx512vnni,-avx512vpopcntdq,+bmi,+bmi2,-cldemote,-clflushopt,-clwb,-clzero,+cmov,+cx16,+cx8,-enqcmd,+f16c,+fma,-fma4,+fsgsbase,+fxsr,-gfni,+invpcid,-lwp,+lzcnt,+mmx,+movbe,-movdir64b,-movdiri,-mwaitx,+pclmul,-pconfig,-pku,+popcnt,-prefetchwt1,+prfchw,-ptwrite,-rdpid,+rdrnd,+rdseed,+rtm,+sahf,-sgx,-sha,-shstk,+sse,+sse2,+sse3,+sse4.1,+sse4.2,-sse4a,+ssse3,-tbm,-vaes,-vpclmulqdq,-waitpkg,-wbnoinvd,-xop,+xsave,-xsavec,+xsaveopt,-xsaves'), ('308c49885ad3c35a475c360e21af1359caa88c78eb495fa0f5e8c6676ae5019e', 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'))

During handling of the above exception, another exception occurred:

TypeError Traceback (most recent call last)
13 frames
in ()
----> 1 sc.tl.ingest(adata, adata_ref, obs='louvain') #ingest

/usr/local/lib/python3.7/dist-packages/scanpy/tools/_ingest.py in ingest(adata, adata_ref, obs, embedding_method, labeling_method, neighbors_key, inplace, **kwargs)
131
132 if obs is not None:
--> 133 ing.neighbors(**kwargs)
134 for i, col in enumerate(obs):
135 ing.map_labels(col, labeling_method[i])

/usr/local/lib/python3.7/dist-packages/scanpy/tools/_ingest.py in neighbors(self, k, queue_size, epsilon, random_state)
469 self._nnd_idx.search_rng_state = rng_state
470
--> 471 self._indices, self._distances = self._nnd_idx.query(test, k, epsilon)
472
473 else:

/usr/local/lib/python3.7/dist-packages/pynndescent/pynndescent_.py in query(self, query_data, k, epsilon)
1564 """
1565 if not hasattr(self, "_search_graph"):
-> 1566 self._init_search_graph()
1567
1568 if not self._is_sparse:

/usr/local/lib/python3.7/dist-packages/pynndescent/pynndescent_.py in _init_search_graph(self)
1061 self._distance_func,
1062 self.rng_state,
-> 1063 self.diversify_prob,
1064 )
1065 reverse_graph.eliminate_zeros()

/usr/local/lib/python3.7/dist-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
432 e.patch_message('\n'.join((str(e).rstrip(), help_msg)))
433 # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 434 raise e
435
436 def inspect_llvm(self, signature=None):

/usr/local/lib/python3.7/dist-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
365 argtypes.append(self.typeof_pyval(a))
366 try:
--> 367 return self.compile(tuple(argtypes))
368 except errors.ForceLiteralArg as e:
369 # Received request for compiler re-entry with the list of arguments

/usr/local/lib/python3.7/dist-packages/numba/core/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
30 def _acquire_compile_lock(*args, **kwargs):
31 with self:
---> 32 return func(*args, **kwargs)
33 return _acquire_compile_lock
34

/usr/local/lib/python3.7/dist-packages/numba/core/dispatcher.py in compile(self, sig)
823 raise e.bind_fold_arguments(folded)
824 self.add_overload(cres)
--> 825 self._cache.save_overload(sig, cres)
826 return cres.entry_point
827

/usr/local/lib/python3.7/dist-packages/numba/core/caching.py in save_overload(self, sig, data)
669 """
670 with self._guard_against_spurious_io_errors():
--> 671 self._save_overload(sig, data)
672
673 def _save_overload(self, sig, data):

/usr/local/lib/python3.7/dist-packages/numba/core/caching.py in _save_overload(self, sig, data)
679 key = self._index_key(sig, _get_codegen(data))
680 data = self._impl.reduce(data)
--> 681 self._cache_file.save(key, data)
682
683 @contextlib.contextmanager

/usr/local/lib/python3.7/dist-packages/numba/core/caching.py in save(self, key, data)
494 break
495 overloads[key] = data_name
--> 496 self._save_index(overloads)
497 self._save_data(data_name, data)
498

/usr/local/lib/python3.7/dist-packages/numba/core/caching.py in _save_index(self, overloads)
540 def _save_index(self, overloads):
541 data = self._source_stamp, overloads
--> 542 data = self._dump(data)
543 with self._open_for_write(self._index_path) as f:
544 pickle.dump(self._version, f, protocol=-1)

/usr/local/lib/python3.7/dist-packages/numba/core/caching.py in _dump(self, obj)
568
569 def _dump(self, obj):
--> 570 return pickle.dumps(obj, protocol=-1)
571
572 @contextlib.contextmanager

TypeError: can't pickle weakref objects

How to solve this problem? Thanks.
The code comes from :https://scanpy-tutorials.readthedocs.io/en/latest/integrating-data-using-ingest.html
user: HelloWorldLTY
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_7268: state: open
title: Running `jit_module` on an existing module? (And document calling `jit(...)(func)` manually)
body: ## Feature request

I have an extremely simple library on my hands that I want to try `numba` with, but to me it does not really make sense to add a dependency to it (it has zero right now). I figured that it might be a good idea to allow users to manually `jit` a module object they have imported, along the lines of:

```py
import numba
import module as _module
module = numba.jit_module(module)
```

A similar case is the use of `@jit` outside of a decorator context, so an un-jitted-at-definition-time function gets JITed. This is already possible due to the way Python's decorator works, but IMO it would help to put them in examples:

```py
from numba import jit
from module import some_cool_func
potentially_cooler_func = jit(some_cool_func)
```

(Huh, I like how `jit`'s docstring doesn't actually occur in the online manual...)
user: Artoria2e5
issue_7264: state: open
title: StrEnum comparison is incorrect inside jit or njit wrapped functions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
I am currently on numba 0.54.0rc2 and python 3.9.5 and a `StrEnum` comparison doesn't work as expected.
```python
from numba import jit, njit
from enum import Enum


class RGB(str, Enum):
    Red = 'red'
    Green = 'green'
    Blue = 'blue'

@njit
def njit_compare(rgb):
    return rgb == RGB.Red

@jit
def jit_compare(rgb):
    return rgb == RGB.Red

def vanilla_compare(rgb):
    return rgb == RGB.Red


def main():
    red = RGB.Red
    res1 = njit_compare(red)
    res2 = jit_compare(red)
    res3 = vanilla_compare(red)
    print(res1, res2, res3)


if __name__ == "__main__":
    main()
```
gives an output of `False False True`.


user: mcreng
labels: bug - miscompile: Bugs: miscompile
issue_7259: state: open
title: More efficient np.zeros
body: At the moment, Numba is not as efficient as Numpy in creating arrays with `np.zeros`. The difference is quite large even for medium-sized arrays (the example below should use about 230MB).
Here's a small reproducer:

```python
import numpy as np
from numba import njit

@njit
def alloc():
    a = np.zeros((480 - 1 + 2, 250+250**2), np.float64)
    return a

alloc()
%timeit alloc()
%timeit alloc.py_func()
160 ms ± 9.41 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
4.83 ms ± 212 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
```

user: luk-f-a
labels: performance - run time: Performance issue occurring at run time.
issue_7248: state: open
title: [FEATURE REQUEST] Crash when no permissions to access cache directory
body: Directly linked to: #4032 (closed by author due to existing workaround)

While working inside a Docker container, I ran into a situation where the active user had no permission to access the cache directories numba was trying to use. This resulted in a `RuntimeError` being thrown upon importing a module with jit-decortated functions.

There is a workaround by explicitly supplying a writeable directory to numba via the `NUMBA_CACHE_DIR` environment variable.

However, I was wondering if it were a good idea to throw a warning to the user instead and either disable caching entirely or add a new CacheLocator which creates a temporary caching directory using `tempfile.mkdtemp` for the active session. The `mkdtemp` option would delegate the task of creating a writable directory to the standard library and should succeed in the vast majority of cases.

I imagine that others might run into this when they try to use numba accelerated libraries inside of containers which are executed with limited privileges. (This issue is of course not limited to containers, but it feels like there is a lot of root / non-root hassle surrounding Docker :-P)

Cheers!
user: HPLegion
issue_7246: state: open
title: Slow prange/bad parallelization
body: Bug: `prange` does not lead to good parallelization.
The following example runs an expensive function 100 times.
* The serial implementation takes **0.39 seconds**.
* A parallelized implementation with `multiprocessing.pool.ThreadPool` takes **0.068 seconds**.
* A parallelized implementation with `prange` takes **0.23 seconds**. This is much worse than the ThreadPool implementation. Windows Task Manager shows 100% utilization on all 8 cores, so some kind of parallelization is happening. It just isn't working very well.

### Self-contained example

```python
import time
import numpy as np
from multiprocessing.pool import ThreadPool
from numba import njit, prange

pool = ThreadPool()

# This is an expensive function that will be called many times in parallel.
# It is purely CPU-bound, so it should parallelize well.
@njit(cache=True, nogil=True)
def i_am_expensive(x, n):
    for _ in range(n):
        x = (x * 16553 + 27077) % 31849
    return x

# Baseline with multiprocessing.pool.ThreadPool, which parallelizes well.
def call_expensive_function_many_times_threadpool(m, n):
    params = [(x, n) for x in np.arange(m)]
    return sum(pool.starmap(i_am_expensive, params))

# Calling function in parallel with prange. This does not parallelize well.
@njit(cache=True, parallel=True, nogil=True)
def call_expensive_function_many_times_prange(m, n):
    results = np.arange(m)
    for i in prange(m):
        results[i] = i_am_expensive(i, n)
    return results.sum()

# Calling function without any parallelism.
def call_expensive_function_not_parallel(m, n):
    return sum(i_am_expensive(x, n) for x in np.arange(m))

# For all possible functions, run benchmark
for call_expensive_function_many_times in [
    call_expensive_function_many_times_threadpool,
    call_expensive_function_many_times_prange,
    call_expensive_function_not_parallel,
]:
    print(call_expensive_function_many_times.__name__)

    # Compile and warmup JIT
    for _ in range(5):
        call_expensive_function_many_times(100, 1000)

    # Run test 10 times to see if it was a fluke
    for _ in range(10):
        # Run function and measure time
        start_time = time.perf_counter()
        result = call_expensive_function_many_times(100, 1000_000)
        elapsed_time = time.perf_counter() - start_time

        # Print results
        print(f"{elapsed_time:.3f} seconds - result: {result}")
    print()
```

### Timing results

```
call_expensive_function_many_times_threadpool
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287
0.068 seconds - result: 1571287

call_expensive_function_many_times_prange
0.253 seconds - result: 1571287
0.235 seconds - result: 1571287
0.230 seconds - result: 1571287
0.230 seconds - result: 1571287
0.246 seconds - result: 1571287
0.234 seconds - result: 1571287
0.232 seconds - result: 1571287
0.234 seconds - result: 1571287
0.251 seconds - result: 1571287
0.234 seconds - result: 1571287

call_expensive_function_not_parallel
0.389 seconds - result: 1571287
0.396 seconds - result: 1571287
0.402 seconds - result: 1571287
0.396 seconds - result: 1571287
0.390 seconds - result: 1571287
0.392 seconds - result: 1571287
0.392 seconds - result: 1571287
0.386 seconds - result: 1571287
0.398 seconds - result: 1571287
0.391 seconds - result: 1571287
```

Note: The runtime for the `prange` implementation rise to over 0.88 seconds (**slower than the serial implementation!**) when run in WSL2 or docker. The runtime of the other implementations stay the same.

### Environment

- Numba version: 0.53.1
- Operating system: Windows 10
- Python version: 3.9.1

### Reproducibility

@HPLegion also observes bad parallelization performance: https://gitter.im/numba/numba?at=60fbc6b1c9f8852a9705704f 
user: 99991
labels: performance: performance related issue
performance - run time: Performance issue occurring at run time.
issue_7245: state: open
title: [Feature Request] "Iteration" over empty tuple
body: Hi,

Currently trying to iterate over an empty tuple raises a typing error. Luckily there is a workaround (see below) so this is not entirely a deal breaker. But maybe it would be possible to generate some kind of generic empty iterator (or prune the loop entirely) such that no error is raised? (I hope I am not overlooking some weird consequences that could have)

EDIT: I just noticed that the workaround breaks if the empty tuple is nested inside another tuple (I guess that this is due to how the branch pruning works). This slightly raises the importance of tackling this issue.

Cheers

PS: Somewhere in the back of my mind I feel like I may have adressed this before, but I cannot seem to find an issue, sorry if this is a duplicate :-)

### Reproducer
```python 
from numba import njit

@njit
def f_guarded(x):
    if len(x)>0:
        for c in x:
            pass

@njit
def f_unguarded(x):
    for c in x:
        pass

@njit
def f_guarded_nested(x):
    if len(x[0])>0:
        for c in x[0]:
            pass

cases = {
    "Guarded iterator with filled tuple": lambda: f_guarded((1,2,3)),
    "Guarded iterator with empty tuple": lambda: f_guarded(tuple()),
    "Unguarded iterator with filled tuple": lambda: f_unguarded((1,2,3)),
    "Unguarded iterator with empty tuple": lambda: f_unguarded(tuple()),
    "Guarded iterator with nested empty tuple": lambda: f_guarded_nested( ((),) )
}

for desc, c in cases.items():
    try:
        c()
        print(desc + ": success")
    except Exception as e:
        print(desc + ": failed")
        print(e)
    print()
```
### Output
```
Guarded iterator with filled tuple: success

Guarded iterator with empty tuple: success

Unguarded iterator with filled tuple: success

Unguarded iterator with empty tuple: failed
Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of getiter with parameters (Tuple())

During: typing of intrinsic-call at bugs/iter_empty_tuple.py (12)

File "bugs/iter_empty_tuple.py", line 12:
def f_unguarded(x):
    for c in x:
    ^


Guarded iterator with nested empty tuple: failed
Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of getiter with parameters (Tuple())

During: typing of intrinsic-call at bugs/iter_empty_tuple.py (18)

File "bugs/iter_empty_tuple.py", line 18:
def f_guarded_nested(x):
    <source elided>
    if len(x[0])>0:
        for c in x[0]:
        ^
```
user: HPLegion
issue_7225: state: open
title: Renamed variable names may not be unique
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest ~released~ 0.54rc2 release candidate version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Using 0.54.0rc2 for one of Bodo's tests causes a typing failure, since some renamed variable names end up being the same in a function (but with different data types). It happens when some function is inlined multiple times (in the same outer function), but with different input types. Creating a reproducer is not easy for this unfortunately.

There is probably some issue with variable scopes in inlining, but making renamed variables globally unique can prevent similar problems in general. Is there a problem with using `ir_utils.next_label()` here instead of starting the counter from one for each variable?https://github.com/numba/numba/blob/d0ca288f24eccff3ba1f86e38f0de07a717f8d4c/numba/core/ir.py#L1142

I have a workaround for this case so this is not a blocker, but I think making renamed variables unique can improve robustness.

user: ehsantn
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7215: state: open
title: incorrect result on Python 3.7
body: [Kats](https://github.com/facebookresearch/Kats) ran into a bug with Numba `@jit` (Numba version 0.53.1). This bug doesn't happen on Python 3.8(.3) or Python 3.9(.6), but does happen on Python 3.7.5. I reduced it to the following:

```python
from typing import Dict
from numba import jit

@jit(forceobj=True)
def broken(f: Dict[str, float], x: Dict[str, bool]) -> Dict[str, float]:
    result = {}
    for k, v in f.items():
        if x.get(k, True):
            result[k] = v
    return result

if __name__ == "__main__":
    print(broken({"one": 1, "two": 2, "three": 3}, {"two": False}))
```

Expected: `{'one': 1, 'three': 3}`

Actual (on Python 3.7): `{'one': 1}`

Adding additional logging shows that on Python 3.7, only the first entry in `f` is processed.  If the inner `if x.get(k, True)` check is removed, all Python versions produce the same result.

user: michaelbrundage
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7213: state: open
title: parfors lowering error from missing entry in varmap
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import jit, prange
import numpy as np

@jit(nopython=True, parallel=True)
def foo():
    a = np.empty((2,))
    for k in prange(2):
        b = np.arange(1)
        c = np.zeros((n, n), dtype=np.complex128)
        d = np.expand_dims(b, -1) * c
        e = np.diag(global_arr @ d)
        a[k] = 1
    return a

n = 5
global_arr = np.ones((n, n)).astype(np.complex128)
foo()
```
does this:
```numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
Failed in nopython mode pipeline (step: native lowering)
'$push_global_to_block.300'

File "di85.py", line 9:
def foo():
    <source elided>
        b = np.arange(1)
        c = np.zeros((n, n), dtype=np.complex128)
        ^
```

This is from reduced input as reported here: https://numba.discourse.group/t/jit-decorated-function-fails-compiling-with-parallel-true/793
user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7188: state: open
title: CUDA: `cuda.cudadrv.libs.detect()` doesn't give the location of libcuda.so
body: In many instances, getting CUDA errors with Numba when other CUDA apps work can be caused by Numba picking up a wrong / inappropriate libcuda.so (see e.g. #7187 #7104) - it would be helpful if `cuda.cudadrv.libs.detect()` gave the location of this library to aid in troubleshooting.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_7183: state: open
title: error_model target option not working with cfunc (and maybe other target options?)
body: The following:

```python
from numba import cfunc, njit

rec_cfunc = cfunc('double(double)', nopython=True, error_model='numpy')(lambda x:  1.0 / x)
rec_njit = njit('f8(f8,)', fastmath=True, error_model='numpy')(lambda x: 1.0 / x)

print(rec_njit(0.0))
print(rec_cfunc(0.0))
```

results in:

```
$ python repro.py 
inf
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/vlovero/repro.py", line 8, in <module>
    print(rec_cfunc(0.0))
  File "/home/gmarkall/numbadev/numba/numba/core/ccallback.py", line 134, in __call__
    return self._pyfunc(*args, **kwargs)
  File "/home/gmarkall/numbadev/issues/vlovero/repro.py", line 4, in <lambda>
    rec_cfunc = cfunc('double(double)', nopython
```

It looks from inspection of the implementation (`cfunc`, `_CFuncCompiler`, `_FunctionCompiler`, etc.) that target options should be passed through as they are with `njit` (I didn't look too deeply though), but `error_model` seems to ultimately have no effect with the `cfunc` decorator - it may be that target options aren't working in general?
user: gmarkall
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7179: state: open
title: Support jit decorator flags in cc.export (e.g. fastmath) 
body: From #5664:

> Adding the possibility of using `@njit` flags in `@cc.export` would be great! Is it possible?

and:

> I have managed to add the 'fastmath' flag to the `ExportEntry` object:
> 
> ```
> class ExportEntry(object):
>     """
>     A simple record for exporting symbols.
>     """
> 
>     def __init__(self, symbol, signature, function, fastmath=False):
>         self.symbol = symbol
>         self.signature = signature
>         self.function = function
>         self.fastmath = fastmath
> ```
> 
> Then, the `_cull_exports` methodof the `_ModuleCompiler` object shall me modified with the following code:
> 
> ```
> for entry in self.export_entries:
>             flags_aux = flags.copy()
>             if entry.fastmath:
>                 flags_aux.set('fastmath', value=cpu.FastMathOptions(True))
> 
>             cres = compile_extra(self.typing_context, self.context,
>                                  entry.function,
>                                  entry.signature.args,
>                                  entry.signature.return_type, flags_aux,
>                                  locals={}, library=library)
> ```
> 
> With this modifications, I am able to use the `@cc.export` decorator like this:
> 
> `@cc.export('foo', 'float64(float64[::1], float64[::1])', fastmath=True)`
> 
> And it is working for me right now. I guess this code may be improved, but this simple patch works, so I would expect that 'fastmath' and 'parallel' flags could be added to `@cc.export` in an "official" way.

The above could be worked up into a patch with tests added to complete the feature imp[lementation.
user: gmarkall
labels: good first issue: A good issue for a first time contributor
AOT: ahead of time compilation issue
issue_7174: state: open
title: operator.eq with Bytes selects Numpy_rules_ufunc template's signature
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I tried checking equality on two bytes types and get the folllowing error.

```python
import numba
@numba.njit
def test(lhs, rhs):
    return lhs == rhs
print(test(b'hello', b'124223'))
```

```python
Traceback (most recent call last):
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typeinfer.py", line 154, in propagate
    constraint(typeinfer)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typeinfer.py", line 190, in __call__
    typeinfer.copy_type(self.src, self.dst, loc=self.loc)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typeinfer.py", line 1095, in copy_type
    self.typevars[dest_var].union(self.typevars[src_var], loc=loc)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typeinfer.py", line 106, in union
    self.add_type(other.type, loc=loc)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typeinfer.py", line 61, in add_type
    raise TypingError(msg % (tp, self.type, self.var,
numba.core.errors.TypingError: No conversion from array(bool, 1d, C) to bool for '$8return_value.3', defined at None

File "temp_test.py", line 1:
import numba
^

During: typing of assignment at temp_test.py (1)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "temp_test.py", line 8, in <module>
    print(test(b'hello', b"124223"))
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 482, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 421, in error_rewrite
    raise e
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 434, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 979, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 145, in compile
    raise retval
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 155, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/dispatcher.py", line 168, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 686, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 492, in _compile_bytecode
    return self._compile_core()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typed_passes.py", line 396, in run_pass
    lower.lower()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 138, in lower
    self.lower_normal_function(self.fndesc)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 192, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 221, in lower_function_body
    self.lower_block(block)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 235, in lower_block
    self.lower_inst(inst)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 373, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 549, in lower_assign
    return self.lower_expr(ty, value)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/lowering.py", line 1283, in lower_expr
    res = self.context.special_ops[expr.op](self, expr)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/np/ufunc/array_exprs.py", line 384, in _lower_array_expr
    cres = context.compile_subroutine(builder, impl, inner_sig, flags=flags,
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/base.py", line 875, in compile_subroutine
    cres = self._compile_subroutine_no_cache(builder, impl, sig,
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/base.py", line 846, in _compile_subroutine_no_cache
    cres = compiler.compile_internal(self.typing_context, self,
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 760, in compile_internal
    return pipeline.compile_extra(func)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 428, in compile_extra
    return self._compile_bytecode()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 492, in _compile_bytecode
    return self._compile_core()
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 471, in _compile_core
    raise e
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler.py", line 462, in _compile_core
    pm.run(self.state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typed_passes.py", line 105, in run_pass
    typemap, return_type, calltypes, errs = type_inference_stage(
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typed_passes.py", line 83, in type_inference_stage
    errs = infer.propagate(raise_errors=raise_errors)
  File "/Users/nicholasriasanovsky/Documents/bodo/nick-numba/numba/core/typeinfer.py", line 1074, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: native lowering)
Failed in nopython mode pipeline (step: nopython frontend)
No conversion from array(bool, 1d, C) to bool for '$8return_value.3', defined at None

File "temp_test.py", line 1:
import numba
^

During: typing of assignment at temp_test.py (1)

File "temp_test.py", line 1:
import numba
^

During: lowering "$6compare_op.2 = arrayexpr(expr=(<built-in function eq>, [Var(lhs, temp_test.py:5), Var(rhs, temp_test.py:5)]), ty=array(bool, 1d, C))" at temp_test.py (5)
```



This isn't suprising because `operator.eq` doesn't appear to be implemented for bytes. However, what is surprising is that it matches a signature with output `types.Array(bool, 1, "C")`. This appears to happen because bytes is a subclass of ArrayCompatable, so the Numpy_rules_ufunc template matches.

I've tried to provide an overload for eq, but I can't seem to get Numba to select it (maybe because the return types don't match).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: njriasan
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7169: state: open
title: CUDA: `debug=True` conflates checking for exceptions and generating debug info
body: From the docstring of the `cuda.jit` decorator:

> **debug**: If `True`, check for exceptions thrown when executing the kernel. Since this degrades performance, this should only be used for debugging purposes. Defaults to `False`. (The default value can be overridden by setting environment variable `NUMBA_CUDA_DEBUGINFO=1`.)

This also enables the generation of debug information. Ideally there should be two separate flags, one for debuginfo, and one for checking for exceptions. Perhaps:

- `debuginfo`: Set to `True` to enable debug info generation.
- `exception_check`: Set to `True` to enable exception checking.

with `debug=True` implying that both of the above are `True` - this will provide consistent behavior with existing versions of Numba as well as providing more fine-grained control over debugging functionality.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7168: state: open
title: Impact of flags in function selection/recompilation
body: Discussion: Impact of flags in function selection/recompilation.

This:
```python
from numba import njit
import numpy as np

@njit
def foo(a, b):
    return a + b

@njit
def caller(a, b):
    return foo(a, b)

@njit(fastmath=True)
def fast_caller(a, b):
    return foo(a, b)

@njit
def main(a, b):
    # SWAP THE ORDER OF THESE CALLS AND RERUN TO SEE THE EFFECT
    x = caller(a, b)
    y = fast_caller(a, b)
    return x, y

print(main(10., 20.))
print(main.inspect_llvm(main.signatures[0]))
```
produces a `fadd double %arg.b, %arg.a` or a `fadd fast double %arg.b, %arg.a` for `foo` that gets inlined into `main` depending on the order of the calling functions.

The flags are propagating from the caller to the callee, but not impacting function selection and potentially triggering recompilation for new variants based on flags. To do this I think typing has to be made aware of the flags, probably by them being part of a function signature, and then this would trigger a recompilation if there's no match. In the above example, were typing aware of the flags for the different calls to `foo`, two variants would be generated, one fast and one normal, and this would be reflected in the LLVM IR.

Discussion points:
1. Performance impact on compile and runtime.
2. Difficulty of implementation.
3. Is this desirable behaviour!?
4. Something else.
user: stuartarchibald
labels: bug - miscompile: Bugs: miscompile
issue_7167: state: open
title: Make aliasing work for tuple (re)construction.
body: Resolves #7135 

Previously, aliasing only worked when extracting something from a tuple.  In issue 7135, a tuple is passed to a parfor and because it is a tuple, we extract the individual parts and reconstruct the tuple within the gufunc since tuples can't be passed explicitly to gufuncs.  When the tuple is reconstructed, we need the elements that go into the tuple to alias with the tuple so that when elements are subsequently extracted that everything aliases and so the original arguments are known to be live and so that liveness propagates to the tuple and then elements extracted from it.  In short, this PR stops dead code removal from thinking that writes into parts of a reconstructed tuple are dead.
user: DrTodd13
labels: Effort - medium: Medium size effort needed
issue_7166: state: open
title: LoweringError with tuple_setitem and slice
body: The reproducer:

```python
from numba import njit
from numba.cpython.unsafe.tuple import tuple_setitem


@njit
def settuple(t):
    new_t = tuple_setitem(t, 0, t[1])
    return tuple_setitem(new_t, 1, t[0])


t = (0, slice(None, None, None))
print(settuple(t))
```

fails with a `LoweringError` with the following traceback:

```
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/numba/numba/core/base.py", line 710, in cast
    impl = self._casts.find((fromty, toty))
  File "/home/gmarkall/numbadev/numba/numba/core/base.py", line 48, in find
    out = self._find(sig)
  File "/home/gmarkall/numbadev/numba/numba/core/base.py", line 57, in _find
    raise NotImplementedError(self, sig)
NotImplementedError: (<numba.core.base.OverloadSelector object at 0x7f54542962b0>, (slice<a:b>, Union[int64,slice<a:b>]))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/gmarkall/numbadev/numba/numba/core/errors.py", line 755, in new_error_context
    yield
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 231, in lower_block
    self.lower_inst(inst)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 361, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 537, in lower_assign
    return self.lower_expr(ty, value)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 1065, in lower_expr
    res = self.lower_call(resty, expr)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 796, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 1018, in _lower_call_normal
    argvals = self.fold_call_args(
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 735, in fold_call_args
    argvals = typing.fold_arguments(pysig,
  File "/home/gmarkall/numbadev/numba/numba/core/typing/templates.py", line 243, in fold_arguments
    ba.arguments[name] = normal_handler(i, param, ba.arguments[name])
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 722, in normal_handler
    return self._cast_var(var, signature.args[index])
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 701, in _cast_var
    return self.context.cast(self.builder, val, varty, ty)
  File "/home/gmarkall/numbadev/numba/numba/core/base.py", line 713, in cast
    raise NotImplementedError(
NotImplementedError: Cannot cast slice<a:b> to Union[int64,slice<a:b>]: %".8" = extractvalue {i64, {i64, i64, i64}} %"inserted.f1", 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "repro.py", line 12, in <module>
    print(settuple(t))
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 501, in _compile_for_args
    raise e
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 434, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 979, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 141, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 155, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/gmarkall/numbadev/numba/numba/core/dispatcher.py", line 168, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 682, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 426, in compile_extra
    return self._compile_bytecode()
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 490, in _compile_bytecode
    return self._compile_core()
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 469, in _compile_core
    raise e
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 460, in _compile_core
    pm.run(self.state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/gmarkall/numbadev/numba/numba/core/typed_passes.py", line 396, in run_pass
    lower.lower()
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 137, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 191, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 217, in lower_function_body
    self.lower_block(block)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 231, in lower_block
    self.lower_inst(inst)
  File "/home/gmarkall/miniconda3/envs/numbacuda102/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/gmarkall/numbadev/numba/numba/core/errors.py", line 765, in new_error_context
    raise newerr.with_traceback(tb)
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
Cannot cast slice<a:b> to Union[int64,slice<a:b>]: %".8" = extractvalue {i64, {i64, i64, i64}} %"inserted.f1", 1

File "repro.py", line 7:
def settuple(t):
    new_t = tuple_setitem(t, 0, t[1])
    ^

During: lowering "new_t = call $2load_global.0(t, $const6.2, $12binary_subscr.5, func=$2load_global.0, args=[Var(t, repro.py:7), Var($const6.2, repro.py:7), Var($12binary_subscr.5, repro.py:7)], kws=(), vararg=None, target=None)" at repro.py (7)
```
user: gmarkall
labels: bug - ice: Bugs: internal compiler error
issue_7135: state: open
title: Miscompiled parallel access to namedtuple
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

If I access an array in a parallel loop through a namedtuple, writes have no effect:

```python
import numpy as np
import numba
from collections import namedtuple

@numba.njit(parallel=True)
def foo(dat):
    n, = dat.x.shape
    for i in numba.prange(n):
        dat.x[i] = -1

x = np.ones(10)
Data = namedtuple("Data", ["x"])
dat = Data(x)

foo(dat)
dat
```
This should show an array with all values equal -1, but it is still filled with 1.

This does not happen if we access the namedtuple as a tuple, disable parallelization or move the array access into a non-inlined function:

```python
# works fine
@numba.njit(parallel=True)
def foo1(dat):
    n, = dat.x.shape

    x = dat.x
    for i in numba.prange(n):
        x[i] = -1


# works fine
@numba.njit(parallel=True)
def foo2(dat):
    n, = dat[0].shape

    for i in numba.prange(n):
        dat[0][i] = -1


@numba.njit(inline='never')
def bar(dat, i):
    dat.x[i] = -1


# works fine
def foo3(dat):
    n, = dat[0].shape
    
    for i in numba.prange(n):
        bar(dat, i)
```
user: aseyboldt
labels: bug - miscompile: Bugs: miscompile
issue_7124: state: open
title: Float Literal Support
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request Float Literal Type
I'd like to see support for a Float Literal type, similar to the Integer Literal and Boolean Literal types that currently exist.
The main motivations for this use case would be to situations where users provide floats to APIs that require constants for typings (and in practice accept integers or floats) or to support the option to avoid runtime checks for common cases with users tend to provide literals (i.e. numpy.quantile https://numpy.org/doc/stable/reference/generated/numpy.quantile.html).

I'm happy to provide this feature in a PR myself.
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: njriasan
issue_7117: state: open
title: NUMBA_DISABLE_JIT causes an infinite loop in Structref instance creation.
body: ```
import os
os.environ['NUMBA_DISABLE_JIT'] = '1'

import numba
import numpy as np
from numba import njit
from numba.core import types
from numba.experimental import structref

@structref.register
class ValueType(types.StructRef):
    def preprocess_fields(self, fields):
        return tuple((name, types.unliteral(typ)) for name, typ in fields)
class Value(structref.StructRefProxy):
    def __new__(cls, val):
        return structref.StructRefProxy.__new__(cls, val)
    @property
    def val(self):
        return Value_get_val(self)
@njit
def Value_get_val(self):
    return self.val
structref.define_proxy(Value, ValueType, ["val"])
@njit
def div_by_zero(node):
    return node.val / 0
node1 = Value(54321)
div_by_zero(node1)
```

```
---------------------------------------------------------------------------
RecursionError                            Traceback (most recent call last)
structref_mini_test.py in 
     35     return node.val / 0
     36 
---> 37 node1 = Value(54321)
     38 
     39 div_by_zero(node1)
structref_mini_test.py in __new__(cls, val)
     18 class Value(structref.StructRefProxy):
     19     def __new__(cls, val):
---> 20         return structref.StructRefProxy.__new__(cls, val)
     21 
     22     @property
~/anaconda3/envs/py38/lib/python3.8/site-packages/numba/experimental/structref.py in __new__(cls, *args)
    374             # cache it to attribute to avoid recompilation
    375             cls.__numba_ctor = ctor
--> 376         return ctor(*args)
    377 
    378     @property
~/anaconda3/envs/py38/lib/python3.8/site-packages/numba/experimental/structref.py in ctor(*args)
    371             @njit
    372             def ctor(*args):
--> 373                 return cls(*args)
    374             # cache it to attribute to avoid recompilation
    375             cls.__numba_ctor = ctor
... last 3 frames repeated, from the frame below ...
structref_mini_test.py in __new__(cls, val)
     18 class Value(structref.StructRefProxy):
     19     def __new__(cls, val):
---> 20         return structref.StructRefProxy.__new__(cls, val)
     21 
     22     @property
RecursionError: maximum recursion depth exceeded
```
user: bairdlampard534
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7112: state: open
title: NumPy Ufuncs on scalar values don't work in CUDA
body: Reported in [this Discourse post](https://numba.discourse.group/t/cant-use-basic-numpy-functions-with-cuda-like-zeros-or-empty/628/4).

The [CUDA NumPy support documentation](https://numba.readthedocs.io/en/latest/cuda/cudapysupported.html#numpy-support) states that:

> scalar ufuncs that have equivalents in the math module; i.e. np.sin(x[0]), where x is a 1D array.

are supported. However, executing:

```python
import numpy as np
from numba import cuda
import math

test_in2 = cuda.to_device(np.array([0, math.pi/3, math.pi]))
test_out2 = cuda.to_device(np.array([0,0,0]))

@cuda.jit
def test_math_sin_numpy(in_array, out_array):
    i = cuda.grid(1)
    if i < in_array.size:
        if np.sin(in_array[i]) < .5:
            out_array[i] = 100

test_math_sin_numpy.forall(test_in2.size)(test_in2, test_out2)
print(test_out2.copy_to_host())
```

results in an exception:

```
numba.core.errors.TypingError: Failed in cuda mode pipeline (step: nopython frontend)
Use of unsupported NumPy function 'numpy.sin' or unsupported use of the function.

File "repro.py", line 12:
def test_math_sin_numpy(in_array, out_array):
    <source elided>
    if i < in_array.size:
        if np.sin(in_array[i]) < .5:
        ^

During: typing of get attribute at /home/gmarkall/numbadev/issues/discourse-628/repro.py (12)

File "repro.py", line 12:
def test_math_sin_numpy(in_array, out_array):
    <source elided>
    if i < in_array.size:
        if np.sin(in_array[i]) < .5:
```

This has never worked since the relevant documentation was added in #2722. However, it should not be too difficult to fix - the typing and lowering for these NumPy ufuncs can share the implementations from the typing and lowering for the `math` module.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_7110: state: open
title: numpy.delete optional argument 'axis' support
body: ## Feature request

Hi,
I'm working at the moment with numba and numpy, and I wondered, why numba doesn't seems to fully support numpy.delete. If I use the third argument "axis" (described in [Numpy Delete Docu](https://numpy.org/doc/stable/reference/generated/numpy.delete.html)), numba tells me that it doesn't know this argument. Without numba it is working perfectly. (It is very interesting, that numba does support 'axis' from numpy.append, but doesn't support numpy.insert at all.) The problem is, that without this argument, arrays are automatically flattened when deleting a part of it. I appended an code example and a (not very nice) way to go around that problem. Thanks for your help!

`A = np.zeros((2,5))`
`print("original array",A)`
`B = np.delete(A,1)`
`print("without axis",B)`
`C = np.delete(A,1,0)   `
`print("with axis",C)`
`D = np.append(A[:1],A[2:],axis=0)  `
`print("alternative way",D)`

output:

`original array [[0. 0. 0. 0. 0.]
 [0. 0. 0. 0. 0.]]`
`without axis [0. 0. 0. 0. 0. 0. 0. 0. 0.]`
`with axis [[0. 0. 0. 0. 0.]]`
`alternative way [[0. 0. 0. 0. 0.]]`

user: Hanni-ui
issue_7109: state: open
title: Second update to nonlocal variable is ignored
body: This outputs 1 instead of 2:

```python
import numba

@numba.njit
def test():

    a = 0
    
    def inner():
        nonlocal a
        a = 1
        a = 2
        
    inner()
    print(a)
        
test()
```

Version: numba-0.53.1-cp37-cp37m-manylinux2014_x86_64.whl
user: ghost
labels: bug - miscompile: Bugs: miscompile
issue_7108: state: open
title: Mutating a typed dict whilst iterating is not handled correctly
body: When I try mutating a typed dict via a for loop in @njit I only get one iteration of the loop mutated. If I create a new dict instead it works.

Numpy version: 1.20.2
Numba version: 0.53.1



```
import numba as nb
from numba.types import Set, Tuple, int32, int64
from numba.typed import Dict

t = Tuple((int64,int64))
d1 = Dict.empty(t,int64)
d2 = Dict.empty(t,int64)

@nb.njit
def augment_wrong(x):
    # This is wrong - only one pass through iteration
    for key in x.keys():
        x[(key[0]+1, key[1])] = 1
    return x

@nb.njit
def augment_works(x):
    new_d = Dict.empty(t,int64)
    for key in x.keys():
        new_d[key] = 1 # Copy original key over
        new_d[(key[0]+1, key[1])] = 1
    return new_d

d1[(0,0)] = 1
d1[(1,1)] = 1
d2[(0,0)] = 1
d2[(1,1)] = 1

print(augment_wrong(d1))
print(augment_works(d2))
```

Apologies if I'm misunderstanding a guarantee - my understanding is that mutating typed Dicts should be allowed.

Thanks!
user: mharradon
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7101: state: open
title: segmentation fault when calling np.all in ipython 
body: 
## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I tested this in the following envs
1. Ubuntu on VM box, - python 3.8 with numba stable and latest master version
2. Anaconda Docker image -with numba stable and latest master version 

This only happens when I am using `ipython` in linux. If I run the following code in `ipython` on windows or script, it works without any error.
```
from numba import njit
import numpy as np
@njit
def func():
     return np.all([[True,False],[True,True]])

```
Output:
```
In [2]: func()
Out[2]: True

Segmentation fault
(numbaenv) root@3080b57977ff:/home/numba_c/numba#
```

Edit 1: I missed this earlier as i was focused on the `segfault`. The output seems to be wrong as well. numpy gives `False` for the above while numba is evaluating it to `True`
user: rawwar
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_7099: state: open
title: NamedTuple Optional np.ndarray field type does not compile
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

It seems that numba does not pass the type of a namedtuple; in this case it is an Optional[np.ndarray].
This might be related to https://github.com/numba/numba/issues/3972 .
In the example below, the calls to `f` work, the call to `g` errors out.

```python
import numba as nb
import numpy as np

from typing import NamedTuple,Optional
class A(NamedTuple):
    a : Optional[np.ndarray] = None
    
@nb.njit
def f(p:A):
    a = np.empty((0,)) if p.a is None else p.a
    return len(a)

p = A(a = None)
assert f(p)==0

p = A(a = np.zeros(3))
assert f(p)==3
    
@nb.njit
def g(p:A):
    a = p.a
    if a is not None:
        return len(a)

p = A(a = None)
g(p)
```

```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-74-725a4aecb7f3> in <module>
     24 
     25 p = A(a = None)
---> 26 g(p)

~/miniconda3/lib/python3.9/site-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    418                 e.patch_message(msg)
    419 
--> 420             error_rewrite(e, 'typing')
    421         except errors.UnsupportedError as e:
    422             # Something unsupported is present in the user code, add help info

~/miniconda3/lib/python3.9/site-packages/numba/core/dispatcher.py in error_rewrite(e, issue_type)
    359                 raise e
    360             else:
--> 361                 raise e.with_traceback(None)
    362 
    363         argtypes = []

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function len>) found for signature:
 
 >>> len(none)
 
There are 22 candidate implementations:
      - Of which 22 did not match due to:
      Overload of function 'len': File: <numerous>: Line N/A.
        With argument(s): '(none)':
       No match.

During: resolving callee type: Function(<built-in function len>)
During: typing of call at <ipython-input-74-725a4aecb7f3> (23)


File "<ipython-input-74-725a4aecb7f3>", line 23:
def g(p:A):
    <source elided>
    if a is not None:
        return len(a)
        ^
```

Workaround, a bit wordier to satisfy static analyzers:
```python
@nb.njit
def f(p:A):
    maybe_a=p.a
    has_a = maybe_a is not None
    _a = maybe_a if maybe_a is not None else np.empty((0,)) # the default value must support all ops that non-None a does
    return len(_a)
p = A(a = None)
assert f(p)==0
```

user: LunarLanding
issue_7093: state: open
title: CUDA: Make typing and target contexts singletons
body: As identified in the Numba dev meeting on 2021-06-09, it may be necessary to make the CUDA target and typing contexts singletons. However, this might cause issues because certain things are attached to the context for each dispatcher, for example the fast math flag.

This issue is to hold notes, progress, and thoughts on the process of making them singletons.

The first step is to make them singletons and to check how this affects the test suite - it is expected that most things should work, except those involving the fast math flag.

To resolve the fast math flag issue, the storage of fast math in the context in CUDA should be dropped, and the builder should be used to enquire about the fast math status.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7089: state: open
title: CUDA: Overloading existing implementations of functions seems not to work
body: The following:

```python
from operator import sub

import numpy as np
import numba as nb
from numba import cuda
from numba.core.extending import overload


def vec(x, y, z):
    return nb.float32(x), nb.float32(y), nb.float32(z)


vector3 = nb.types.UniTuple(nb.float32, 3)


@overload(sub, target="cuda")
def sub_vec_overload(a, b):
    if a == vector3 and b == vector3:
        def impl(a, b):
            return a[0] - b[0], a[1] - b[1], a[2] - b[2]
        return impl


@cuda.jit()
def test_cuda(a, b, r):
    r[0] = a - b


av = vec(3, 2, 1)
bv = vec(1, 2, 3)
res = np.zeros((1, 3), np.float32)

test_cuda[1, 1](av, bv, res)
```

Results in:

```
numba.core.errors.TypingError: Failed in cuda mode pipeline (step: native lowering)
No implementation of function Function(<built-in function sub>) found for signature:
 
 >>> sub(UniTuple(float32 x 3), UniTuple(float32 x 3))
 
There are 8 candidate implementations:
 - Of which 2 did not match due to:
 Operator Overload in function 'sub': File: unknown: Line unknown.
   With argument(s): '(UniTuple(float32 x 3), UniTuple(float32 x 3))':
  No match for registered cases:
   * (int64, int64) -> int64
   * (int64, uint64) -> int64
   * (uint64, int64) -> int64
   * (uint64, uint64) -> uint64
   * (float32, float32) -> float32
   * (float64, float64) -> float64
   * (complex64, complex64) -> complex64
   * (complex128, complex128) -> complex128
 - Of which 6 did not match due to:
 Overload of function 'sub': File: <numerous>: Line N/A.
   With argument(s): '(UniTuple(float32 x 3), UniTuple(float32 x 3))':
  No match.

During: lowering "$6binary_subtract.2 = a - b" at /home/gmarkall/numbadev/issues/MegaIng/cuda_overload.py (27)
```

with current master. I've also tried it with #7058, which gives a slightly different error:

```
numba.core.errors.TypingError: Failed in cuda mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function sub>) found for signature:
 
 >>> sub(UniTuple(float32 x 3), UniTuple(float32 x 3))
 
There are 12 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'sub_vec_overload': File: ../issues/MegaIng/cuda_overload.py: Line 16.
    With argument(s): '(UniTuple(float32 x 3), UniTuple(float32 x 3))':
   Rejected as the implementation raised a specific error:
     LoweringError: Failed in cuda mode pipeline (step: native lowering)
   No definition for lowering <built-in method jit_wrapper__built_in_function_sub_ of _dynfunc._Closure object at 0x7f5521e10340>(float32, float32) -> float32
   
   File "cuda_overload.py", line 20:
           def impl(a, b):
               return a[0] - b[0], a[1] - b[1], a[2] - b[2]
               ^
   
   During: lowering "$14binary_subtract.6 = $6binary_subscr.2 - $12binary_subscr.5" at /home/gmarkall/numbadev/issues/MegaIng/cuda_overload.py (20)
  raised from /home/gmarkall/numbadev/numba/numba/core/errors.py:754
  - Of which 4 did not match due to:
  Overload in function '_OverloadWrapper._build.<locals>.ol_generated': File: numba/core/overload_glue.py: Line 131.
    With argument(s): '(UniTuple(float32 x 3), UniTuple(float32 x 3))':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<intrinsic stub>) found for signature:
    
    >>> stub(UniTuple(float32 x 3), UniTuple(float32 x 3))
    
   There are 2 candidate implementations:
     - Of which 2 did not match due to:
     Intrinsic of function 'stub': File: numba/core/overload_glue.py: Line 35.
       With argument(s): '(UniTuple(float32 x 3), UniTuple(float32 x 3))':
      No match.
   
   During: resolving callee type: Function(<intrinsic stub>)
   During: typing of call at <string> (3)
   
   
   File "<string>", line 3:
   <source missing, REPL/exec in use?>

  raised from /home/gmarkall/numbadev/numba/numba/core/typeinfer.py:1074
  - Of which 6 did not match due to:
  Overload of function 'sub': File: <numerous>: Line N/A.
    With argument(s): '(UniTuple(float32 x 3), UniTuple(float32 x 3))':
   No match.

During: typing of intrinsic-call at /home/gmarkall/numbadev/issues/MegaIng/cuda_overload.py (27)

File "cuda_overload.py", line 27:
def test_cpu(a, b, r):
    r[0] = a - b
    ^
```

cc @MegaIng 
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_7085: state: open
title: Vectorize doesn't play well with `forceobj=True`
body: Thanks for Numba and all your support. It's been invaluable to me in optimizing specific bits of python code. :+1: 

`numba.vectorize` doesn't compile a ufunc in object mode properly, specifically using Python integers of arbitrary size. `numba.jit` produces the expected result.

## Minimal example

Python version: 3.8.5
Numpy version: 1.17.4
Numba version: 0.53.1

```python
# File: bug.py
import numba
import numpy as np


@numba.jit(forceobj=True)
def my_add_jit(a, b):
    return a ^ b


@numba.vectorize(forceobj=True)
def my_add_ufunc(a, b):
    return a ^ b


def test_small_integers():
    # Using integers smaller than 2^64
    a = 26878
    b = 242750
    print("jit:  ", my_add_jit(a, b), a ^ b)
    print("ufunc:", my_add_ufunc(a, b), a ^ b)


def test_large_integers():
    # Using integers larger than 2^64
    a = 1016303452178253514437189983278
    b = 7109215207484208127493508648
    print("jit:  ", my_add_jit(a, b), a ^ b)
    print("ufunc:", my_add_ufunc(a, b), a ^ b)
```

## Current output

```python
In [1]: %run bug.py                                                                                             

In [2]: test_large_integers()                                                                                   
jit:   1011747723244212619517498216966 1011747723244212619517498216966
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-2-8a67a812ecb0> in <module>
----> 1 test_large_integers()

~/repos/galois/bug.py in test_large_integers()
     26     b = 7109215207484208127493508648
     27     print("jit:  ", my_add_jit(a, b), a ^ b)
---> 28     print("ufunc:", my_add_ufunc(a, b), a ^ b)

~/.local/lib/python3.8/site-packages/numba/np/ufunc/dufunc.py in _compile_for_args(self, *args, **kws)
    185         argtys = []
    186         for arg in args[:nin]:
--> 187             argty = typeof(arg)
    188             if isinstance(argty, types.Array):
    189                 argty = argty.dtype

~/.local/lib/python3.8/site-packages/numba/core/typing/typeof.py in typeof(val, purpose)
     29     # Note the behaviour for Purpose.argument must match _typeof.c.
     30     c = _TypeofContext(purpose)
---> 31     ty = typeof_impl(val, c)
     32     if ty is None:
     33         msg = _termcolor.errmsg(

/usr/lib/python3.8/functools.py in wrapper(*args, **kw)
    873                             '1 positional argument')
    874 
--> 875         return dispatch(args[0].__class__)(*args, **kw)
    876 
    877     funcname = getattr(func, '__name__', 'singledispatch function')

~/.local/lib/python3.8/site-packages/numba/core/typing/typeof.py in _typeof_int(val, c)
    130         typ = types.uint64
    131     else:
--> 132         raise ValueError("Int value is too large: %s" % val)
    133     return typ
    134 

ValueError: Int value is too large: 1016303452178253514437189983278
```

## Expected output

```python
In [1]: %run bug.py                                                                                             

In [2]: test_large_integers()                                                                                   
jit:   1011747723244212619517498216966 1011747723244212619517498216966
ufunc: 1011747723244212619517498216966 1011747723244212619517498216966
```

## Additional confusion

Also, even if I pass in small integers, `numba` complains that I haven't provided the return signature. How do I provide a function signature for object mode?

```python
In [1]: %run bug.py                                                                                             

In [2]: test_small_integers()                                                                                   
jit:   253120 253120
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-5fe3443ac9e3> in <module>
----> 1 test_small_integers()

~/repos/galois/bug.py in test_small_integers()
     18     b = 242750
     19     print("jit:  ", my_add_jit(a, b), a ^ b)
---> 20     print("ufunc:", my_add_ufunc(a, b), a ^ b)
     21 
     22 

~/.local/lib/python3.8/site-packages/numba/np/ufunc/dufunc.py in _compile_for_args(self, *args, **kws)
    199                 argty = numpy_support.map_arrayscalar_type(arg)
    200             argtys.append(argty)
--> 201         return self._compile_for_argtys(tuple(argtys))
    202 
    203     def _compile_for_argtys(self, argtys, return_type=None):

~/.local/lib/python3.8/site-packages/numba/np/ufunc/dufunc.py in _compile_for_argtys(self, argtys, return_type)
    218         cres, argtys, return_type = ufuncbuilder._compile_element_wise_function(
    219             self._dispatcher, self.targetoptions, sig)
--> 220         actual_sig = ufuncbuilder._finalize_ufunc_signature(
    221             cres, argtys, return_type)
    222         dtypenums, ptr, env = ufuncbuilder._build_element_wise_ufunc_wrapper(

~/.local/lib/python3.8/site-packages/numba/np/ufunc/ufuncbuilder.py in _finalize_ufunc_signature(cres, args, return_type)
    155         if cres.objectmode:
    156             # Object mode is used and return type is not specified
--> 157             raise TypeError("return type must be specified for object mode")
    158         else:
    159             return_type = cres.signature.return_type

TypeError: return type must be specified for object mode
```

The only way I could satisfy the compiler was to provide this signature, but this won't work for arbitrarily-large integers (which is the intended use case with `forceobj=True`).

```python
@numba.vectorize("int64(int64, int64)", forceobj=True)
def my_add_ufunc(a, b):
    return a ^ b
```

```python
In [1]: %run bug.py                                                                                             

In [2]: test_small_integers()                                                                                   
jit:   253120 253120
ufunc: 253120 253120
```

Feel free to close this immediately if this is intended behavior.
user: mhostetter
issue_7084: state: open
title: Feature request: user-level statically defined tracepoints
body: ## Feature request

I would like to be able to insert user-level statically defined tracepoints (USDT, sometimes also known as 'probes') into nopython-mode compiled code. I want this because I want to do very low-level profiling of my code, including (ideally) using hardware PMC data to understand cache hit performance and CPU stall behavior on Linux.

### Motivation

Performance profiling has been requested in the past (#5028 for example) but it looks very difficult, possibly requiring patches in LLVM, and requiring a migration to a different LLVM JIT implementation.

Static tracing is less powerful than #5028's proposal, but it _might_ be easier to implement, and it can serve as a bridge to help with profiling for advanced users. 

By integrating with a system like [DTrace](https://illumos.org/books/dtrace/chp-usdt.html), static tracepoints could quickly open up a wide array of profiling tools. With tracepoints, we could use the [BPF suite](http://www.brendangregg.com/ebpf.html) of performance analysis tools, [perf(1)](https://en.wikipedia.org/wiki/Perf_(Linux)), and [SystemTap](https://sourceware.org/systemtap/wiki). These each have powerful visualization frameworks built in, are highly programmable, and have access to lots of other lower-level data.

In summary - I think static tracing might be easier than #5028, but captures some of the benefits.

### Implementation ideas

A good implementation might target DTrace and/or SystemTap probes. I think DTrace is more broadly useful, but both are good.

I don't have strong opinions on the user-facing API. But the simplest might be something like a `probe` function which takes a label name:

```python
import numba

@numba.jit(nopython=True)
def add_sin(x, y):
    numba.probe("add_sin")
    return np.sin(x + y)
```

It would be nice to include information about inferred types in the actual probe that is generated from this, but even the most basic version - which just has a probe with no arguments, just a string name - would be useful.

A big question, to me, is how one would actually add a static probe through the LLVM JIT compilation. I have no idea how feasible this really is. Static tracepoints usually are implemented through cleverness in an ELF header; the actual machine code is just a noop which is modified during runtime when profiling tools activate the probe. As a first pass, this _might_ be doable with a `numba.extensions.intrinsic`?

[XRay](https://llvm.org/docs/XRay.html) is yet another tracing system, and one which might be easier add because it's part of the LLVM project, but I'm not nearly as familiar with it. I don't know how useful it would be because I don't know how well it integrates with other tools.

### Related work

[`python-stapsdt`](https://github.com/sthima/python-stapsdt) is a Python library for adding static tracepoints to Python code, backed by [`libstapsdt`](https://github.com/sthima/libstapsdt).

[Python Issue 21590](https://bugs.python.org/issue21590) added a few static tracepoints to the CPython interpreter. Usage is documented [here](https://docs.python.org/3/howto/instrumentation.html).
user: spenczar
issue_7077: state: open
title: Support full broadcasting in `numpy.where`
body: There are still a few broadcasting cases in `numpy.where` that aren't covered.

```python
import numpy as np
import numba


@numba.njit
def nb_where(c, a, b):
    return np.where(c, a, b)


b = np.random.random(size=(3, 3))
inputs_1 = [np.array([[False]]), np.array([[0]]), b]

nb_where(*inputs_1)
# lib/python3.7/site-packages/numba/np/arraymath.py in where_impl()
#    3185             shape = cond.shape
#    3186             if x.shape != shape or y.shape != shape:
# -> 3187                 raise ValueError("all inputs should have the same shape")
#    3188             res = np.empty_like(x, dtype=npty)
#    3189             cf = cond.flat
#
# ValueError: all inputs should have the same shape

```

From #6624 and #3630, I see that there's some support for broadcasting when the latter two arguments (i.e. `a` and `b`) are static, but not this more general case.

From a NumPy perspective, one easy answer is to just broadcast all the arguments with something like `np.broadcast_arrays`; however, since the general NumPy broadcasting functions aren't available, I'm not sure how else to neatly work around this.  (Created an issue for those: #7078.)
user: brandonwillard
issue_7075: state: open
title: Numba caches relative imports and not absolute
body: Calling a function decorated with `@numba.njit(cache=True)` results in a relative import being stored to `__pycache__`. When the cached compiled function is later imported and called from a file in another directory than where it is was called when the cache was created a  `ModuleNotFoundError` is thrown.

The issue for me occurs since I test the `njit` decorated functions using `pytest` before calling them in my production code. This relative storage of module paths then leads to the error being thrown in runtime since the `__pycache__` is already there from the run with `pytest`.

Could the `cache=True` store absolute paths or not store the paths at all perhaps?

Tested on:
Linux Ubuntu 20.04 LTS with `numba==0.53.1` and `python==3.8.5`

Reproducible code:
Deflate the tar.gz file and run the script `test_path.sh` inside to reproduce the issue.
[issue_numba_cache_import.tar.gz](https://github.com/numba/numba/files/6591209/issue_numba_cache_import.tar.gz)


user: mikaeltw
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_7069: state: open
title: Support accessing static values of classes in JIT functions
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->
I came across this gap recently. Static values of classes can be handled similar to global/free variables I think.

```python
import numba

class Foo:
    pass

class Bar:
    a = Foo()

@numba.njit
def f():
    return Bar.a

f()
```
```
  File "/Users/ehsan/dev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/ehsan/dev/numba/numba/core/typed_passes.py", line 104, in run_pass
    typemap, return_type, calltypes, errs = type_inference_stage(
  File "/Users/ehsan/dev/numba/numba/core/typed_passes.py", line 80, in type_inference_stage
    infer.build_constraint()
  File "/Users/ehsan/dev/numba/numba/core/typeinfer.py", line 1024, in build_constraint
    self.constrain_statement(inst)
  File "/Users/ehsan/dev/numba/numba/core/typeinfer.py", line 1371, in constrain_statement
    self.typeof_assign(inst)
  File "/Users/ehsan/dev/numba/numba/core/typeinfer.py", line 1442, in typeof_assign
    self.typeof_global(inst, inst.target, value)
  File "/Users/ehsan/dev/numba/numba/core/typeinfer.py", line 1542, in typeof_global
    typ = self.resolve_value_type(inst, gvar.value)
  File "/Users/ehsan/dev/numba/numba/core/typeinfer.py", line 1463, in resolve_value_type
    raise TypingError(msg, loc=inst.loc)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'Bar': Cannot determine Numba type of <class 'type'>

File "../tmp/class_static.py", line 12:
def f():
    return Bar.a
    ^
```
user: ehsantn
issue_7063: state: open
title: Numba installation scripts exhibit a race condition during parallel builds
body: I can't confirm whether prior versions of Numba suffer similar issues, <sup>*...they almost certainly do*</sup> but Numba 0.53.1 non-deterministically blows up at compilation time when enabling parallel make jobs – that is, when passing anything *other* than `-j 1` to the `setup.py build` phase.

When passing `-j {n}` for `n > 1`, installation frequently fails with a wall of text resembling:

```
$ python3.7 setup.py build -j 64
TBB disabled
OpenMP disabled
running build
got version from expanded keyword {'version': '0.53.1', 'full': '97fe221b3704bd17567b57ea47f4fc6604476cf9'}
running build_py
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/runtests.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/extending.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_version.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/__main__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/types
copying numba/types/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/types
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/typed/typedobjectutils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/typed/typedlist.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/typed/typeddict.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/typed/listobject.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/typed/dictobject.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/typed/dictimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/typed/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_record_dtype.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_jitclasses.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/threading_backend_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_wrapper.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_withlifting.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_warnings.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_vectorization_type_inference.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_vectorization.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_unsafe_intrinsics.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_unpack_sequence.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_unicode_names.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_unicode_array.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_unicode.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_ufuncs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typingerror.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_types.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typeof.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typenames.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typeinfer.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typeguard.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typedobjectutils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typedlist.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_typeconv.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_tuples.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_try_except.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_tracing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_threadsafety.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_target_overloadselector.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_sysinfo.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_sys_stdin_assignment.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_svml.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_support.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_struct_ref.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_storeslice.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_stencils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_ssa.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_sort.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_slices.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_sets.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_serialize.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_runtests.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_return_values.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_remove_dead.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_refop_pruning.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_recursion.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_recarray_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_range.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_random.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_python_int.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_pycc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_profiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_print.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_practical_lowering_issues.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_polynomial.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_pipeline.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_parfors_passes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_parfors_caching.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_parfors.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_parallel_backend.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_overlap.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_optional.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_operators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_objects.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_object_mode.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_obj_lifetime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_numpyadapt.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_numpy_support.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_numconv.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_numbers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_numberctor.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_num_threads.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_nrt_refct.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_nrt.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_npdatetime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_np_functions.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_nested_calls.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_nan.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_multi3.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_moved_modules.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_mixed_tuple_unroller.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_maxmin.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_mathlib.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_map_filter_reduce.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_mangling.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_mandelbrot.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_make_function_to_jit_function.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_looplifting.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_locals.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_llvm_version_check.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_llvm_pass_timings.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_literal_dispatch.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_lists.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_listobject.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_listimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_linalg.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_jitmethod.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_jit_module.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_iteration.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_itanium_mangler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_ir_utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_ir_inlining.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_ir.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_intwidth.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_interproc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_inlining.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_init_utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_indexing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_import.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_help.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_heapq.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_hashing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_globals.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_gil.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_generators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_gdb.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_function_type.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_funcdesc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_func_lifetime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_func_interface.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_flow_control.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_fastmath.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_fancy_indexing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_extending_types.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_extending.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_extended_arg.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_exceptions.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_event.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_errormodels.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_errorhandling.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_enums.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_entrypoints.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dyn_func.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dyn_array.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dummyarray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dispatcher.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dicts.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dictobject.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dictimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_deprecations.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_debuginfo.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_debug.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_datamodel.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_dataflow.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_ctypes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_copy_propagate.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_conversion.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_config.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_conditions_as_predicates.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_comprehension.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_complex.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_compiler_lock.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_compile_cache.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_codegen.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_closure.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_cli.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_chained_assign.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_cgutils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_cfunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_cffi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_casting.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_caching.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_byteflow.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_builtins.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_buffer_protocol.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_boundscheck.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_blackscholes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_auto_constants.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_asnumbatype.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_return.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_reductions.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_methods.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_manipulation.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_iterators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_exprs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_constants.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_attr.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_array_analysis.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_api.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_annotations.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_analysis.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/test_alignment.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/support.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/serialize_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/recursion_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/pdlike_usecase.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/parfors_cache_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/overload_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/orphaned_semaphore_usecase.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/matmul_usecase.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/inlining_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/error_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/enum_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/dummy_module.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/ctypes_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/complex_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/compile_with_pycc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/cfunc_cache_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/cffi_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/cache_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/annotation_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
copying numba/tests/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/testing
copying numba/testing/notebook.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/testing
copying numba/testing/main.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/testing
copying numba/testing/loader.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/testing
copying numba/testing/_runtests.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/testing
copying numba/testing/__main__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/testing
copying numba/testing/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/testing
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/stencils
copying numba/stencils/stencilparfor.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/stencils
copying numba/stencils/stencil.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/stencils
copying numba/stencils/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/stencils
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/scripts
copying numba/scripts/generate_lower_listing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/scripts
copying numba/scripts/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/scripts
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/vectorizers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/target.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/stubs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/mathimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/mathdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/initialize.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/hsaimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/hsadecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/gcn_occupancy.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/enums.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/dispatch.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/descriptor.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/decorators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/compiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/codegen.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/api.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
copying numba/roc/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
copying numba/pycc/platform.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
copying numba/pycc/llvm_types.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
copying numba/pycc/decorators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
copying numba/pycc/compiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
copying numba/pycc/cc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
copying numba/pycc/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/parfors
copying numba/parfors/parfor_lowering_utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/parfors
copying numba/parfors/parfor_lowering.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/parfors
copying numba/parfors/parfor.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/parfors
copying numba/parfors/array_analysis.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/parfors
copying numba/parfors/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/parfors
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/ufunc_db.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/polynomial.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/numpy_support.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/npyimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/npyfuncs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/npdatetime_helpers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/npdatetime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/linalg.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/extensions.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/arrayobj.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/arraymath.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
copying numba/np/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/timsort.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/special.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/quicksort.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/numba_sysinfo.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/numba_entry.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/mergesort.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/llvm_pass_timings.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/literal.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/inspection.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/init_utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/gdb_hook.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/findlib.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/dump_style.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/dummyarray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/cffiimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/appdirs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/misc/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental
copying numba/experimental/structref.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental
copying numba/experimental/function_type.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental
copying numba/experimental/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/vectorizers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/types.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/testing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/target.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/stubs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/simulator_init.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/random.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/printimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/nvvmutils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/models.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/mathimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/libdeviceimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/libdevicefuncs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/libdevicedecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/libdevice.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/intrinsic_wrapper.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/initialize.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/errors.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/envvars.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/dispatcher.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/device_init.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/descriptor.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/decorators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/cudamath.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/cudaimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/cudadecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/cuda_paths.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/compiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/codegen.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/args.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/api.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
copying numba/cuda/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/unicode_support.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/unicode.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/tupleobj.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/slicing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/setobj.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/rangeobj.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/randomimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/printimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/numbers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/mathimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/listobj.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/iterators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/heapq.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/hashing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/enumimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/cmathimpl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/charseq.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/builtins.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
copying numba/cpython/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/withcontexts.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/untyped_passes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/typeinfer.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/typed_passes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/transforms.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/tracing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/ssa.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/sigutils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/serialize.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/removerefctpass.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/registry.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/pythonapi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/pylowering.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/postproc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/options.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/optional.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/object_mode_passes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/lowering.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/itanium_mangler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/ir_utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/ir.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/intrinsics.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/interpreter.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/inline_closurecall.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/imputils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/generators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/funcdesc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/fastmathpass.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/externals.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/extending.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/event.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/errors.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/environment.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/entrypoints.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/dispatcher.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/descriptors.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/decorators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/debuginfo.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/dataflow.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/cpu_options.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/cpu.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/controlflow.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/consts.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/config.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/compiler_machinery.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/compiler_lock.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/compiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/codegen.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/cgutils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/ccallback.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/callwrapper.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/callconv.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/caching.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/byteflow.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/bytecode.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/boxing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/base.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/analysis.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
copying numba/core/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
copying numba/cext/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase
copying numba/tests/pycc_distutils_usecase/source_module.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase
copying numba/tests/pycc_distutils_usecase/setup_setuptools_nested.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase
copying numba/tests/pycc_distutils_usecase/setup_setuptools.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase
copying numba/tests/pycc_distutils_usecase/setup_distutils_nested.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase
copying numba/tests/pycc_distutils_usecase/setup_distutils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase
copying numba/tests/pycc_distutils_usecase/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_vectorize_decor.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_ufuncbuilding.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_ufunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_parallel_ufunc_issues.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_parallel_low_work.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_parallel_env_variable.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_gufunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_errors.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_dufunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/test_caching.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/cache_usecases.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
copying numba/tests/npyufunc/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/npyufunc
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_typed_list_usage.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_typed_dict_usage.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_structref_usage.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_rec_array.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_llvm_pass_timings.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_literally_usage.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_literal_container_usage.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_jitclass.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/test_examples.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
copying numba/tests/doc_examples/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/doc_examples
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase/nested
copying numba/tests/pycc_distutils_usecase/nested/source_module.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase/nested
copying numba/tests/pycc_distutils_usecase/nested/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/tests/pycc_distutils_usecase/nested
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests
copying numba/roc/tests/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/servicelib
copying numba/roc/servicelib/threadlocal.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/servicelib
copying numba/roc/servicelib/service.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/servicelib
copying numba/roc/servicelib/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/servicelib
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/error.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/enums_ext.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/enums.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/drvapi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/driver.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/devices.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/devicearray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
copying numba/roc/hsadrv/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hsadrv
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hlc
copying numba/roc/hlc/libhlc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hlc
copying numba/roc/hlc/hlc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hlc
copying numba/roc/hlc/config.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hlc
copying numba/roc/hlc/common.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hlc
copying numba/roc/hlc/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/hlc
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_ufuncbuilding.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_simple.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_scan.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_reduction.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_positioning.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_occupancy.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_memory.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_matmul.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_math.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_linkage.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_large_code.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_intrinsics.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_gufuncbuilding.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_decorator.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_compiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_barrier.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_autojit.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_atomics.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/test_async_kernel.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/run_far_branch.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
copying numba/roc/tests/hsapy/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsapy
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsadrv
copying numba/roc/tests/hsadrv/test_driver.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsadrv
copying numba/roc/tests/hsadrv/test_async.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsadrv
copying numba/roc/tests/hsadrv/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/roc/tests/hsadrv
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/unsafe
copying numba/np/unsafe/ndarray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/unsafe
copying numba/np/unsafe/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/unsafe
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/wrappers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/ufuncbuilder.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/sigparse.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/parallel.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/gufunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/dufunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/deviceufunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/decorators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/array_exprs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
copying numba/np/ufunc/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc/help
copying numba/misc/help/inspector.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc/help
copying numba/misc/help/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc/help
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental/jitclass
copying numba/experimental/jitclass/decorators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental/jitclass
copying numba/experimental/jitclass/boxing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental/jitclass
copying numba/experimental/jitclass/base.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental/jitclass
copying numba/experimental/jitclass/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental/jitclass
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests
copying numba/cuda/tests/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator
copying numba/cuda/simulator/reduction.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator
copying numba/cuda/simulator/kernelapi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator
copying numba/cuda/simulator/kernel.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator
copying numba/cuda/simulator/compiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator
copying numba/cuda/simulator/api.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator
copying numba/cuda/simulator/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/kernels
copying numba/cuda/kernels/transpose.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/kernels
copying numba/cuda/kernels/reduction.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/kernels
copying numba/cuda/kernels/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/kernels
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/runtime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/rtapi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/nvvm.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/ndarray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/libs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/error.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/enums.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/drvapi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/driver.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/devices.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/devicearray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
copying numba/cuda/cudadrv/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/nocuda
copying numba/cuda/tests/nocuda/test_nvvm.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/nocuda
copying numba/cuda/tests/nocuda/test_library_lookup.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/nocuda
copying numba/cuda/tests/nocuda/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/nocuda
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/doc_examples
copying numba/cuda/tests/doc_examples/test_random.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/doc_examples
copying numba/cuda/tests/doc_examples/test_cg.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/doc_examples
copying numba/cuda/tests/doc_examples/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/doc_examples
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudasim
copying numba/cuda/tests/cudasim/test_cudasim_issues.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudasim
copying numba/cuda/tests/cudasim/support.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudasim
copying numba/cuda/tests/cudasim/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudasim
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_warp_ops.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_vectorize_scalar_arg.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_vectorize_device.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_vectorize_decor.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_vectorize_complex.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_vectorize.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_userexc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_transpose.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_sync.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_sm_creation.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_sm.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_slicing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_serialize.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_retrieve_autoconverted_arrays.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_reduction.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_record_dtype.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_random.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_py2_div_issue.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_print.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_powi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_optimization.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_operator.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_nondet.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_multithreads.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_multiprocessing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_multigpu.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_montecarlo.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_minmax.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_matmul.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_math.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_mandel.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_localmem.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_libdevice.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_laplace.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_lang.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_ipc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_intrinsics.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_inspect.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_idiv.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_gufunc_scheduling.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_gufunc_scalar.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_gufunc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_globals.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_frexp_ldexp.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_freevar.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_forall.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_fastmath.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_exception.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_errors.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_dispatcher.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_device_func.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_debuginfo.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_debug.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_datetime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_cuda_jit_no_types.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_cuda_array_interface.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_cooperative_groups.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_constmem.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_const_string.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_complex_kernel.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_complex.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_compiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_casting.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_boolean.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_blackscholes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_atomics.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_array_methods.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_array_args.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_array.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/test_alignment.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
copying numba/cuda/tests/cudapy/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudapy
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_streams.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_select_device.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_runtime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_reset_device.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_profiler.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_pinned.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_nvvm_driver.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_managed_alloc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_linker.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_ir_patch.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_inline_ptx.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_host_alloc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_events.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_emm_plugins.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_detect.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_deallocations.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_cuda_ndarray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_cuda_memory.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_cuda_libraries.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_cuda_driver.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_cuda_devicerecord.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_cuda_auto_context.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_cuda_array_slicing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_context_stack.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/test_array_attr.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
copying numba/cuda/tests/cudadrv/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv/data
copying numba/cuda/tests/cudadrv/data/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv/data
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/runtime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/nvvm.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/libs.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/drvapi.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/driver.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/devices.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/devicearray.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
copying numba/cuda/simulator/cudadrv/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/simulator/cudadrv
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython/unsafe
copying numba/cpython/unsafe/tuple.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython/unsafe
copying numba/cpython/unsafe/numbers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython/unsafe
copying numba/cpython/unsafe/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cpython/unsafe
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/unsafe
copying numba/core/unsafe/refcount.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/unsafe
copying numba/core/unsafe/nrt.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/unsafe
copying numba/core/unsafe/eh.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/unsafe
copying numba/core/unsafe/bytes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/unsafe
copying numba/core/unsafe/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/unsafe
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/typeof.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/templates.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/setdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/randomdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/npydecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/npdatetime.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/mathdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/listdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/enumdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/dictdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/ctypes_utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/context.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/collections.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/cmathdecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/cffi_utils.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/builtins.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/bufproto.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/asnumbatype.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/arraydecl.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
copying numba/core/typing/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typing
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/scalars.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/npytypes.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/misc.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/iterators.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/functions.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/function_type.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/containers.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/common.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/abstract.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
copying numba/core/types/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/types
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typeconv
copying numba/core/typeconv/typeconv.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typeconv
copying numba/core/typeconv/rules.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typeconv
copying numba/core/typeconv/castgraph.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typeconv
copying numba/core/typeconv/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typeconv
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/nrtopt.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/nrtdynmod.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/nrt.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/context.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/rewrites
copying numba/core/rewrites/static_raise.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/rewrites
copying numba/core/rewrites/static_getitem.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/rewrites
copying numba/core/rewrites/static_binop.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/rewrites
copying numba/core/rewrites/registry.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/rewrites
copying numba/core/rewrites/ir_print.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/rewrites
copying numba/core/rewrites/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/rewrites
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/datamodel
copying numba/core/datamodel/testing.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/datamodel
copying numba/core/datamodel/registry.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/datamodel
copying numba/core/datamodel/packer.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/datamodel
copying numba/core/datamodel/models.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/datamodel
copying numba/core/datamodel/manager.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/datamodel
copying numba/core/datamodel/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/datamodel
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/annotations
copying numba/core/annotations/type_annotations.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/annotations
copying numba/core/annotations/pretty_annotate.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/annotations
copying numba/core/annotations/__init__.py -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/annotations
copying numba/mviewbuf.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_typeof.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_random.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_npymath_exports.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_lapack.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_helpermod.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_helperlib.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_hashtable.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_dynfuncmod.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_dynfunc.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/mathnames.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/capsulethunk.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_unicodetype_db.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_typeof.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_pymodule.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_numba_common.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_hashtable.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_devicearray.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/_arraystruct.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba
copying numba/typed/py.typed -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/typed
copying numba/pycc/modulemixin.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/pycc
copying numba/misc/cmdlang.gdb -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/misc
copying numba/cext/utils.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
copying numba/cext/listobject.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
copying numba/cext/dictobject.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
copying numba/cext/listobject.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
copying numba/cext/dictobject.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
copying numba/cext/cext.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cext
copying numba/cuda/tests/cudadrv/data/jitlink.ptx -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/tests/cudadrv/data
copying numba/core/runtime/nrt.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/_nrt_pythonmod.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/_nrt_python.c -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/nrt_external.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/runtime/nrt.h -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime
copying numba/core/annotations/template.html -> /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/annotations
warning: build_py: byte-compiling is disabled, skipping.

running build_ext
building 'numba._dynfunc' extension
building 'numba._dispatcher' extension
building 'numba._helperlib' extension
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules winreg, win32api or win32con are installed.
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/cext
compile options: '-I/usr/lib/python3.7/site-packages/numpy/core/include -I/usr/include/python3.7m -c'
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/typeconv
compile options: '-I/usr/lib/python3.7/site-packages/numpy/core/include -I/usr/include/python3.7m -c'
compile options: '-I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/_dynfuncmod.c
x86_64-pc-linux-gnu-gcc: numba/_typeof.c
x86_64-pc-linux-gnu-gcc: numba/_hashtable.c
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/_dynfuncmod.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/_dynfunc.cpython-37m-x86_64-linux-gnu.so
x86_64-pc-linux-gnu-gcc: numba/_dispatcher.cpp
building 'numba.core.typeconv._typeconv' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

compile options: '-I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/_helpermod.c
x86_64-pc-linux-gnu-gcc: numba/cext/utils.c
x86_64-pc-linux-gnu-gcc: numba/cext/listobject.c
x86_64-pc-linux-gnu-gcc: numba/core/typeconv/typeconv.cpp
x86_64-pc-linux-gnu-gcc: numba/core/typeconv/_typeconv.cpp
x86_64-pc-linux-gnu-gcc: numba/cext/dictobject.c
x86_64-pc-linux-gnu-gcc: numba/core/typeconv/typeconv.cpp
x86_64-pc-linux-gnu-g++ -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/typeconv/typeconv.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/typeconv/_typeconv.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typeconv/_typeconv.cpython-37m-x86_64-linux-gnu.so
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/typeconv/typeconv.o: file not recognized: file truncated
collect2: error: ld returned 1 exit status
building 'numba.np.ufunc._internal' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/np
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/np/ufunc
compile options: '-I/usr/lib/python3.7/site-packages/numpy/core/include -I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/np/ufunc/_internal.c
x86_64-pc-linux-gnu-g++ -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/_dispatcher.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/_typeof.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/_hashtable.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/typeconv/typeconv.o -L/usr/lib/python3.7/site-packages/numpy/core/lib -lnpymath -lm -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/_dispatcher.cpython-37m-x86_64-linux-gnu.so
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/np/ufunc/_internal.o -L/usr/lib/python3.7/site-packages/numpy/core/lib -lnpymath -lm -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc/_internal.cpython-37m-x86_64-linux-gnu.so
building 'numba.np.ufunc._num_threads' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

compile options: '-I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/np/ufunc/_num_threads.c
building 'numba.mviewbuf' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

compile options: '-I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/mviewbuf.c
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/np/ufunc/_num_threads.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc/_num_threads.cpython-37m-x86_64-linux-gnu.so
building 'numba.core.runtime._nrt_python' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/runtime
compile options: '-I/usr/lib/python3.7/site-packages/numpy/core/include -I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/core/runtime/_nrt_pythonmod.c
x86_64-pc-linux-gnu-gcc: numba/core/runtime/nrt.c
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/mviewbuf.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/mviewbuf.cpython-37m-x86_64-linux-gnu.so
building 'numba.experimental.jitclass._box' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/experimental
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/experimental/jitclass
compile options: '-I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/experimental/jitclass/_box.c
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/runtime/_nrt_pythonmod.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/runtime/nrt.o -L/usr/lib/python3.7/site-packages/numpy/core/lib -lnpymath -lm -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/runtime/_nrt_python.cpython-37m-x86_64-linux-gnu.so
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/experimental/jitclass/_box.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/experimental/jitclass/_box.cpython-37m-x86_64-linux-gnu.so
building 'numba.cuda.cudadrv._extras' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/cuda
creating /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/cuda/cudadrv
compile options: '-Inumba -I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/cuda/cudadrv/_extras.c
building 'numba._devicearray' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

compile options: '-Inumba -I/usr/include/python3.7m -c'
extra options: '-std=c++11'
x86_64-pc-linux-gnu-gcc: numba/_devicearray.cpp
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/cuda/cudadrv/_extras.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/cuda/cudadrv/_extras.cpython-37m-x86_64-linux-gnu.so
building 'numba.np.ufunc.workqueue' extension
C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC

compile options: '-I/usr/include/python3.7m -c'
x86_64-pc-linux-gnu-gcc: numba/np/ufunc/workqueue.c
x86_64-pc-linux-gnu-gcc: numba/np/ufunc/gufunc_scheduler.cpp
x86_64-pc-linux-gnu-g++ -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/_devicearray.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/_devicearray.cpython-37m-x86_64-linux-gnu.so
x86_64-pc-linux-gnu-g++ -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/np/ufunc/workqueue.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/np/ufunc/gufunc_scheduler.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/np/ufunc/workqueue.cpython-37m-x86_64-linux-gnu.so
x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/_helpermod.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/cext/utils.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/cext/dictobject.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/cext/listobject.o -L/usr/lib/python3.7/site-packages/numpy/core/lib -lnpymath -lm -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/_helperlib.cpython-37m-x86_64-linux-gnu.so
error: Command "x86_64-pc-linux-gnu-g++ -shared -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/typeconv/typeconv.o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7/numba/core/typeconv/_typeconv.o -o /var/tmp/portage/dev-python/numba-0.53.1/work/numba-0.53.1-python3_7/build/lib/numba/core/typeconv/_typeconv.cpython-37m-x86_64-linux-gnu.so" failed with exit status 1
```

The tell-tale error line is actually embedded halfway up that log output, which is utterly ridiculous *but what can you do*:

```
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-
linux-gnu/bin/ld: /var/tmp/portage/dev-python/numba-0.53.1
/work/numba-0.53.1-python3_7/build/temp.linux-x86_64-3.7
/numba/core/typeconv/typeconv.o: file not recognized: file 
truncated
```

That means that parallel compilation has failed, which (of course) parallel compilation *almost* always does when building anything scientific under Python 3. Pretty much all of Python's standard scientific stack suffer similar issues – including:

* NumPy at numpy/numpy#15957.
* SciPy at scipy/scipy#7112.
* Pandas at pandas-dev/pandas#30873.

Ideally, upstream `setuptools` would resolve this for everybody and thus us. Pragmatically, `setuptools` developers have no interest or intention of resolving this within the expected lifetime of our Universe. So, a bit of a wait time there.

The [recommended resolution adopted by SciPy](https://github.com/scipy/scipy/blob/master/setup.py#L260) is to **disable parallel building entirely by forcing** `-j 1` **in** `setup.py`. Yes, that's demonstrably awful – but there are *no* working alternatives on the table. Forcing `-j 1` at C extension build time is exactly what everyone does. That's the MostlyRightThing™ to do, because even if `setuptools` *were* to eventually resolve their decades-old unresolved race conditions (which we should all have profound doubts about) that would do little to assist everyone stuck on older `setuptools` versions.

Fortunately, this is trivial. Just override the `finalize_options()` method of your custom `NumbaBuildExt` class in `setup.py` to resemble:

```
class NumbaBuildExt(build_ext):

    user_options = build_ext.user_options + numba_be_user_options
    boolean_options = build_ext.boolean_options + ['werror', 'wall', 'noopt']

    def finalize_options(self):
        super().finalize_options()

        # Disable distutils parallel build due to upstream race conditions.
        if self.parallel:
            print("NOTE: -j build option not supported.")
        self.parallel = None
```

**Boom.** That's it. Then we can all get back to solving actual computational problems that matter, like racing each other to `@numba.njit` random [Rosetta Stone tasks](https://rosettacode.org/wiki/Category:Python).
user: leycec
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_7062: state: open
title: Runtime integer calculation overflow
body: Not sure if this can be classified as a bug but I thought I would post this just incase it isn't known about. Values known at compile time, and are thus computed in Python, use Python's long int and can represent values outside the range of a normal integer so you can get results that don't quite match.

```
from numba import cuda
import numpy as np

@cuda.jit
def test_kernel(a,b,c,test):
	i = cuda.grid(1)

	test[0] = a**b%c
	test[1] = 11**19%1009

a, b, c = 11, 19, 1009
test = cuda.device_array(2, dtype = np.uint32)

test_kernel[1, 1](a,b,c,test)

print(a**b%c,test.copy_to_host())
>>> 902 [759 902]
```
user: uchytilc
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_7060: state: open
title: prange with randomised / shuffled iteration
body: ## Feature request

`prange` currently makes it possible to explicitly parallelise a loop (assuming `parallel=True`).

There are situations where iteration over a range should ideally be randomised / shuffled so that the CPU load can be spread more evenly across all threads.

In my case I am using `prange` to iterate nodes in a graph, and regions of the graph entail heavier computation than other regions in the graph. This results in certain threads (spawned via `prange`) finishing sooner than other threads, which will then block and complete more slowly than otherwise possible.

This could be alleviated by randomising the order of iteration over `prange`.
user: songololo
issue_7059: state: open
title: CUDA typing / lowering can't find `contains_impl` for char sequences
body: There are two reproducers here, which I include both of because I suspect the issues are related / the same.

With master + PR #7057 + PR #6917, the following:

```python
from numba import cuda
import numpy as np

@cuda.jit
def k(result):
    result[0] = '123' in '12345'

result = np.zeros(1, dtype=np.bool_)
k[1, 1](result)
```

Gives the following traceback:

```
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/numba/numba/core/errors.py", line 744, in new_error_context
    yield
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 230, in lower_block
    self.lower_inst(inst)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 323, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 499, in lower_assign
    return self.lower_expr(ty, value)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 1003, in lower_expr
    return self.lower_binop(resty, expr, expr.fn)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 625, in lower_binop
    impl = self.context.get_function(op, sig)
  File "/home/gmarkall/numbadev/numba/numba/core/base.py", line 568, in get_function
    return self.get_function(fn, sig, _firstcall=False)
  File "/home/gmarkall/numbadev/numba/numba/core/base.py", line 570, in get_function
    raise NotImplementedError("No definition for lowering %s%s" % (key, sig))
NotImplementedError: No definition for lowering <built-in method contains_impl of _dynfunc._Closure object at 0x7f35e557bd00>(unicode_type, unicode_type) -> bool

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/cuda-unicode-string-typing/repro_small.py", line 11, in <module>
    k[1, 1](result)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 861, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 994, in call
    kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 1002, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 1099, in compile
    kernel = _Kernel(self.py_func, argtypes, link=self.link,
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 538, in __init__
    cres = compile_cuda(self.py_func, types.void, self.argtypes,
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 163, in compile_cuda
    cres = compiler.compile_extra(typingctx=typingctx,
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 675, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 419, in compile_extra
    return self._compile_bytecode()
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 483, in _compile_bytecode
    return self._compile_core()
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 462, in _compile_core
    raise e
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 453, in _compile_core
    pm.run(self.state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/gmarkall/numbadev/numba/numba/core/typed_passes.py", line 396, in run_pass
    lower.lower()
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 136, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 190, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 216, in lower_function_body
    self.lower_block(block)
  File "/home/gmarkall/numbadev/numba/numba/core/lowering.py", line 230, in lower_block
    self.lower_inst(inst)
  File "/home/gmarkall/miniconda3/envs/numbanp120/lib/python3.9/contextlib.py", line 135, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/gmarkall/numbadev/numba/numba/core/errors.py", line 754, in new_error_context
    raise newerr.with_traceback(tb)
numba.core.errors.LoweringError: Failed in cuda mode pipeline (step: native lowering)
No definition for lowering <built-in method contains_impl of _dynfunc._Closure object at 0x7f35e557bd00>(unicode_type, unicode_type) -> bool

File "repro_small.py", line 7:
def k(result):
    result[0] = '123' in '12345'
    ^

During: lowering "$6contains_op.2 = $const2.0 in $const4.1" at /home/gmarkall/numbadev/issues/cuda-unicode-string-typing/repro_small.py (7)
```

I believe the `contains_impl` method it can't lower is from:

https://github.com/numba/numba/blob/ae4a0f18c399e69f854f13b592c5d07819f89bad/numba/cpython/charseq.py#L512-L529

If I pass in an array containing the string:

```python
from numba import cuda
import numpy as np


@cuda.jit
def k(result, p2):
    result[0] = '123' in p2[()]


y = np.array('12345')
result = np.zeros(1, dtype=np.bool_)

k[1, 1](result, y)
```

then typing seems to go extremely slowly and eventually fail. If I apply the following:

```diff
diff --git a/numba/core/typing/context.py b/numba/core/typing/context.py
index c46360eb9..44ae4e721 100644
--- a/numba/core/typing/context.py
+++ b/numba/core/typing/context.py
@@ -244,6 +244,7 @@ class BaseContext(object):
 
         if isinstance(func, types.Callable):
             # XXX fold this into the __call__ attribute logic?
+            print(f"Resolving call type, {func} == {args} -- {kws}")
             return func.get_call_type(self, args, kws)
```

a large amount of output is produced, with a portion of it being:

```
Resolving call type, Function(<built-in function eq>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, AssertionError == (Literal[str](PY_UNICODE_WCHAR_KIND unsupported),) -- {}
Resolving call type, AssertionError == (Literal[str](Unexpected unicode encoding encountered),) -- {}
Resolving call type, Function(<intrinsic _malloc_string>) == (int64, int64, int64, bool) -- {}
Resolving call type, Function(uint32) == (Literal[int](0),) -- {}
Resolving call type, Function(<function _set_code_point at 0x7f9bcc0cc790>) == (unicode_type, int64, uint32) -- {}
Resolving call type, Function(<built-in function eq>) == (int32, Literal[int](1)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<intrinsic set_uint8>) == (void*, int64, uint32) -- {}
Resolving call type, Function(<built-in function eq>) == (int32, Literal[int](2)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<intrinsic set_uint16>) == (void*, int64, uint32) -- {}
Resolving call type, Function(<built-in function eq>) == (int32, Literal[int](4)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<intrinsic set_uint32>) == (void*, int64, uint32) -- {}
Resolving call type, AssertionError == (Literal[str](Unexpected unicode representation in _set_code_point),) -- {}
Resolving call type, Function(<built-in function eq>) == (int32, Literal[int](1)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<intrinsic set_uint8>) == (void*, int64, uint32) -- {}
Resolving call type, Function(<built-in function eq>) == (int32, Literal[int](2)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<intrinsic set_uint16>) == (void*, int64, uint32) -- {}
Resolving call type, Function(<built-in function eq>) == (int32, Literal[int](4)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<intrinsic set_uint32>) == (void*, int64, uint32) -- {}
Resolving call type, AssertionError == (Literal[str](Unexpected unicode representation in _set_code_point),) -- {}
Resolving call type, Function(<function _kind_to_byte_width at 0x7f9bcc0cc940>) == (int64,) -- {}
Resolving call type, Function(<intrinsic _malloc_string>) == (int64, int64, int64, bool) -- {}
Resolving call type, Function(uint32) == (Literal[int](0),) -- {}
Resolving call type, Function(<function _set_code_point at 0x7f9bcc0cc790>) == (unicode_type, int64, uint32) -- {}
Resolving call type, Function(<class 'range'>) == (int64,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<class 'str'>) == (unicode_type,) -- {}
Resolving call type, Function(<class 'str'>) == ([unichr x 5],) -- {}
Resolving call type, Function(<built-in function len>) == ([unichr x 5],) -- {}
Resolving call type, Function(<built-in function eq>) == (Literal[int](0), Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function sub>) == (Literal[int](5), Literal[int](1)) -- {}
Resolving call type, Function(<built-in function lt>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<class 'bool'>) == (Literal[int](1),) -- {}
Resolving call type, Function(<intrinsic deref_uint32>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<class 'bool'>) == (Literal[int](1),) -- {}
Resolving call type, Function(<intrinsic deref_uint32>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function add>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function eq>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function sub>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function lt>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function add>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function eq>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function sub>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function lt>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function add>) == (int64, Literal[int](1)) -- {}
Resolving call type, BoundFunction((<class 'numba.core.types.npytypes.UnicodeCharSeq'>, '_get_kind') for [unichr x 5]) == () -- {}
Resolving call type, Function(<built-in function len>) == ([unichr x 5],) -- {}
Resolving call type, Function(<built-in function eq>) == (Literal[int](0), Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function sub>) == (Literal[int](5), Literal[int](1)) -- {}
Resolving call type, Function(<built-in function lt>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<class 'bool'>) == (Literal[int](1),) -- {}
Resolving call type, Function(<intrinsic deref_uint32>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<class 'bool'>) == (Literal[int](1),) -- {}
Resolving call type, Function(<intrinsic deref_uint32>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function add>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function eq>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function sub>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function lt>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function add>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function eq>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function sub>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<built-in function lt>) == (int64, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function add>) == (int64, Literal[int](1)) -- {}
Resolving call type, Function(<class 'range'>) == (int64,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<class 'bool'>) == (Literal[int](1),) -- {}
Resolving call type, Function(<intrinsic deref_uint32>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<class 'bool'>) == (Literal[int](1),) -- {}
Resolving call type, Function(<intrinsic deref_uint32>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function gt>) == (uint32, Literal[int](0)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function gt>) == (Literal[int](0), Literal[int](65535)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function gt>) == (Literal[int](0), Literal[int](255)) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function len>) == ([unichr x 5],) -- {}
Resolving call type, Function(<class 'range'>) == (int64,) -- {}
Resolving call type, Function(<function unicode_charseq_get_code at 0x7f9bcc01eb80>) == ([unichr x 5], int64) -- {}
Resolving call type, Function(<built-in function gt>) == (uint32, int64) -- {}
Resolving call type, Function(<class 'bool'>) == (bool,) -- {}
Resolving call type, Function(<built-in function gt>) == (int64, Literal[int](65535)) -- {}
```

(this is just at a random point where I hit ctrl+C and copied the last output).

Eventually the typing fails with:

```
Traceback (most recent call last):
  File "/home/gmarkall/numbadev/issues/cuda-unicode-string-typing/repro.py", line 13, in <module>
    k[1, 1](result, y)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 861, in __call__
    return self.dispatcher.call(args, self.griddim, self.blockdim,
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 994, in call
    kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 1002, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 1099, in compile
    kernel = _Kernel(self.py_func, argtypes, link=self.link,
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 538, in __init__
    cres = compile_cuda(self.py_func, types.void, self.argtypes,
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/gmarkall/numbadev/numba/numba/cuda/compiler.py", line 163, in compile_cuda
    cres = compiler.compile_extra(typingctx=typingctx,
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 675, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 419, in compile_extra
    return self._compile_bytecode()
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 483, in _compile_bytecode
    return self._compile_core()
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 462, in _compile_core
    raise e
  File "/home/gmarkall/numbadev/numba/numba/core/compiler.py", line 453, in _compile_core
    pm.run(self.state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 343, in run
    raise patched_exception
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 334, in run
    self._runPass(idx, pass_inst, state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_lock.py", line 35, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/gmarkall/numbadev/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/gmarkall/numbadev/numba/numba/core/typed_passes.py", line 105, in run_pass
    typemap, return_type, calltypes, errs = type_inference_stage(
  File "/home/gmarkall/numbadev/numba/numba/core/typed_passes.py", line 83, in type_inference_stage
    errs = infer.propagate(raise_errors=raise_errors)
  File "/home/gmarkall/numbadev/numba/numba/core/typeinfer.py", line 1071, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in cuda mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function contains>) found for signature:
 
 >>> contains([unichr x 5], Literal[str](123))
 
There are 14 candidate implementations:
  - Of which 13 did not match due to:
  Overload of function 'contains': File: <numerous>: Line N/A.
    With argument(s): '([unichr x 5], unicode_type)':
   No match.
  - Of which 1 did not match due to:
  Overload in function 'charseq_contains': File: numba/cpython/charseq.py: Line 512.
    With argument(s): '([unichr x 5], unicode_type)':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<class 'str'>) found for signature:
    
    >>> str([unichr x 5])
    
   There are 6 candidate implementations:
       - Of which 4 did not match due to:
       Overload of function 'str': File: <numerous>: Line N/A.
         With argument(s): '([unichr x 5])':
        No match.
       - Of which 2 did not match due to:
       Overload in function 'charseq_str': File: numba/cpython/charseq.py: Line 600.
         With argument(s): '([unichr x 5])':
        Rejected as the implementation raised a specific error:
          TypingError: Failed in nopython mode pipeline (step: nopython frontend)
        No implementation of function Function(<function _empty_string at 0x7f700c75c280>) found for signature:
         
         >>> _empty_string(int64, int64, bool)
         
        There are 2 candidate implementations:
              - Of which 2 did not match due to:
              Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba/core/extending.py: Line 159.
                With argument(s): '(int64, int64, bool)':
               Rejected as the implementation raised a specific error:
                 LoweringError: Failed in nopython mode pipeline (step: native lowering)
               NRT required but not enabled
               
               File "../../numba/numba/cpython/unicode.py", line 277:
               def _empty_string(kind, length, is_ascii=0):
                   <source elided>
                   char_width = _kind_to_byte_width(kind)
                   s = _malloc_string(kind, char_width, length, is_ascii)
                   ^
               
               During: lowering "s = call $10load_global.3(kind, char_width, length, is_ascii, func=$10load_global.3, args=[Var(kind, unicode.py:276), Var(char_width, unicode.py:276), Var(length, unicode.py:276), Var(is_ascii, unicode.py:276)], kws=(), vararg=None, target=None)" at /home/gmarkall/numbadev/numba/numba/cpython/unicode.py (277)
          raised from /home/gmarkall/numbadev/numba/numba/core/errors.py:754
        
        During: resolving callee type: Function(<function _empty_string at 0x7f700c75c280>)
        During: typing of call at /home/gmarkall/numbadev/numba/numba/cpython/charseq.py (609)
        
        
        File "../../numba/numba/cpython/charseq.py", line 609:
                def str_impl(s):
                    <source elided>
                    is_ascii = kind == 1 and s.isascii()
                    result = unicode._empty_string(kind, n, is_ascii)
                    ^
   
     raised from /home/gmarkall/numbadev/numba/numba/core/typeinfer.py:1071
   
   During: resolving callee type: Function(<class 'str'>)
   During: typing of call at /home/gmarkall/numbadev/numba/numba/cpython/charseq.py (528)
   
   
   File "../../numba/numba/cpython/charseq.py", line 528:
               def contains_impl(a, b):
                   return str(b) in str(a)
                   ^

  raised from /home/gmarkall/numbadev/numba/numba/core/typeinfer.py:1071

During: typing of intrinsic-call at /home/gmarkall/numbadev/issues/cuda-unicode-string-typing/repro.py (7)

File "repro.py", line 7:
def k(result, p2):
    result[0] = '123' in p2[()]
    ^
```

Related: #6897 - I think that might be the same issue, but the traceback / error has changed a little since that was reported.
user: gmarkall
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_7055: state: open
title: Make repr on `TypeRef` more verbose
body: It'd might be useful to make the repr on `TypeRef` more verbose? Using `class MyArray(types.Array): pass`, 
this:
```python
print(typeof(MyArray(types.float64, 3, 'C', True)))
```
gives
```
typeref[readonly array(float64, 3d, C)]
```
Maybe not for this PR though?

_Originally posted by @stuartarchibald in https://github.com/numba/numba/pull/7050#discussion_r637057893_
user: sklam
labels: good second issue: A good issue for second time contributors
issue_7043: state: open
title: register_jitable -ed function not recognized when used as arg to njit function
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

register_jitable-ed function is not recognized when used as arg to njit-ed function.

Numba version: 0.53.1
Code:
```py
import numba as nb
import numba.extending

@nb.extending.register_jitable
def g(x):
    return 2*x

@nb.njit
def f(g,x):
    x+=1
    return g(x)

f(g,2)
```
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-1-cbb9b70cf0f8> in <module>
     11     return g(x)
     12 
---> 13 f(g,2)

~/miniconda3/lib/python3.9/site-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    418                 e.patch_message(msg)
    419 
--> 420             error_rewrite(e, 'typing')
    421         except errors.UnsupportedError as e:
    422             # Something unsupported is present in the user code, add help info

~/miniconda3/lib/python3.9/site-packages/numba/core/dispatcher.py in error_rewrite(e, issue_type)
    359                 raise e
    360             else:
--> 361                 raise e.with_traceback(None)
    362 
    363         argtypes = []

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type pyobject
During: typing of argument at <ipython-input-1-cbb9b70cf0f8> (10)

File "<ipython-input-1-cbb9b70cf0f8>", line 10:
def f(g,x):
    x+=1
    ^

This error may have been caused by the following argument(s):
- argument 0: Cannot determine Numba type of <class 'function'>
```

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Swaping register_jitable for njit works:

```py
import numba as nb
import numba.extending

# @nb.extending.register_jitable
@nb.njit
def g(x):
    return 2*x

@nb.njit
def f(g,x):
    x+=1
    return g(x)

f(g,2)
```
```
6
```

user: LunarLanding
issue_7035: state: open
title: `DEBUG_JIT` doesn't work for CUDA
body: See also #7034.

`config.DEBUG_JIT` it doesn't work for CUDA, giving errors like:

```
TypeError: Failed in cuda mode pipeline (step: native lowering) Type of #1 arg mismatch: i8* != i8 addrspace(4)*
```

This probably needs an appropriate implementation of `debug_print` for the CUDA target context.

If it is added, it should be recommended that kernels are only launched with a small number of threads (perhaps 1) when `DEBUG_JIT` is turned on.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_7034: state: open
title: `DEBUG_JIT` is undocumented
body: Setting `NUMBA_DEBUG_JIT` to `1` results in the printing of debug info in lowered code, using 

https://github.com/numba/numba/blob/d4d09f378c471b702c5ec0f9a9f0f32a4637f6c7/numba/core/lowering.py#L265-L267

e.g.

https://github.com/numba/numba/blob/d4d09f378c471b702c5ec0f9a9f0f32a4637f6c7/numba/core/lowering.py#L209-L210

This isn't documented, and it doesn't work for CUDA, giving errors like:

```
TypeError: Failed in cuda mode pipeline (step: native lowering) Type of #1 arg mismatch: i8* != i8 addrspace(4)*
```
Some questions:

* Should this be documented? Or is this an internal-only debugging tool?
* Either way, is it a bug that it doesn't work for CUDA? It could be made to work for CUDA, but care would need to be taken to not launch debugged kernels with too many threads or the output will be unintelligible.

cc / with thanks to @MegaIng 
user: gmarkall
issue_7033: state: open
title: Unsupported op-code encountered: list_to_tuple (only with Python 3.9)
body: Checked with Numba 0.53.1 and Python 3.9.1:
```python
if __name__ == '__main__':
    import numba
    @numba.njit()
    def fun():
        return None(*None, (None if None else None))
    fun()
```
gives:
```
numba.core.errors.UnsupportedError: Failed in nopython mode pipeline (step: nopython frontend)
Unsupported op-code encountered: list_to_tuple(info=('$phi20.1',))
File "test.py", line 5:
    def fun():
        return None(*None, (None if None else None))
```

user: slayoo
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_7029: state: open
title: `.view()` for NumPy types broken if the view type is a complex type
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit
import numpy as np

@njit
def foo(x):
    return x.view(np.complex64)

foo(1)
```
does:
```
cpython/unsafe/numbers.py", line 18, in viewer
                      assert 0, "unreachable"
                  AssertionError: unreachable
```
user: stuartarchibald
labels: bug - ice: Bugs: internal compiler error
issue_7028: state: open
title: memory leak caused by racing conditions in parallel loop
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Simple reproducing example:

```python
# bug.py

from time import sleep
import numpy as np
from numba import njit, prange

@njit(parallel=IS_PARALLEL)
def run_iters(n_tries, size):
    res = np.zeros(size, dtype=np.float64)
    for n in prange(n_tries):
        tmp = np.zeros(size, dtype=np.float64)
        res += tmp
    return res


if __name__ == "__main__":
    n_tries = 200
    size = 6000
    for _ in range(100):
        res = run_iters(n_tries, size)
        sleep(0.1) # allow counter to measure performance
```

When `IS_PARALLEL` is `False`, no memory leak occurs. To check this I run `mprof run --include-children python bug.py` using the standard `memory_profiler` package. The exported profile I get with `mprof plot --output memory.png` is shown below:

![image](https://user-images.githubusercontent.com/5283394/118287721-6843a300-b4dc-11eb-86b2-ef907558a5ba.png)


However, when `IS_PARALLEL` is `True`, I get completely different picture:

![image](https://user-images.githubusercontent.com/5283394/118287521-316d8d00-b4dc-11eb-808f-d7384ff706da.png)


The leak gets worse as the size of arrays and the number of internal iterations in the loop increases. In my experiments with real code I observed several hundreds gigabytes of RAM consumed by the process, where normally it requires less then a gigabyte.


Note that when racing conditions are resolved via accumulation of temporary results, everything works normally again. I.e., whis this modification:
```python
@njit(parallel=True)
def run_iters(n_tries, size):
    res = np.zeros((n_tries, size), dtype=np.float64)
    for n in prange(n_tries):
        tmp = np.zeros(size, dtype=np.float64)
        res[n, :] += tmp
    return res.sum(axis=0)
```

I get the following memory profile:

![image](https://user-images.githubusercontent.com/5283394/118286992-b5734500-b4db-11eb-9f59-939a7863504b.png)

The problem with this workaround is that `n_tries` in my real experiments is very large, so it's not an option to accumulate intermediate results.
user: evfro
labels: bug - memory leak: Memory leak
issue_7014: state: open
title: [BUG] cannot pickle generator when there is only one function that uses input
body: The following code gives me pickle error:

```
import numba
import numpy as np

kws = {'cache': True}

@numba.njit(**kws)
def g(raw_data):
    for i in range(100000):
        yield i

@numba.jit(**kws)
def calibration():
    for i in range(1):
        data = input("Input anything: ").encode()
        for each in g(data):
            pass

calibration()
```

Gave me:

```
Input anything: ecqcfe
Traceback (most recent call last):
  File "test.py", line 18, in <module>
    calibration()
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 439, in _c
ompile_for_args
    raise e
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 372, in _c
ompile_for_args
    return_val = self.compile(tuple(argtypes))
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 915, in co
mpile
    self._cache.save_overload(sig, cres)
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/caching.py", line 661, in save_
overload
    self._save_overload(sig, data)
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/caching.py", line 671, in _save
_overload
    self._cache_file.save(key, data)
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/caching.py", line 489, in save
    self._save_data(data_name, data)
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/caching.py", line 547, in _save
_data
    data = self._dump(data)
  File "/home/nobodyxu/.local/lib/python3.8/site-packages/numba/core/caching.py", line 560, in _dump
    return pickle.dumps(obj, protocol=-1)
_pickle.PicklingError: Can't pickle <function g at 0x7f5edfa051f0>: it's not the same object as __ma
in__.g
```

However, if I change my code a little bit by adding another normal function that is pure:

```
import numba
import numpy as np

kws = {'cache': True}

@numba.njit(**kws)
def g(raw_data):
    for i in range(100000):
        yield i

@numba.njit(**kws)
def f():
    l = []
    for each in g(b"anything"):
        l.append(each)
    return l
f()

@numba.jit(**kws)
def calibration():
    for i in range(1):
        data = input("Input anything: ").encode()
        for each in g(data):
            pass

calibration()
```

Then it works as expected.

The numba on my computer is installed via `pip3`:

```
version_info(major=0, minor=53, patch=1, short=(0, 53), full=(0, 53, 1), string='0.53.1', tuple=('0', '53', '1'), git_revision=None)                                                                    
```

Might be related to #2868 ?
user: NobodyXu
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_7012: state: open
title: pow() producing incorrect results for negative integer exponent 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
from numba import njit

@njit
def foo(x):
    print(pow(2, x))

foo(-2)
foo.py_func(-2)
```
produces:
```
0
0.25
```

from a quick look at the source, not sure that this is quite right
https://github.com/numba/numba/blob/51978769c319b50404ac2ea972aa1e8c0aa9f0a4/numba/cpython/numbers.py#L230-L231 also, am not convinced this is valid in the case of a negative exponent https://github.com/numba/numba/blob/51978769c319b50404ac2ea972aa1e8c0aa9f0a4/numba/cpython/numbers.py#L212
user: stuartarchibald
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_7002: state: open
title: Purely scalar inputs break njit'd functions that utilize np.stack
body: Hello!

I have a edge case issue with a njited function that utilizes `np.stack`. A minimum working example is below…

```
import numpy as np
from numba import njit

def f(x, y):

    x2 = x**2
    y2 = y**2

    result = np.stack((x2, y2))

    return result

fn = njit(f)

x_array = np.linspace(0., 10., 5)
y_array = np.linspace(-1., 1., 5)

x_scalar = 10.
y_scalar = -0.5
```

The purely Python implementation returns a 2d array when `f(x_array, y_array)` is called and a 1d array when calling `f(x_scalar, y_scalar)` (specifically: `array([100.  ,   0.25])`). The njit’d function works fine for `fn(x_array, y_array)` but fails for `fn(x_scalar, y_scalar)` with the error:

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function stack at 0x000002071A9750D0>) found for signature:
>>> stack(UniTuple(float64 x 2))
```

I posted this issue on [discourse ](https://numba.discourse.group/t/intended-behavior-njitd-np-stack-does-not-seem-to-work-with-scalars/704/3) and it does look like it may be an unsupported part of `np.stack`, but I don't believe this is mentioned in the numba [docs](https://numba.readthedocs.io/en/stable/reference/numpysupported.html).

As a user mentioned on discourse, my specific use case can be fixed by adding:

```
x2 = np.asarray(x2)
y2 = np.asarray(y2)
```

right before `np.stack()` is called.

I am running `numba 0.53.1` and `numpy 1.19.2` under `python 3.9.4`.
user: jrenaud90
issue_6998: state: open
title: np.linalg.solve unexpectedly returns an `F_CONTIGUOUS` array for `C_CONTIGUOUS` inputs
body: ## Reporting a bug

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

## Reproducer

```python
import numpy as np
from numba import njit


def f(x, y):
    return np.linalg.solve(x, y)


if __name__ == "__main__":

    x = np.array([[1, 2], [3, 5]], dtype=np.float64)
    y = np.eye(2, dtype=np.float64)

    g = njit()(f)

    numpy_result = f(x, y)
    numba_result = g(x, y)

    print(numpy_result.flags)
    print(numba_result.flags)
```

This prints the following:
```
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False

  C_CONTIGUOUS : False
  F_CONTIGUOUS : True
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
```
I am not sure if this is the expected/desired behaviour. I encountered this when attempting to feed the results of `np.linalg.solve` into `np.dot` and saw:
```
NumbaPerformanceWarning: np.dot() is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 1d, C))
```

user: JSKenyon
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6993: state: open
title: Generators don't get cleaned up on
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG ) (current master).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

This came to light while trying to figure out what I did wrong in #6992. This is somewhat related to #5350, but I think a slightly different error (or the root of the other error. idk).

```
import gc

from numba import njit
from numba.core.runtime import rtsys
from numba.typed import List

@njit
def gen(n):
    l = List()
    for i in range(n):
        yield i
    l.append(1)

def main():
    a = gen(10)
    b = gen(10)
    for t in zip(a,b):
        pass


print(rtsys.get_allocation_stats())

main()
gc.collect()
print(rtsys.get_allocation_stats())
```

As can be seen from the output of the above code, only one of the lists gets freed. Notice how I am not returning the Lists, so it should be very clear who has to clean it up. The core problem here is that the generator `b` does not get exhausted and apparently, generators don't get cleaned up correctly on GC. Via `weakref`, I did check that both generators get GC.
user: MegaIng
labels: bug - memory leak: Memory leak
issue_6992: state: open
title: Moved typedlist __iter__ into njit code instead of just __getitem__
body: <!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->


This is a very small change rewriting `typed.List.__iter__` to use a new function `_iter` that implements the entire loop in `njit` code, creating a speed-up of 30x (probably because of less calls across the compilation boundaries).

I didn't create new unittest because I assume that typed List is already well tested and I am not changing any user facing behaviour/adding new features.
user: MegaIng
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_6980: state: open
title: jax.ndarray.shape not working in @njit with error `unknown attribute shape of readonly buffer
body: jax arrays define the __array__ interface so i expected them to work. Not writeable, of course, but at least readable.

Happening because `numba.typeof(jax.numpy.ones(3))` is a Buffer and not a Array 

MWE:
```python
>>> import jax, numba
>>> a=jax.numpy.ones((3,4))
>>> @numba.njit
... def test(x):
...   return x.shape[0]
... 
>>> test(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/filippovicentini/Documents/pythonenvs/netket_env/lib64/python3.8/site-packages/numba/core/dispatcher.py", line 420, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/filippovicentini/Documents/pythonenvs/netket_env/lib64/python3.8/site-packages/numba/core/dispatcher.py", line 361, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'shape' of type readonly buffer(float64, 2d, C)

File "<stdin>", line 3:
<source missing, REPL/exec in use?>

During: typing of get attribute at <stdin> (3)

File "<stdin>", line 3:
<source missing, REPL/exec in use?>
```
user: PhilipVinc
issue_6976: state: open
title: parallel mode ignores divide by zero errors, sometimes fills with nonsense
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->


## Case 1 nested

The size the array seems to matter for whether the output is non-deterministic

```python
import numpy as np
from numba import njit, prange
```

```python
def foo(x, y):
    return x / y

cfoo = njit(foo)

def bar(x, y):
    out = np.zeros(len(x))
    for i in prange(len(x)):
        out[i] = cfoo(x[i], y)
    return out
```

Errors with no parallelization, the expected result

```python
njit(bar)(np.ones(100), 0)
```

```pytb
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
<ipython-input-42-aebfaf53ad4a> in <module>
----> 1 njit(bar)(np.ones(100), 0)

ZeroDivisionError: division by zero
```

With parallelization, no error, and nonsense results

```python
njit(parallel=True)(bar)(np.ones(100), 0)
```

```
array([ 0.00000000e+000, -1.36311572e+057, -1.36311572e+057,
       -1.36311572e+057, -1.36311572e+057, -1.36311572e+057,
       -1.36311572e+057,  0.00000000e+000, -1.36311572e+057,
       -1.36311572e+057, -1.36311572e+057, -1.36311572e+057,
       -1.36311572e+057, -1.36311572e+057,  0.00000000e+000,
       -1.36311572e+057, -1.36311572e+057, -1.36311572e+057,
       -1.36311572e+057, -1.36311572e+057, -1.36311572e+057,
        0.00000000e+000, -1.36311572e+057, -1.36311572e+057,
       -1.36311572e+057, -1.36311572e+057, -1.36311572e+057,
       -1.36311572e+057,  0.00000000e+000, -1.36311572e+057,
       -1.36311572e+057, -1.36311572e+057,  2.41298017e-314,
       -1.49166815e-154,  0.00000000e+000,  0.00000000e+000,
        2.41463797e-314,  0.00000000e+000,  0.00000000e+000,
        6.94200297e-310,  0.00000000e+000, -1.49166815e-154,
        1.38338381e-322,  2.33419537e-313,  1.28303992e-138,
        1.28528994e-138,  0.00000000e+000,  1.28765272e-138,
        1.28527008e-138,  1.28642776e-138,  1.28643801e-138,
        1.28663790e-138,  0.00000000e+000,  1.28747333e-138,
        1.28748358e-138,  4.94065646e-324,              nan,
        6.94199943e-310,  0.00000000e+000,  8.48798317e-314,
        1.27319747e-313,  1.83684208e-313,  1.69759663e-313,
        5.56268465e-308,  0.00000000e+000,  2.41108763e-314,
        2.41098414e-314,  7.53351297e-320, -1.49166815e-154,
       -1.29074172e-231,  0.00000000e+000,  1.28617150e-138,
        4.33875185e-311, -1.49166815e-154,  2.41463797e-314,
        2.41465960e-314,  0.00000000e+000,  2.41465859e-314,
        2.12199579e-314,  4.94065646e-324,  0.00000000e+000,
        0.00000000e+000,  0.00000000e+000,  8.51419406e-308,
        2.41465605e-314,  2.41465778e-314,  2.41465865e-314,
        2.41465960e-314,  0.00000000e+000,  2.41465866e-314,
        2.41465867e-314,  2.41465882e-314,  2.41465883e-314,
        2.41465947e-314,  0.00000000e+000,  9.73469813e-309,
       -1.49166815e-154,  1.73060171e-077,  2.41463799e-314,
        2.41465867e-314])
```

## Case 2 non-nested

```python
def baz(x, y):
    out = np.zeros(len(x))

    for i in numba.prange(len(x)):
        out[i] = x[i] / y

    return out
```

This at least follows numpy's semantics, though numpy would warn.

```python
njit(parallel=True)(baz)(np.ones(100), 0)
```

```
array([inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf,
       inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf,
       inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf,
       inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf,
       inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf,
       inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf,
       inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf, inf,
       inf, inf, inf, inf, inf, inf, inf, inf, inf])
```

## Expected results

I would have expected all these cases to error, following from the [documentation for `jit`](http://numba.pydata.org/numba-doc/latest/reference/jit-compilation.html#jit-functions).

## Version info

```
print(numba.__version__)
print(numba.threading_layer())
# 0.53.1
# workqueue
```
user: ivirshup
labels: discussion: An issue requiring discussion
issue_6972: state: open
title: Wrapper or type to avoid inlining
body: Functions that take other functions as arguments are an essential part of many numeric libraries, including those dealing with minimizers, solvers and integrators among others. While recent numba version have seen an improvement in relation to this (mainly due to #5579 and #6373) the user experience is still inconsistent. 

Consider the following example
```python
# solver library code
def solver(rhs, starting_value):
    # Some cool code here

# user code
def my_problem(x):
    # some code here

solution = solver(my_problem, 0)
```

Depending on the content of `my_problem` and `solver` sometimes the cache will work and sometimes will not (Check this out for a great example of this #6772 )

In my opinion, the problem is that we are not telling numba that `rhs` is a function pointer and therefore should never be inlined. In other words, we want to be able to compile the solver library ahead of time and independent of what the user will provide.

The current inability to do this makes it very difficult to provide numba libraries that deal with minimizers, solvers and intergrators as there is always a very large compilation overhead that cannot be cached. We are seeing this, for example, in https://github.com/hgrecco/numbakit-ode The integration itself beats SciPy code by a factor of 10 but warming up takes a very long time that makes it unusable for small integrations.

My proposed solution is one of the following:
1. Treat arguments with `FunctionType` as function pointers.
2. Add a boolean flag to `FunctionType` to indicate if it should be treated like a pointers.
3. Create `FunctionPointerType` to indicate that an argument should never be inlined.

As a very frequent user of the argumentless `njit` I understand that my solutionm might not be allways welcome. Library maintainers will need to explicitely add a signature and library users will need to adhere to it. But in any case, this will still better than coding in Cython or using C, C++ or fortran where we also need to use a signature. In addition, libraries like https://github.com/hgrecco/numbakit-anjit/ could be use to help with adding a signature.

See also:
- https://numba.discourse.group/t/using-the-cache/666
user: hgrecco
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_6967: state: open
title: CUDA vectorize returns array from scalar input
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import vectorize, float64, boolean
import math

for target in ('cpu', 'cuda'):
    print(f"{target}".center(80, '-'))

    @vectorize([boolean(boolean), float64(float64)], target=target)
    def cuda_cos(x):
            return math.cos(x)

    x = cuda_cos(1.2)
    print(x, type(x))

    y = cuda_cos(False)
    print(y, type(y))
```
does this:
```
--------------------------------------cpu---------------------------------------
0.3623577544766736 <class 'numpy.float64'>
True <class 'numpy.bool_'>
--------------------------------------cuda--------------------------------------
[0.36235775] <class 'numpy.ndarray'>
[ True] <class 'numpy.ndarray'>
```
note the CUDA target returning one element `ndarray`s.

user: stuartarchibald
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_6962: state: open
title: Parallelism that worked in 0.52 no longer works in 0.53.1
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Hello!  First off, thanks for developing and maintaining numba! 

I've encountered an issue when using `njit` with `parallel=True`.  In numba version 0.53.1 (and 0.53.0) the following minimal(ish) working example produces the wrong result, whereas in version 0.52 it does not.

```
import numpy as np
from numba import njit


EPSILON = 1e-100


@njit('float64[:, :](float64[:, :])', parallel=True)
def _invert_nat_cat_2D(probs):
    to_return = np.zeros((probs.shape[0], probs.shape[1] + 1))
    for i in range(to_return.shape[0]):
        ext_probs = np.zeros((probs.shape[1] + 1), dtype=np.float64)
        ext_probs[:-1] = probs[i]
        ext_probs = np.exp(ext_probs - np.max(ext_probs))
        ext_probs /= np.sum(ext_probs)
        to_return[i] = np.maximum(ext_probs, EPSILON)
    return to_return

def _invert_nat_cat_2D_safe(probs):
    to_return = np.zeros((probs.shape[0], probs.shape[1] + 1))
    for i in range(to_return.shape[0]):
        ext_probs = np.zeros((probs.shape[1] + 1), dtype=np.float64)
        ext_probs[:-1] = probs[i]
        ext_probs = np.exp(ext_probs - np.max(ext_probs))
        ext_probs /= np.sum(ext_probs)
        to_return[i] = np.maximum(ext_probs, EPSILON)
    return to_return

x = np.arange(16, dtype=np.float64).reshape((4, 4))
print('unsafe', _invert_nat_cat_2D(x))
print('safe', _invert_nat_cat_2D_safe(x))
assert np.allclose(_invert_nat_cat_2D(x), _invert_nat_cat_2D_safe(x))
```

Using numba=0.52, I get (as expected):
```
unsafe [[3.10627741e-02 8.44373745e-02 2.29524581e-01 6.23912497e-01
  3.10627741e-02]
 [3.20397904e-02 8.70931799e-02 2.36743808e-01 6.43536392e-01
  5.86829230e-04]
 [3.20582585e-02 8.71433816e-02 2.36880271e-01 6.43907335e-01
  1.07543476e-05]
 [3.20585970e-02 8.71443016e-02 2.36882771e-01 6.43914133e-01
  1.96974828e-07]]
safe [[3.10627741e-02 8.44373745e-02 2.29524581e-01 6.23912497e-01
  3.10627741e-02]
 [3.20397904e-02 8.70931799e-02 2.36743808e-01 6.43536392e-01
  5.86829230e-04]
 [3.20582585e-02 8.71433816e-02 2.36880271e-01 6.43907335e-01
  1.07543476e-05]
 [3.20585970e-02 8.71443016e-02 2.36882771e-01 6.43914133e-01
  1.96974828e-07]]
```

Using numba==0.53.1, the output is always:
```
unsafe [[0.2 0.2 0.2 0.2 0.2]
 [0.2 0.2 0.2 0.2 0.2]
 [0.2 0.2 0.2 0.2 0.2]
 [0.2 0.2 0.2 0.2 0.2]]
safe [[3.10627741e-02 8.44373745e-02 2.29524581e-01 6.23912497e-01
  3.10627741e-02]
 [3.20397904e-02 8.70931799e-02 2.36743808e-01 6.43536392e-01
  5.86829230e-04]
 [3.20582585e-02 8.71433816e-02 2.36880271e-01 6.43907335e-01
  1.07543476e-05]
 [3.20585970e-02 8.71443016e-02 2.36882771e-01 6.43914133e-01
  1.96974828e-07]]
Traceback (most recent call last):
  File "numba_bug.py", line 32, in <module>
    assert np.allclose(_invert_nat_cat_2D(x), _invert_nat_cat_2D_safe(x))
AssertionError
```

If I drop the `parallel=True` in numba==0.53.1, things run as expected.

I was able to reproduce this using python==3.7.10 on my macbook (OS==11.2.3) as well as on a linux server (python==3.6.1).

I apologize if this code is expected to fail, but the fact that it works using previous versions of numba, and this line 

> Array assignment in which the target is an array selection using a slice or a boolean array, and the value being assigned is either a scalar or another selection where the slice range or bitarray are inferred to be compatible.

from https://numba.pydata.org/numba-doc/latest/user/parallel.html makes me think this should be supported, and so it may be a bug.

Thanks!
user: jeffspence
labels: bug - regression: A regression against a previous version of Numba
issue_6960: state: open
title: Regression with parfor in numba=0.53.1 when aliased arrays are struct attributes
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi, 

It seems in numba=0.53.x a new problem was introduced related to parfor's alias analysis, specifically `LoweringError `appears when compiled code uses an array attribute of some struct in several branches that further use this array in a prange. 

It can be reproduced with:
```
import numpy as np
from numba import njit
from numba.core import cgutils, types
from numba.extending import (
    make_attribute_wrapper,
    models,
    register_model,
    type_callable,
    lower_builtin,
)

def make_dummy_type():
    class Dummy(object):
        def __init__(self, data):
            self.data = data

    class DummyType(types.Type):
        def __init__(self, data):
            self.data = data
            super(DummyType, self).__init__(name="Dummy({})".format(self.data))

    @register_model(DummyType)
    class DummyModel(models.StructModel):
        def __init__(self, dmm, fe_type):
            members = [("data", fe_type.data)]
            models.StructModel.__init__(self, dmm, fe_type, members)

    make_attribute_wrapper(DummyType, "data", "_data")

    @type_callable(Dummy)
    def type_dummy(context):
        def typer(value):
            return DummyType(value)
        return typer

    @lower_builtin(Dummy, types.Array)
    def impl_dummy(context, builder, sig, args):
        typ = sig.return_type
        [value] = args
        dummy = cgutils.create_struct_proxy(typ)(context, builder)
        dummy.data = value
        if context.enable_nrt:
            context.nrt.incref(builder, sig.args[0], value)
        return dummy._getvalue()

    # Store attributes
    return Dummy, DummyType

Dummy, DummyType = make_dummy_type()


''' This version fails with KeyError on size variable that's been removed'''
@njit(parallel=True)
def test_impl(arr, cond):

    dobj = Dummy(arr)
    if not cond:
        return dobj._data.min()

    return dobj._data.max()


''' And this doesn't and can be kind of workaround'''
@njit(parallel=True)
def test_impl_wa(arr, cond):

    dobj = Dummy(arr)
    dobj_data = dobj._data
    if not cond:
        return dobj_data.min()

    return dobj_data.max()


data = np.arange(20)
print(test_impl(data, True))
# print(test_impl_wa(data, True))
```

Gives:
> ...
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\parfors\parfor_lowering.py", line 69, in _lower_parfor_parallel
>     lowerer.lower_inst(instr)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 370, in lower_inst
>     val = self.lower_assign(ty, inst)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 544, in lower_assign
>     return self.lower_expr(ty, value)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 1070, in lower_expr
>     res = self.lower_call(resty, expr)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 806, in lower_call
>     res = self._lower_call_normal(fnty, expr, signature)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 1031, in _lower_call_normal
>     fnty, signature, expr.args, expr.vararg, expr.kws,
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 746, in fold_call_args
>     stararg_handler)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typing\templates.py", line 239, in fold_arguments
>     ba.arguments[name] = normal_handler(i, param, ba.arguments[name])
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 729, in normal_handler
>     return self._cast_var(var, signature.args[index])
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 707, in _cast_var
>     val = self.loadvar(var.name)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 1292, in loadvar
>     ptr = self.getvar(name)
>   File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\lowering.py", line 1286, in getvar
>     return self.varmap[name]
> KeyError: '$26load_attr.1_size0.97'
> 
> During handling of the above exception, another exception occurred:
> ...
> numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
> '$26load_attr.1_size0.97'
> 
> File "numba\parfors\parfor.py", line 134:
>         def min_1(in_arr):
>             <source elided>
>             val = numba.cpython.builtins.get_type_max_value(in_arr.dtype)
>             for i in numba.parfors.parfor.internal_prange(len(in_arr)):
>             ^
> 
> During: lowering "id=1[LoopNest(index_variable = parfor_index.102, range = (0, $26load_attr.1_size0.97, 1))]{173: <ir.Block at 
> 

Debugging shows that it was first seen with #5936, and the root cause is probably in alias analysis and the fact that the shape and size definitions for aliased arrays are now inserted only once and it may turn up first in the block that won't directly use them, so despite other blocks still refer to them, the definitions are removed during simplify, i.e.

```
CFG adjacency lists:
{0: [14, 107],
 14: [24],
 24: [87, 89],
 87: [24],
 89: [],
 107: [171],
 171: [173, 191],
 173: [171],
 191: []}

-----------------------IR after array analysis: test_impl-----------------------
...
label 14:
    $26load_attr.1 = getattr(value=dobj, attr=_data) ['$26load_attr.1', 'dobj']
    $26load_attr.1_shape.96 = getattr(value=$26load_attr.1, attr=shape) ['$26load_attr.1', '$26load_attr.1_shape.96']
    $26load_attr.1_size0.97 = static_getitem(value=$26load_attr.1_shape.96, index=0, index_var=None) ['$26load_attr.1_shape.96', '$26load_attr.1_size0.97']
    $np_g_var.0 = global(np: <module 'numpy' from 'C:\\Users\\akozlov\\AppData\\Local\\Continuum\\anaconda3\\envs\\NUMBA_MASTER_4\\lib\\site-packages\\numpy\\__init__.py'>) ['$np_g_var.0']
...

--------------------------IR after simplify: test_impl--------------------------
...
label 14:
    $in_arr.48.107 = getattr(value=$dobj.106, attr=_data) ['$dobj.106', '$in_arr.48.107']
    $np_g_var.90 = global(np: <module 'numpy' from 'C:\\Users\\akozlov\\AppData\\Local\\Continuum\\anaconda3\\envs\\NUMBA_MASTER_4\\lib\\site-packages\\numpy\\__init__.py'>) ['$np_g_var.90']
    $np_typ_var.91 = const(str, int32)       ['$np_typ_var.91']
    $dtype_attr_var.92 = getattr(value=$np_g_var.90, attr=dtype) ['$dtype_attr_var.92', '$np_g_var.90']
    $dtype_var.93 = call $dtype_attr_var.92($np_typ_var.91, func=$dtype_attr_var.92, args=[Var($np_typ_var.91, parfor.py:133)], kws=(), vararg=None) ['$dtype_attr_var.92', '$dtype_var.93', '$np_typ_var.91']
    $60get_iter.8.75 = getiter(value=$58call_method.7.74) ['$58call_method.7.74', '$60get_iter.8.75']
---begin parfor 1---
index_var =  parfor_index.102
params =  None
races =  {'val.66'}
LoopNest(index_variable = parfor_index.102, range = (0, $26load_attr.1_size0.97, 1))
```

BR,
Alexey.
user: kozlov-alexey
labels: bug - regression: A regression against a previous version of Numba
issue_6956: state: open
title: Excessive recompilation due to use of `literally` and potentially unaware in memory cache.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This is quite hard to describe, there's some background information here: https://numba.discourse.group/t/performance-discrepancy-between-jit-generated-jit-overload/671/6

Essentially, the use of `literally` is causing recompilation of functions when there's no need as they have been previously compiled with exactly the same arguments.

Example:
```python
from numba import njit, types, literally
from numba.extending import overload
import numpy as np

# ------------------------------------------------------------------------------
print(f'Standard behaviour'.center(80, '='))
# This example shows normal behaviour...

def baz(x):
    ...

@overload(baz, inline="always")
def ol_baz(x):
    print('ol baz', x)
    print("ol baz, returning")
    return lambda x: print('real impl')

@njit
def foo(x):
    baz(x)

for i in range(4):
    print(f'run {i}'.center(80, '-'))
    foo('dispatch_string')
    print(foo.signatures)

# ------------------------------------------------------------------------------
print(f'Erroneous behaviour'.center(80, '='))
# This example shows the bug...

def bar(x):
    ...

@overload(bar, inline="always")
def ol_bar(x):
    print('ol bar', x)
    if not isinstance(x, types.Literal):
        print("ol bar: literal escape")
        return lambda x: literally(x)

    if x.literal_value == "dispatch_string":
        print("ol bar, returning")
        return lambda x: print('real impl')

@njit
def foo(x):
    bar(x)

# NOTE: Each loop iteration causes a recompilation?!
for i in range(4):
    print(f'run {i}'.center(80, '-'))
    foo('dispatch_string')
    print(foo.signatures)
```
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
performance - compile time: Performance issue occurring at compile time.
issue_6954: state: open
title: @vectorize with *args failing
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit, vectorize
import numpy as np

@vectorize
def foo(*args):
    return 1

foo(np.zeros(1))
```
produces:
```
numba/core/untyped_passes.py", line 105, in run_pass
    raise TypeError("Signature mismatch: %d argument types given, "
TypeError: Failed in object mode pipeline (step: fix up args)
Signature mismatch: 0 argument types given, but function takes 1 arguments
```

user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6952: state: open
title: Vectorized ufuncs don't respect `casting` keyword argument
body: Despite passing `casting="unsafe"` to a numba-generated ufunc, numba still uses `casting rule ''safe''`.

## Minimal example

Python version: 3.8.5
Numpy version: 1.17.4
Numba version: 0.53.1

```python
import numba
import numpy as np

def my_add(a, b):
    return a + b

my_ufunc = numba.vectorize("uint8(uint8, uint8)", nopython=True)(my_add)

a = np.array([1,2,3], dtype=np.uint8)
print(a)
b = np.array([2,3,4], dtype=np.int16)
print(b)

c = my_ufunc(a, b, casting="unsafe")
print(c)
```

## Current output
```
$ python3 bug.py
[1 2 3]
[2 3 4]
Traceback (most recent call last):
  File "bug.py", line 14, in <module>
    c = my_ufunc(a, b, casting="unsafe")
TypeError: ufunc 'my_add' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''
```

## Expected output
```
$ python3 bug.py
[1 2 3]
[2 3 4]
[3 5 7]
```
user: mhostetter
issue_6947: state: open
title: Losing local struct variable pointer in jitted function
body: # Bug description
I'm aware that numpy struct is a reference type, not value type, but when it's used in function, Python copies struct values and "forgets" links to it (see example **fill_python** and **fill_jit_global_struct** functions below). Anyhow, numba behaviour differs dramatically from pure Python, so I consider it as a bug.
First example contains next tests:
1. We assure that struct is really a reference type
2. Pure python function **fill_python** correctly initialize local struct variable **s** with zeros and copies them to our array
3. Jitted function **fill_jit** fully ignores zero-initializing leaving only manual assignment to **field1**. Probably its pointer is lost instantly.
4. **fill_jit_element_wise** tries to copy struct element-wise, but also fails, so reason is the same as in pt. 4
5. **fill_jit_global_struct** uses previously initialized global struct global_s and succeeds
6. We make sure that however _global_s_ was modified in function and assigned to array elements, but it's not linked to the last element of array (so in non-jitted function too)

Second example uses jitclass and shows us something new. Originally I found this issue and writing this ticket I tried to avoid jitclass in my example, but couldn't reproduce this bug with "simple functions". The thing is that if the struct is initialized INSIDE the loop, all works correctly (**list_jit_inside_loop**). But if it's initialized outside the loop, its pointer is lost like in pt. 3. Of course tests 2 and 5 work fine, I didn't include them here.


# Example 1
```python
from numba import njit
import numpy as np


Struct = np.dtype( [('field1', 'i4'), ('field2', 'i4' )])

print('-----======= check that struct is a reference type')
a = np.full(3, -1, dtype = Struct)
print("a[1]['field1'] = ", a[1]['field1'])
s1 = a[1]
s1['field1'] = 5
print("a[1]['field1'] = ", a[1]['field1'])
print()



# initialize array
a = np.full(3, -1, dtype = Struct)

def fill_python(a, n):
    # initialize single struct
    s = np.zeros(1, dtype = Struct)[0]
    for i in range(n):
        s['field1'] = i
        a[i] = s


print('-----======= fill_python')
a[:] = np.full(3, -1, dtype = Struct)
print('before fill:', a)
fill_python(a, 3)
print('after fill: ', a)
print()



@njit
def fill_jit(a, n):
    for i in range(n):
        s = np.zeros(1, dtype = Struct)[0]
        s.field1 = i
        a[i] = s


print('-----======= fill_jit')
a[:] = np.full(3, -1, dtype = Struct)
print('before fill:', a)
fill_jit(a, 3)
print('after fill: ', a)
print()


@njit
def fill_jit_element_wise(a, n):
    for i in range(n):
        s = np.zeros(1, dtype = Struct)[0]
        s.field1 = i
        a[i].field1 = s.field1
        a[i].field2 = s.field2

print('-----======= fill_jit_element_wise')
a[:] = np.full(3, -1, dtype = Struct)
print('before fill:', a)
fill_jit_element_wise(a, 3)
print('after fill: ', a)
print()




@njit
def fill_jit_global_struct(a, global_s, n):
    for i in range(n):
        global_s['field1'] = i
        a[i] = global_s

global_s = np.zeros(1, dtype = Struct)[0]
print('-----======= fill_jit_global_struct')
a[:] = np.full(3, -1, dtype = Struct)
print('before fill:', a)
fill_jit_global_struct(a, global_s, 3)
print('after fill: ', a)
print()

print('-----======= check that global_s pointer is not linked to a[-1]')
print( "global_s['field1'] = ", global_s['field1'] )
a[-1]['field1'] = -1
print( "a[-1]['field1'] = ", a[-1]['field1'] )
print( "global_s['field1'] = ", global_s['field1'] )
```

# Example 1 output
```
-----======= check that struct is a reference type
a[1]['field1'] =  -1
a[1]['field1'] =  5

-----======= fill_python
before fill: [(-1, -1) (-1, -1) (-1, -1)]
after fill:  [(0, 0) (1, 0) (2, 0)]

-----======= fill_jit
before fill: [(-1, -1) (-1, -1) (-1, -1)]
after fill:  [(0, -555819298) (1, -555819298) (2, -555819298)]

-----======= fill_jit_element_wise
before fill: [(-1, -1) (-1, -1) (-1, -1)]
after fill:  [(0, -555819298) (1, -555819298) (2, -555819298)]

-----======= fill_jit_global_struct
before fill: [(-1, -1) (-1, -1) (-1, -1)]
after fill:  [(0, 0) (1, 0) (2, 0)]

-----======= check that global_s pointer is not linked to a[-1]
global_s['field1'] =  2
a[-1]['field1'] =  -1
global_s['field1'] =  2
```

# Example 2 (jitclass)
```python
from numba.experimental import jitclass
from numba import njit, int32
import numba
import numpy as np

Struct = np.dtype( [('field1', 'i4'), ('field2', 'i4' )])
nb_Struct = numba.from_dtype(Struct)

spec_List = [
    ('capacity', int32)
    ,('collection', nb_Struct[::1])
    ,('p_top', int32)
]
@jitclass(spec_List)
class List:
    def __init__(self, initial_capacity = 16):
        self.capacity = initial_capacity
        self.collection = np.zeros(self.capacity, dtype = Struct)
        self.p_top = -1

    def Add(self, x):
        self.p_top += 1
        self.collection[self.p_top] = x

    def Clear(self):
        self.collection = np.zeros(self.capacity, dtype = Struct)
        self.p_top = -1
        
    def Reset(self):
        self.p_top = -1


l = List(4)

@njit
def list_jit_outside_loop(l, n):
    l.Reset()
    s = np.zeros(1, dtype = Struct)[0]
    for i in range(n):
        s['field1'] = i
        l.Add(s)

@njit
def list_jit_inside_loop(l, n):
    l.Reset()
    for i in range(n):
        s = np.zeros(1, dtype = Struct)[0]
        s['field1'] = i
        l.Add(s)


print('-----======= list_jit_outside_loop')
list_jit_outside_loop(l, 3)
print( l.collection )

print('-----======= list_jit_inside_loop')
list_jit_inside_loop(l, 3)
print( l.collection )
```

# Example 2 output
```
-----======= list_jit_outside_loop
[(0, -555819298) (1, -555819298) (2, -555819298) (0,          0)]
-----======= list_jit_inside_loop
[(0, 0) (1, 0) (2, 0) (0, 0)]
```
user: ghostoid
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6943: state: open
title: Error storing record view
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

from https://gitter.im/numba/numba?at=607d55082e5574669b46d04c

```python
import numpy as np
from numba import typeof
from numba.experimental import jitclass

counter_dtype = np.dtype([('element', np.int32, 5)])
one_counter = np.zeros(1, dtype=counter_dtype)[0]
print(one_counter)  

spec = [
    ("counter", typeof(one_counter))
]
print(spec)  # [('counter', Record(element[type=nestedarray(int32, (5,));offset=0];20;False))]

@jitclass(spec)
class UpdatingStuff:
    def __init__(self, counter):
        self.counter = counter

UpdatingStuff(one_counter)
```

error reported:

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x621e39550>.
Failed in nopython mode pipeline (step: native lowering)
use load_from_data_pointer() instead

File "chk.py", line 17:
    def __init__(self, counter):
        self.counter = counter
        ^
```

Numba should have catch the error of storing a record view as field. This problem is likely not specific to jitclass, but general to every container type.
user: sklam
labels: bug - ice: Bugs: internal compiler error
issue_6942: state: open
title: Inconsistent self-values assignment within 2-dimensional array
body: # Bug description
I've found that when we make a batch assignment within the same array, "moving" values from left to the right (e.g. a[1:6] = a[0:5]), if array is >= 2-dims shaped and the start index is not 0, numba will generate somewhat left-associated loop, propagating wrong values, see example below.

# Minimal example
```python
from numba import njit
import numpy as np

def SetArray(a, p, src_start, dest_start, cnt):
    a[p, dest_start:dest_start + cnt] = a[p, src_start:src_start + cnt]

SetArray_JIT = njit(SetArray)

a = np.zeros((1, 10), dtype = np.int32)

#-----======= moving from left to the right (src_start != 0)
a[0] = np.arange(10)
SetArray(a, 0, 1, 3, 7)
print('numpy', a[0])

a[0] = np.arange(10)
SetArray_JIT(a, 0, 1, 3, 7)
print('numba', a[0])      #------ wrong result
```

# Example output
```
numpy [0 1 2 1 2 3 4 5 6 7]
numba [0 1 2 1 2 1 2 1 2 1]
```
user: ghostoid
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6939: state: open
title: Implement `slice` boxing
body: This PR implements a `box` function for `SliceType`.  Closes #6931.
user: brandonwillard
issue_6931: state: open
title: Boxing for `slice`
body: The native `slice` object doesn't have a `box` implementation:

```python
import numba


@numba.njit
def get_slice(a, b):
    return slice(a, b)
```
```python
>>> get_slice(1, 2)
TypeError: cannot convert native slice<a:b> to Python object
```

## Feature request

A `box` implementation for `slice`.

user: brandonwillard
issue_6927: state: open
title: Leading underscore field in structref leads to compilation failure
body: Having a field in a structref with leading underscore leads to error.
Maybe it's already known but not documented?

```python
import numpy as np

from numba import njit
from numba.core import types
from numba.experimental import structref

from numba.tests.support import skip_unless_scipy

@structref.register
class MyStructType(types.StructRef):
    def preprocess_fields(self, fields):
        return tuple((name, types.unliteral(typ)) for name, typ in fields)

class MyStruct(structref.StructRefProxy):
    def __new__(cls, name):
        return structref.StructRefProxy.__new__(cls, name)
    @property
    def name(self):
        return MyStruct_get_name(self)

@njit
def MyStruct_get_name(self):
    return self._name

typ = structref.define_proxy(MyStruct, MyStructType, ["_name"])

MyStruct("hello")
```

fails with error
```python
 >>> MyStruct(unicode_type)

There are 2 candidate implementations:
    - Of which 2 did not match due to:
    Overload in function 'ctor': File: ../../../../../../Dropbox/Ricerca/Codes/Python/netket/<unknown> (built from string?): Line 0.
      With argument(s): '(unicode_type)':
     Rejected as the implementation raised a specific error:
       LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
     _name

     File "<string>", line 6:
     <source missing, REPL/exec in use?>

     During: lowering "(st)._name = _name" at <string> (6)
  raised from /Users/filippovicentini/Documents/pythonenvs/netket_env/lib/python3.8/site-packages/numba/core/errors.py:751

During: resolving callee type: Function(<class '__main__.MyStruct'>)
During: typing of call at /Users/filippovicentini/Documents/pythonenvs/netket_env/lib/python3.8/site-packages/numba/experimental/structref.py (373)


File "../../../../../Documents/pythonenvs/netket_env/lib/python3.8/site-packages/numba/experimental/structref.py", line 373:
            def ctor(*args):
                return cls(*args)
                ^
```
user: PhilipVinc
labels: bug - documentation incorrect: documentation is incorrect or missing something important
issue_6921: state: open
title: Interop With CuPy's Stream Context Mangers
body: ## Feature request

CuPy's stream objects support being used as context managers. Their wrapper around streams includes a per-thread current stream that's used for all operations in a given thread. I'm not sure what kind of coordination would be needed to make this happen, but it would be super helpful if we could have the following actually work:

```
with cupy_stream:
    numba_gpu_call(stuff)
```

This is potentially related to https://github.com/numba/numba/issues/4797, but it requires some effort beyond directly wrapping the low-level CUDA APIs.
user: insertinterestingnamehere
labels: CUDA: CUDA related issue/PR
Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_6920: state: open
title: Bad Parfor loop fusion side-effects?
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest ~released version~ HEAD (476d19240c8c2822fb43a529ca89c04428387bf1) ( of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Example:

```python
import numpy as np
from numba import njit, prange


@njit
def array_add(arr, idx, val):
    old = arr[idx]
    arr[idx] += val
    return old


@njit(parallel=dict(prange=True, fusion=True))  # the problem goes away where `fusion=False`
def foo(arr):
    accum = np.zeros(1, dtype=arr.dtype) 
    for i in prange(arr.size):
        array_add(accum, 0, arr[i])

    return accum[0]


total = foo(np.arange(10, dtype=np.intp))
print(total) 

foo.parallel_diagnostics(level=4)
```

This always print `0` when `fusion=True` and print other values (random due to race condition) when `fusion=False`. The code has no valid fusion because the loop domain in `np.zeros(1, ...)` is not equivalent to the `for i in prange(arr.size)`.

FYI, what I am trying to do is adding an atomic add intrinsic: https://gist.github.com/sklam/e5496e412fccac6acc0e96b4413ed977

user: sklam
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6916: state: open
title: Failing to build a jitclass with a deferred_type typed container as class member
body: Hello,

thanks for maintaining and developing Numba.

I encountered difficulties when trying to use typed containers (list) as attribute of a jit class, when the container is typed to a deferred type, see example below:

```python
# Assigning defer-type typed container as class member fails
from collections import OrderedDict
from numba import types, typed, deferred_type
from numba.experimental import jitclass

specs = OrderedDict()
node_type = deferred_type()
specs['children'] = types.ListType(node_type)
@jitclass(specs)
class Node:
    def __init__(self):
        self.children = typed.List.empty_list(node_type)

node_type.define(Node.class_type.instance_type)
# this will fail:
Node()
```

The exact error is:

> Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /Users/ci/miniconda3/conda-bld/llvmdev_1601977477900/work/include/llvm/IR/DataLayout.h, line 625.
Fatal Python error: Aborted

Note:
I successfully compiled a jitclass with a typed container, as the documentation explains:
```python
# Assigning builtin type typed container as class member fails
specs = OrderedDict()
node_type = deferred_type()
specs['children'] = types.ListType(int32)
@jitclass(specs)
class Node:
    def __init__(self):
        self.children = typed.List.empty_list(int32)

node_type.define(Node.class_type.instance_type)
# this will work:
Node()
```
Equally, I managed to compile jitclass with defer type typed class member (not containerized)
```python
specs = OrderedDict()
node_type = deferred_type()
specs['children'] = optional(node_type)
@jitclass(specs)
class Node:
    def __init__(self):
        self.children = None

node_type.define(Node.class_type.instance_type)
# Create node and assign children works:
Node().children = Node()
```
All I wish is a combination of both.

Context: my goal is to build a tree where the amount of children per node depends on the dimensionality of the data. It is thus difficult to "hard code" the amount of children to declare as attribute.

I am using numba 0.53.1 on a macos platform.

Thank you for your help,

user: remydubois
issue_6908: state: open
title: Tracker for target extension API potential issues
body: This tracks potential issues/problems/delayed work/things to revisit in relation to creating Numba's target extension API. Feel free to add/edit. cc @sklam.

Potential issues:

* Symbol mangling:
    * Current name mangling scheme doesn't account for things like flags or the target. Use case could be e.g. two versions of `foo` one with and one without `fastmath` set, these would alias in the symbol table.
* There's numerous tests and utility functions that run compiler passes and do e.g. IR gen without using the compiler pipeline. This is brittle and causes refactoring problems, almost all test failures in the case of changing internal APIs come from these tests/utilities.
    * Try and reduce use of/remove `compile_to_numba_ir` and similar.
    * Create a low level jit interface which is similar to `@jit` but the next level down with all the options available. This should/could return the compiler state object so it's trivial to get hold of the state information.
* Existing targets, e.g. CUDA and ROCm are likely relying on some of the CPU builtins and CPU implementations.

Things to look at again:

* Default flag is `None` as per https://github.com/numba/numba/pull/6888, not a huge problem but if possible the default should be the default flags set for the target.
* Work out how to keep ROCm working.
* The "TODO"s in the doc PR https://github.com/numba/numba/pull/6877

Future work:
* Move the CPU target out of `core` and treat it as another piece of hardware so as to reduce the reliance between the compiler core and the CPU (long term goal).
* Refactor and reduce the registries in existence down to two:
    * `builtin_essentials` - this registry to contain all the stack based stuff the can't be `@overload`'d, these are essentials like iterator implementations that don't really change
    across targets.
    * `legacy_implementations` - this to hold all the things that are currently directly lowered with e.g. `@lower_builtin`, it will replace the numerous existing registries and can eventually be retired when its contents is entirely overload based.
* Create a "configurable dispatcher" class for targets that need a launch configuration.
* Use `@overload_glue` to replace all the existing split API functions.
* Replace `operator` module function implementations with overloads, needs fastmath and general
  flag support. Easiest way to handle fast math is probably to override the default Builder class methods that implement instructions that can have the fast modifier and query the ConfigStack to add in the flag(s) if applicable.



user: stuartarchibald
labels: discussion: An issue requiring discussion
issue_6905: state: open
title: Support error_model in cuda.jit
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->


The `numba.cuda.jit` decorator does currently not support `error_model`, which means that `numba` will generate additional `!=0`  checks and corresponding branching, even if this is not wanted. This is especially bad if the default behavior of the GPU, e.g. `1/0=inf` is the wanted behavior, because we have to add another check manually. Currently:

```py
@nb.cuda.jit()
def inverse(arr):
    i = nb.cuda.grid(1)
    if i < arr.shape[0]:
        arr[i] = arr.shape[0] / arr[i] if arr[i] != 0 else np.inf
```

does the jump, but I would like to be able to pass

```py
@nb.cuda.jit(error_model='numpy')
def inverse(arr):
    i = nb.cuda.grid(1)
    if i < arr.shape[0]:
        arr[i] = arr.shape[0] / arr[i]

```

Similar to how this already works for `nb.jit:`


```py
@nb.jit(error_model='numpy')
def inverse(arr):
    for i in range(arr.shape[0]):
        arr[i] = arr.shape[0] / arr[i]

```

IMO, I would actually expect this to be the default behavior, considering that the current implementation just silently (unless `debug=True`) stops the kernel, which is almost certainly wrong.

user: MegaIng
labels: CUDA: CUDA related issue/PR
Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_6901: state: open
title: Stencil neighborhood option doesn't support numpy.int64.
body: In numba/stencils/stencil.py, there are various places (like line 552, "if isinstance(kernel_size[i][0], int):") where we check for "int" in relation to neighborhoods.  I ran across a case where I was creating a neighborhood tuple by extracting values from a Numpy array.    This causes a problem because those Numpy values will not match in these isinstance int checks.  I worked around it by converting to int during neighborhood tuple creation but perhaps a more flexible check in Numba would eliminate this conversion.
user: DrTodd13
labels: good first issue: A good issue for a first time contributor
issue_6900: state: open
title: divmod should return integers when passed unsigned integer and positive constant
body: 
## Reporting a bug

Using numba: 0.53.1

I have the following code:
```python
            is_byte, is_bit = divmod(i_sample, 8)
            if (masks[i_pat, is_byte] >> is_bit) & 1 == 1:
```
where `i_sample` is an integer. It generates the error:
```
E           numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
E           No implementation of function Function(<built-in function getitem>) found for signature:
E            
E            >>> getitem(array(uint8, 2d, C), Tuple(uint64, float64))
E            
E           There are 22 candidate implementations:
E              - Of which 20 did not match due to:
E              Overload of function 'getitem': File: <numerous>: Line N/A.
E                With argument(s): '(array(uint8, 2d, C), Tuple(uint64, float64))':
```
which is because `is_byte` is a float64. However, the [documentation for divmod](https://docs.python.org/3/library/functions.html#divmod) says:
```
For integers, the result is the same as (a // b, a % b). 
```
with the implication that the return should be a tuple of integers when the arguments are integers. 
user: shaunc
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6897: state: open
title: x in ... resolvable at compile time behaves inconsistently between cuda/njit
body: The following will happily compile in njit, but bombs in cuda.
```
import numba as nb
import numpy as np
from numba import cuda


@cuda.jit(device=True)
def b(q):
    if q in ('a', 'b'):
        return 1
    else:
        return 2


@cuda.jit(nb.void(nb.int32[::1]))
def a(r):
    r[0] = b('a')
    r[1] = b('2')
```

It yields:
```
Traceback (most recent call last):
  File "in.py", line 14, in <module>
    @cuda.jit(nb.void(nb.int32[::1]))
  File "lib\site-packages\numba\cuda\decorators.py", line 136, in kernel_jit
    targetoptions=targetoptions)
  File "lib\site-packages\numba\cuda\compiler.py", line 811, in __init__
    self.compile(sigs[0])
  File "lib\site-packages\numba\cuda\compiler.py", line 949, in compile
    **self.targetoptions)
  File "lib\site-packages\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "lib\site-packages\numba\cuda\compiler.py", line 57, in compile_kernel
    cres = compile_cuda(pyfunc, types.void, args, debug=debug, inline=inline)
  File "lib\site-packages\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "lib\site-packages\numba\cuda\compiler.py", line 46, in compile_cuda
    locals={})
  File "lib\site-packages\numba\core\compiler.py", line 602, in compile_extra
    return pipeline.compile_extra(func)
  File "lib\site-packages\numba\core\compiler.py", line 352, in compile_extra
    return self._compile_bytecode()
  File "lib\site-packages\numba\core\compiler.py", line 414, in _compile_bytecode
    return self._compile_core()
  File "lib\site-packages\numba\core\compiler.py", line 394, in _compile_core
    raise e
  File "lib\site-packages\numba\core\compiler.py", line 385, in _compile_core
    pm.run(self.state)
  File "lib\site-packages\numba\core\compiler_machinery.py", line 339, in run
    raise patched_exception
  File "lib\site-packages\numba\core\compiler_machinery.py", line 330, in run
    self._runPass(idx, pass_inst, state)
  File "lib\site-packages\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "lib\site-packages\numba\core\compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "lib\site-packages\numba\core\compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "lib\site-packages\numba\core\typed_passes.py", line 100, in run_pass
    raise_errors=self._raise_errors)
  File "lib\site-packages\numba\core\typed_passes.py", line 72, in type_inference_stage
    infer.propagate(raise_errors=raise_errors)
  File "lib\site-packages\numba\core\typeinfer.py", line 1071, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<numba.cuda.compiler.DeviceFunctionTemplate object at 0x000001DFD6F92608>) found for signature:
 
 >>> b <CUDA device function>(Literal[str](a))
 
There are 2 candidate implementations:
   - Of which 2 did not match due to:
   Overload in function 'b <CUDA device function>': File: in.py: Line 6.
     With argument(s): '(unicode_type)':
    Rejected as the implementation raised a specific error:
      LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
    Failed in nopython mode pipeline (step: nopython mode backend)
    No definition for lowering <built-in method eq_impl of _dynfunc._Closure object at 0x000001DFFFC9C908>(unicode_type, unicode_type) -> bool
    
    File "lib\site-packages\numba\cpython\listobj.py", line 662:
        def seq_contains_impl(lst, value):
            <source elided>
            for elem in lst:
                if elem == value:
                ^
    
    During: lowering "$16compare_op.4 = elem == value" at lib\site-packages\numba\cpython\listobj.py (662)
    During: lowering "$6compare_op.2 = q in $const4.1" at in.py (8)
  raised from lib\site-packages\numba\core\errors.py:751

During: resolving callee type: Function(<numba.cuda.compiler.DeviceFunctionTemplate object at 0x000001DFD6F92608>)
During: typing of call at in.py (16)


File "in.py", line 16:
def a(r):
    r[0] = b('a')
    ^
```



user: c200chromebook
labels: CUDA: CUDA related issue/PR
issue_6895: state: open
title: := operator cannot be jitted by at least the cuda module
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug



<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

### Bug descritpion
the := operator fails to load properly, the error message is
Type of variable '$30binary_subscr.2' cannot be determined, operation: unknown operation, location: unknown location (0:0)

File "unknown location", line 0:
<source missing, REPL/exec in use?>

This message does not lead to any solution , even though the operator can be jitted in other configurations
### Code to reproduce bug
```
from numba import cuda
import numpy as np

@cuda.jit
def bugged(array):
    i = cuda.grid(1)
    if i < array.shape[0]:
        if (value_used_for_more_complex_computation := array[i]) < 4.:
            array[i] = 1. # this should work


if __name__ == '__main__':
    array = np.zeros((10), int)
    try:
        bugged[1, 10](array)
    except Exception as E:
        print(E)
    print(array)
```
user: Alex-S-H-P
labels: bug - failure to compile: Bugs: failed to compile valid code
bug - regression: A regression against a previous version of Numba
issue_6894: state: open
title: support star-args use in closures
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit

@njit
def foo():
    def bar(a, b):
        pass
    x = 1, 2
    bar(*x)

foo()
```
does this:
```
numba/core/inline_closurecall.py", line 789, in _replace_args_with
    assert(idx < len(args))
AssertionError: Failed in nopython mode pipeline (step: inline calls to locally defined closures)
```
user: stuartarchibald
issue_6891: state: open
title: Cuda functions treat `*args` as a normal parameter
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version (53.1/97fe221b3704bd17567b57ea47f4fc6604476cf9) of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

When a `cuda.jit` function has `*args` parameter, it fails compilation with different errors, depending on how many arguments were passed.

This code:

```
from numba import cuda
import numpy as np

@cuda.jit()
def apply(array, *args):
    x = cuda.grid(1)
    if x < array.shape[0]:
        array[x] = args[0]

array = np.empty(128)

apply[8, 16](array, 2)
```

fails with 

>```
>No implementation of function Function(<built-in function getitem>) found for signature:
> 
> >>> getitem(int64, Literal[int](0))
>
>```

and when instead you call `apply[8, 16](array, 2, 3)`, you get
> ```Signature mismatch: 3 argument types given, but function takes 2 arguments```

It appears as if the cuda pipeline just ignores the `*`, treating `*args` as a single parameter.
If it is for some reason not possible to correctly deal with this, I would at least expect a sane error message.

<details>
<summary> Full tracback example one argument</summary>

> ```
> Traceback (most recent call last):
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\test_cuda.py", line 12, in <module>
>     apply[8, 16](array, 2)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 821, in __call__
>     return self.dispatcher.call(args, self.griddim, self.blockdim,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 964, in call
>     kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 972, in _compile_for_args
>     return self.compile(tuple(argtypes))
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 1093, in compile
>     kernel = _Kernel(self.py_func, argtypes, link=self.link,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 509, in __init__
>     cres = compile_cuda(self.py_func, types.void, self.argtypes,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 47, in compile_cuda
>     cres = compiler.compile_extra(typingctx=typingctx,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 606, in compile_extra
>     return pipeline.compile_extra(func)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 353, in compile_extra
>     return self._compile_bytecode()
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 415, in _compile_bytecode
>     return self._compile_core()
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 395, in _compile_core
>     raise e
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 386, in _compile_core
>     pm.run(self.state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 339, in run
>     raise patched_exception
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 330, in run
>     self._runPass(idx, pass_inst, state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 289, in _runPass
>     mutated |= check(pss.run_pass, internal_state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 262, in check
>     mangled = func(compiler_state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\typed_passes.py", line 104, in run_pass
>     typemap, return_type, calltypes, errs = type_inference_stage(
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\typed_passes.py", line 82, in type_inference_stage
>     errs = infer.propagate(raise_errors=raise_errors)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\typeinfer.py", line 1071, in propagate
>     raise errors[0]
> numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
> No implementation of function Function(<built-in function getitem>) found for signature:
>  
>  >>> getitem(int64, Literal[int](0))
>  
> There are 22 candidate implementations:
>   - Of which 22 did not match due to:
>   Overload of function 'getitem': File: <numerous>: Line N/A.
>     With argument(s): '(int64, int64)':
>    No match.
> 
> During: typing of intrinsic-call at C:\Users\tramp\PycharmProjects\numba_render_engine\test_cuda.py (8)
> During: typing of static-get-item at C:\Users\tramp\PycharmProjects\numba_render_engine\test_cuda.py (8)
> 
> File "test_cuda.py", line 8:
> def apply(array, *args):
>     <source elided>
>     if x < array.shape[0]:
>         array[x] = args[0]
>         ^
> 
> ```

</details>

<details>
<summary> Full tracback example two arguments</summary>

> 
> ```
> Traceback (most recent call last):
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\test_cuda.py", line 12, in <module>
>     apply[8, 16](array, 2, 3)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 821, in __call__
>     return self.dispatcher.call(args, self.griddim, self.blockdim,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 964, in call
>     kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 972, in _compile_for_args
>     return self.compile(tuple(argtypes))
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 1093, in compile
>     kernel = _Kernel(self.py_func, argtypes, link=self.link,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 509, in __init__
>     cres = compile_cuda(self.py_func, types.void, self.argtypes,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 47, in compile_cuda
>     cres = compiler.compile_extra(typingctx=typingctx,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 606, in compile_extra
>     return pipeline.compile_extra(func)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 353, in compile_extra
>     return self._compile_bytecode()
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 415, in _compile_bytecode
>     return self._compile_core()
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 395, in _compile_core
>     raise e
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 386, in _compile_core
>     pm.run(self.state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 339, in run
>     raise patched_exception
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 330, in run
>     self._runPass(idx, pass_inst, state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 289, in _runPass
>     mutated |= check(pss.run_pass, internal_state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 262, in check
>     mangled = func(compiler_state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\untyped_passes.py", line 105, in run_pass
>     raise TypeError("Signature mismatch: %d argument types given, "
> TypeError: Failed in nopython mode pipeline (step: fix up args)
> Signature mismatch: 3 argument types given, but function takes 2 arguments
> 
> Process finished with exit code 1
> 
> ```

</details>

The errors get even more confusing when you try to call a device function. This code:

```
@cuda.jit(device=True)
def process(x, t):
    return t

@cuda.jit()
def apply(array, *args):
    x = cuda.grid(1)
    if x < array.shape[0]:
        array[x] = process(x, *args)

array = np.empty(128)

apply[8, 16](array, 2)
```

instead fails with

> 
> ```
> No implementation of function Function(<built-in function add>) found for signature:
>  
>  >>> add(UniTuple(int32 x 1), int64)
> ```

<details>
  <summary>Full Traceback</summary>
  

> ```
> Traceback (most recent call last):
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\test_cuda.py", line 27, in <module>
>     apply[8, 16](array, 2)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 821, in __call__
>     return self.dispatcher.call(args, self.griddim, self.blockdim,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 964, in call
>     kernel = _dispatcher.Dispatcher._cuda_call(self, *args)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 972, in _compile_for_args
>     return self.compile(tuple(argtypes))
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 1093, in compile
>     kernel = _Kernel(self.py_func, argtypes, link=self.link,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 509, in __init__
>     cres = compile_cuda(self.py_func, types.void, self.argtypes,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\cuda\compiler.py", line 47, in compile_cuda
>     cres = compiler.compile_extra(typingctx=typingctx,
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 606, in compile_extra
>     return pipeline.compile_extra(func)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 353, in compile_extra
>     return self._compile_bytecode()
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 415, in _compile_bytecode
>     return self._compile_core()
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 395, in _compile_core
>     raise e
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler.py", line 386, in _compile_core
>     pm.run(self.state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 339, in run
>     raise patched_exception
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 330, in run
>     self._runPass(idx, pass_inst, state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_lock.py", line 35, in _acquire_compile_lock
>     return func(*args, **kwargs)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 289, in _runPass
>     mutated |= check(pss.run_pass, internal_state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\compiler_machinery.py", line 262, in check
>     mangled = func(compiler_state)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\typed_passes.py", line 104, in run_pass
>     typemap, return_type, calltypes, errs = type_inference_stage(
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\typed_passes.py", line 82, in type_inference_stage
>     errs = infer.propagate(raise_errors=raise_errors)
>   File "C:\Users\tramp\PycharmProjects\numba_render_engine\venv\lib\site-packages\numba\core\typeinfer.py", line 1071, in propagate
>     raise errors[0]
> numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
> No implementation of function Function(<built-in function add>) found for signature:
>  
>  >>> add(UniTuple(int32 x 1), int64)
>  
> There are 12 candidate implementations:
>   - Of which 2 did not match due to:
>   Operator Overload in function 'add': File: unknown: Line unknown.
>     With argument(s): '(UniTuple(int32 x 1), int64)':
>    No match for registered cases:
>     * (int64, int64) -> int64
>     * (int64, uint64) -> int64
>     * (uint64, int64) -> int64
>     * (uint64, uint64) -> uint64
>     * (float32, float32) -> float32
>     * (float64, float64) -> float64
>     * (complex64, complex64) -> complex64
>     * (complex128, complex128) -> complex128
>   - Of which 10 did not match due to:
>   Overload of function 'add': File: <numerous>: Line N/A.
>     With argument(s): '(UniTuple(int32 x 1), int64)':
>    No match.
> 
> During: typing of intrinsic-call at C:\Users\tramp\PycharmProjects\numba_render_engine\test_cuda.py (23)
> 
> File "test_cuda.py", line 23:
> def apply(array, *args):
>     <source elided>
>     if x < array.shape[0]:
>         array[x] = process(x, *args)
>         ^
> 
> ```

</details>


user: MegaIng
labels: CUDA: CUDA related issue/PR
issue_6882: state: open
title: LoweringError using njit(parallel=True) when using python 3.8 (but not when using 3.7)
body: # Code

This same bit of code raises a `LoweringError` with python 3.8 but not with python 3.7:

```py
@numba.njit(parallel=True)
def distance_filter_core(
    points1: ArrayLike, points2: ArrayLike, max_distance: float
) -> np.ndarray:
    res = np.ones(len(points1), np.uint8)
    for i in numba.prange(points1.shape[0]):
        p1 = points1[i]
        for p2 in points2:
            dist = np.sqrt(np.sum((p2 - p1) ** 2))
            if dist < max_distance:
                break
        else:
            res[i] = False
    return res
```

I removed the decorator and used the following workaround to get it working on both 3.7 and 3.8:

```py
if sys.version_info[1] == 7:
    distance_filter_core = numba.njit(parallel=True)(distance_filter_core)
else:
    distance_filter_core = numba.njit()(distance_filter_core)
```

but I am suprised that `numba.prange` works without the `parrallel=True` argument so I am not sure what is actually happening there.

# Traceback

```
 >           raise newerr.with_traceback(tb)
E           numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
E           Failed in nopython mode pipeline (step: nopython mode backend)
E           'parfor_index.51'
E           
E           File "inheart_research/util/mesh.py", line 167:
E           def distance_filter_core(
E               <source elided>
E                   for p2 in points2:
E                       dist = np.sqrt(np.sum((p2 - p1) ** 2))
E                       ^
E           
E           During: lowering "$arg_out_var.57 = getitem(value=$p2.72, index=parfor_index.51, fn=<built-in function getitem>)" at /home/runner/work/research/research/inheart_research/util/mesh.py (167)
E           During: lowering "id=0[LoopNest(index_variable = parfor_index.46, range = (0, points1_size0.31, 1))]{52: <ir.Block at /home/runner/work/research/research/inheart_research/util/mesh.py (163)>, 142: <ir.Block at /home/runner/work/research/research/inheart_research/util/mesh.py (169)>, 144: <ir.Block at /home/runner/work/research/research/inheart_research/util/mesh.py (171)>, 161: <ir.Block at /home/runner/work/research/research/inheart_research/util/mesh.py (164)>, 54: <ir.Block at /home/runner/work/research/research/inheart_research/util/mesh.py (166)>, 105: <ir.Block at /home/runner/work/research/research/inheart_research/util/mesh.py (166)>}Var(parfor_index.46, mesh.py:163)" at /home/runner/work/research/research/inheart_research/util/mesh.py (163)

../../../.cache/pypoetry/virtualenvs/xxx-py3.8/lib/python3.8/site-packages/numba/core/errors.py:751: LoweringError
```

# Versions

llvmlite                      0.36.0
numba                         0.53.1
numpy                         1.20.2

user: nicolascedilnik
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6874: state: open
title: Clarify conversions to numeric types
body: The current documentation for `int` support is `only the one-argument form`, but it actually is more restricted than that.

The second argument of the `int` constructor is the base, used only for setting a custom base when converting from `str`, `bytes` or `bytearray`, so just saying it supports one argument only might be interpreted, like I did, as "no custom base is supported", where actually it just supports `Integer`, `Float` or `Boolean` as implemented [here](https://github.com/numba/numba/blob/master/numba/core/typing/builtins.py#L930-L933).

This uses a single argument but fails:
```python
@njit
def foo(val):
    return int(val)

foo('123') # No implementation of function Function(<class 'int'>) found for signature: >>> int(unicode_type)
```


The [python docs](https://docs.python.org/3/library/functions.html#int) also defines the support for casting objects into `int`s, but since passing an object as an argument require using object mode, it works correctly using the python apis, so I don't think it needs to be mentioned here. In object mode string conversions also work correctly:

```python
@jit(forceobj=True)
def foo(val):
    return int(val)

class A:
    def __int__(self):
        return 4

foo(A())
foo('123')
```

The same restriction applies for `float`, but it has a clearer error message:
```python
@njit
def foo(val):
    return float(val)
foo('123')
```
```
No implementation of function Function(<class 'float'>) found for signature:
 
 >>> float(unicode_type)
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'Float.generic': File: numba/core/typing/builtins.py: Line 939.
    With argument(s): '(unicode_type)':
   Rejected as the implementation raised a specific error:
     TypeError: float() only support for numbers <=========== The int error message does not have this line
```

I would add that error message on the `int` implementation copying [this error](https://github.com/numba/numba/blob/master/numba/core/typing/builtins.py#L945) as a fallback [here](https://github.com/numba/numba/blob/master/numba/core/typing/builtins.py#L934), but I don't know where to test it. I may open another PR for that.
user: Fryuni
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
Effort - short: Short size effort needed
issue_6862: state: open
title: Program crashes with ACCESS_VIOLATION. Windows only.
body: ## Reporting a bug

```
>>> import numba
>>> numba.__version__
'0.53.0'
```

This bug was tested on different Python versions (3.7, 3.9) and different numba versions (0.45.0, 0.53.0, 0.50.0)
I am using package called `librosa` which depends on `resampy` which utilizes `numba`. Also I am using native Csound library using ctype bindings.

Whenever I am trying to run JITed code program crashes (`resampy.interp.resample_f`). If I disable JIT compilation by `NUMBA_DISABLE_JIT=1` program works fine. If I remove Csound or `librosa` programs work fine as well. Bug is Windows only reproducable. 
Here is bug reproduce steps:
1. Download latest [csound](https://csound.com/download.html) version
2. Copy `ctcsound.py` binding from `csound/bin` folder to `site-packages` or to `bug.py` file location
3. Place any `.wav` file over `bug.py`
4. Run following code:
```python
import ctcsound
import librosa

if __name__ == "__main__":
    ct = ctcsound.Csound()
    audio, orig_sr = librosa.load("some_sample.wav", sr=None)
    audio = librosa.resample(audio, orig_sr, 44020)
    print("NOT CRASHED!") 
```
Program crashes with `0xC0000005` error (ACCESS_VIOLATION). [Debugger screenshot](https://ibb.co/Ssj4WV6)
It seems that it's trying to dereference `[[_PyThreadState_Current]+0x48]`, but because `[_PyThreadState_Current]` is 0 next instruction getting `0x48`. `0x48` is outside of virtual memory map that why we are getting `0xC0000005`. I think it's something about GIL.
user: Redict
labels: no action required: No action was needed to resolve.
issue_6855: state: open
title: Rollaxis
body: ## Feature request

It would be very convenient to have `np.rollaxis()` supported. I could use `np.transpose()`, but I have to make a different implementation for each different number of axes.
user: ziofil
issue_6853: state: open
title: Error "The use of yield in a closure is unsupported"
body: I have code:
```
from itertools import product

def prob(dice, pips, target):
    rolls = product(range(1, pips+1), repeat=dice)
    targets = sum(1 for roll in rolls if sum(roll) == target)
    return targets / pips**dice

x = int(input())
y = int(input())
s = 0

for i in range(x*1, x*y+1):
    print(i, prob(x, y, i))
    s = s + prob(x, y, i)
print('sum: ', s)
```

Using numba like that:
```
from itertools import product
from numba import jit

@jit
def prob(dice, pips, target):
    rolls = product(range(1, pips+1), repeat=dice)
    targets = sum(1 for roll in rolls if sum(roll) == target)
    return targets / pips**dice

x = int(input())
y = int(input())
s = 0

for i in range(x*1, x*y+1):
    print(i, prob(x, y, i))
    s = s + prob(x, y, i)
print('sum: ', s)
```

And I have error:
```
Traceback (most recent call last):
  File "C:\Users\Valery\Desktop\main.py", line 15, in <module>
    print(i, prob(x, y, i))
  File "C:\Users\Valery\AppData\Local\Programs\Python\Python39\lib\site-packages\numba\core\dispatcher.py", line 423, in _compile_for_args
    error_rewrite(e, 'unsupported_error')
  File "C:\Users\Valery\AppData\Local\Programs\Python\Python39\lib\site-packages\numba\core\dispatcher.py", line 361, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.UnsupportedError: Failed in object mode pipeline (step: inline calls to locally defined closures)
The use of yield in a closure is unsupported.

File "main.py", line 7:
def prob(dice, pips, target):
    <source elided>
    rolls = product(range(1, pips+1), repeat=dice)
    targets = sum(1 for roll in rolls if sum(roll) == target)
    ^

```

How I can fix that?
user: Babaika25
issue_6846: state: open
title: Implement keyword-only or **kwargs handling for numba.extending.overload
body: I would like to write an extension that (1) only accepts keyword arguments and (2) returns a different type, depending on the values of those arguments. I had more success with this using the high-level `numba.extending.overload` decorator than the low-level `numba.extending.type_callable`, so I'll report the high-level attempts here.

The extended function `f` should look like the following in user code (in a `numba.njit`-decorated function).

```python
f(x=1)       # returns one type
f(y=1)       # returns a different type
f()          # complains about missing x or y
f(1)         # complains about passing argument by position
```

There's a NumPy function that's a little similar: the values of [np.unique](https://numpy.org/doc/stable/reference/generated/numpy.unique.html)'s keyword arguments change the type of its output, but [that hasn't been implemented in Numba](https://github.com/numba/numba/blob/81f708263be0ba6e803bd54633e8c278d93a5e78/numba/np/arrayobj.py#L1915-L1922) yet.

   * If I implement an overload with a keyword-only argument, like `*, x=None, y=None`, the error message is

```
Rejected as the implementation raised a specific error:
   IndexError: tuple index out of range
raised from /.../numba/core/typing/templates.py:214
```

which is still [line 214 in the current master](https://github.com/numba/numba/blob/81f708263be0ba6e803bd54633e8c278d93a5e78/numba/core/typing/templates.py#L214) (I checked surrounding context).

   * If I implement an overload with arbitrary `**kwargs` (to try to do the same thing by inspecting the dict in the typing pass, obviously not in lowered code), the error message is

```
Rejected as the implementation raised a specific error:
   InternalError: The use of VAR_KEYWORD (e.g. **kwargs) is unsupported. (offending argument name is '**kwargs')
raised from .../numba/core/typing/templates.py:532
```

which is still [line 532](https://github.com/numba/numba/blob/81f708263be0ba6e803bd54633e8c278d93a5e78/numba/core/typing/templates.py#L532).

Here's a work-around that I'll be using to get my desired behavior, though it's not ideal:

```python
@numba.extending.overload(f)
def f(
    fake_argument_to_make_the_rest_effectively_keyword_only=None,
    x=None,
    y=None,
):
    # If anything is passed in the first argument, including None, the following fails because
    # the value of this argument becomes the *type* (i.e. a NoneType instance, not None).
    if fake_argument_to_make_the_rest_effectively_keyword_only is not None:
        raise numba.TypingError("positional arguments are not allowed")

    if x is not None:
        def f_impl(
            fake_argument_to_make_the_rest_effectively_keyword_only=None,
            x=None,
            y=None,
        ):
            return 1   # one type

        return f_impl

    elif y is not None:
        def f_impl(
            fake_argument_to_make_the_rest_effectively_keyword_only=None,
            x=None,
            y=None,
        ):
            return numpy.array([1, 2, 3])   # a different type

        return f_impl

    else:
        raise numba.TypingError("either 'x' or 'y' keywords must be supplied")
```
user: jpivarski
labels: discussion: An issue requiring discussion
issue_6845: state: open
title: `cache=True` with same wrapped `fn` but different `targetoptions` [request]
body: [Context](https://stackoverflow.com/q/66675817/10133797). Basically, `parallel=True` below should be effective, but isn't:

```python
import numpy as np
from numba import jit, prange
from timeit import timeit

def make_fn(fn, parallel=False):
    return jit(nopython=True, cache=True, parallel=parallel)(fn)

def _fn0(x, out):
    for j in prange(x.shape[1]):
        for i in range(x.shape[0]):
            out[i, j] = x[i, j]**2 + 1

fn0     = make_fn(_fn0, parallel=False)
fn0_par = make_fn(_fn0, parallel=True)

#%%##########################################################################
x = np.random.randn(240, 240000)
out = np.zeros(x.shape)

# run once to cache
fn0(x, out)
fn0_par(x, out)

print(timeit(lambda: fn0(x, out),     number=20) / 20)
print(timeit(lambda: fn0_par(x, out), number=20) / 20)
```
```
>>> 0.35493123000000004
>>> 0.35127711000000017
```
user: OverLordGoldDragon
labels: caching: Issue involving caching
issue_6838: state: open
title: Error on keyword arguments to parallel functions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
ParallelAccelerator only considers positional arguments to parallel functions ([such as here](https://github.com/numba/numba/blob/5f7bcce048b9c0a7fd02376ca8a2e3574625c99f/numba/parfors/parfor.py#L1447)), resulting in unexpected errors. Supporting kws properly is necessary to avoid several similar issues.

```python
import numpy as np
import numba

@numba.njit(parallel=True)
def f(n):
    return np.arange(n, dtype=np.int32)

print(f(11))
```
```
    return func(*args, **kwargs)
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/ehsan/dev/numba/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/Users/ehsan/dev/numba/numba/core/typed_passes.py", line 255, in run_pass
    preparfor_pass.run()
  File "/Users/ehsan/dev/numba/numba/parfors/parfor.py", line 1373, in run
    self._replace_parallel_functions(self.func_ir.blocks)
  File "/Users/ehsan/dev/numba/numba/parfors/parfor.py", line 1439, in _replace_parallel_functions
    if guard(replace_func):
  File "/Users/ehsan/dev/numba/numba/core/ir_utils.py", line 1452, in guard
    return func(*args, **kwargs)
  File "/Users/ehsan/dev/numba/numba/parfors/parfor.py", line 1427, in replace_func
    new_blocks, _ = inline_closure_call(self.func_ir, g,
  File "/Users/ehsan/dev/numba/numba/core/inline_closurecall.py", line 601, in inline_closure_call
    args = _get_callee_args(call_expr, callee, block.body[i].loc, func_ir)
  File "/Users/ehsan/dev/numba/numba/core/inline_closurecall.py", line 713, in _get_callee_args
    return numba.core.typing.fold_arguments(
  File "/Users/ehsan/dev/numba/numba/core/typing/templates.py", line 217, in fold_arguments
    ba = pysig.bind(*bind_args, **bind_kws)
  File "/opt/anaconda3/envs/DEV/lib/python3.8/inspect.py", line 3025, in bind
    return self._bind(args, kwargs)
  File "/opt/anaconda3/envs/DEV/lib/python3.8/inspect.py", line 3014, in _bind
    raise TypeError(
TypeError: Failed in nopython mode pipeline (step: Preprocessing for parfors)
got an unexpected keyword argument 'dtype'
```
user: ehsantn
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6835: state: open
title: Refcount bug in arrays of structured dtype
body: When accessing a scalar from an existing structured array initialized with np.zeros (also happens with np.empty), the field values seem to underflow. This happens even when explicitly assigning 0 to each field. The only consistent workaround I found was to access the scalar immediately in the assignment combined with manually assigning 0 to each field afterwards.

```python
from numba import njit
import numpy as np

structured_array_dtype = np.dtype({
    'names': ('field1', 'field2'),
    'formats': (np.float64, np.int8),
    'aligned': True,
})

def underflowing_structured_scalar():
    structured_array = np.zeros(1, dtype=structured_array_dtype)
    structured_scalar = structured_array[0]
    structured_scalar['field1'] = 0
    structured_scalar['field2'] = 0
    print('array: ', structured_array)
    print('scalar:', structured_scalar)

def functioning_structured_scalar():
    structured_array = np.zeros(1, dtype=structured_array_dtype)
    structured_scalar = np.zeros(1, dtype=structured_array_dtype)[0]
    structured_scalar['field1'] = 0
    structured_scalar['field2'] = 0
    print('array: ', structured_array)
    print('scalar:', structured_scalar)
```

Python produces the expected output in both cases:

```python
underflowing_structured_scalar()
# array:  [(0., 0)]
# scalar: (0., 0)
functioning_structured_scalar()
# array:  [(0., 0)]
# scalar: (0., 0)
```

Numba leads to underflow when accessing existing structured array:

```python
njit(underflowing_structured_scalar)()
# array:  [(0., 0)]
# scalar: (-9.86830992e+148, -34)
njit(functioning_structured_scalar)()
# array:  [(0., 0)]
# scalar: (0., 0)
```

I get this behavior on a Linux environment (Python 3.8.5) and a Windows environment (Python 3.8.6), both with Numba 0.53.0.
user: austerj
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6825: state: open
title: reflected list behaves differently on Python 3.7 and 3.8
body: Importing from Discourse: https://numba.discourse.group/t/seeing-different-behavior-with-python-3-8-2-vs-python-3-7-5/596/3

```
import numpy as np
from numba import jit

@jit(nopython=True)
def test():
    tmp = []
    for i in range(3):
        tmp.append(i)
    for i in range(1):
        tmp.append(i)
    tmp = np.array(tmp)
    return tmp


tmp = test()
print(tmp)
```

On Python 3.7 this outputs:

```
[0 1 2 0]
```

Whereas on 3.8 it outputs:

```
[0]
```
user: esc
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6819: state: open
title: RuntimeWarning: invalid value when disabling AVX2
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Test code:
```python
#!/usr/bin/env python3

import os

os.environ['NUMBA_CPU_FEATURES'] = '-avx2'

import numpy as np
import numba

@numba.guvectorize(['c8[:], c8[:]'], '(a)->(a)', nopython=True)
def _stefcal_gufunc(init_gain, g):
    print(np.complex64(1) / init_gain[0])

_stefcal_gufunc(np.ones(1, np.complex64))
```

Output
```
(1+0j)
/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/np/ufunc/gufunc.py:123: RuntimeWarning: invalid value encountered in _stefcal_gufunc
  return self.ufunc(*args, **kwargs)
```

I expected there to be no RuntimeWarning since it's just computing 1/1. Removing the NUMBA_CPU_FEATURES line (on a machine with avx2) makes the warning go away.

This appears to be a regression from 0.51.2 to 0.52.

- Python 3.8
- numpy 1.20.1
- numba 0.53.0
- llvmlite 0.36.0
- Everything installed with pip
user: bmerry
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6803: state: open
title: ListType to numpy array issue
body: If I have a list that I want to eventually convert into a numpy array, I have to use a reflected list rather than a `ListType`.

For example:

```
@numba.jit(nopython=True)
def foo1():
    A = [-1]
    numpy.array(A)

@numba.jit(nopython=True)
def foo2():
    A = numba.typed.List([-1])
    numpy.array(A)
    
foo1()
foo2()
```

`foo1()` works but `foo2()` fails. I have some use cases where this requires me to use the old reflected list instead of the new `ListType`.
user: justinblaber
issue_6784: state: open
title: parfors invalid/outdated varmap
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.
This:
```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def test2(g_data, g_indices, g_indptr, X):
    M, N = X.shape
    out = np.zeros(M, dtype=np.float_)
    for k in prange(M):
        x = X[k, :].astype(np.float_)
        total = 0.0
        for i in range(N):
            s = slice(g_indptr[i], g_indptr[i + 1])
            i_indices = g_indices[s]
            i_data = g_data[s]
#             tmp = (i_data * (x[i] - x[i_indices])  ** 2) uncomment this and get a different error!
            val = (i_data * ((x[i] - x[i_indices]) ** 2)).sum()
            total += val
        out[k] = total
    return out

g_data = np.array([1, 2, 3, 4])
g_indptr = np.array([0, 0, 1, 2, 3, 4], dtype=np.int32)
g_indices = np.array([1, 2, 3, 4], dtype=np.int32)
X = np.zeros((5, 5))
test2(g_data, g_indptr, g_indices, X)
```
produces:
```
numba/core/lowering.py", line 1249, in getvar
    return self.varmap[name]
KeyError: 'i_data'
<snip>
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
Failed in nopython mode pipeline (step: native lowering)
'i_data'

File "issue6774_4.py", line 16:
def test2(g_data, g_indices, g_indptr, X):
    <source elided>
#             tmp = (i_data * (x[i] - x[i_indices])  ** 2)
            val = (i_data * ((x[i] - x[i_indices]) ** 2)).sum()
```
note that uncommenting the line that's commented instead produces an assertion error:
```
AssertionError: Sizes of i_data, $130binary_subscr.25 
```
xref: https://github.com/numba/numba/issues/6774#issuecomment-788789663 reported by @ivirshup.

CC @DrTodd13 
user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6783: state: open
title: parfors lowering error from sum with internal prange (suspect SSA related!?)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def test_simple_2(X):
    M, N = X.shape
    out = np.zeros(M, dtype=np.float_)
    for k in prange(M):
        x = X[k, :].astype(np.float_)
        total = 0.0
        for i in range(N):
            i_indices = np.arange(5)
            i_data = np.ones(5)
            val = (i_data).sum()
            total += val
        out[k] = total
    return out


X = np.ones((3, 4))

print(test_simple_2(X))
```
does this:
```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: native lowering)
Failed in nopython mode pipeline (step: native lowering)
'val.72'

File "numba/parfors/parfor.py", line 256:
        def sum_1(in_arr):
            <source elided>
            for i in numba.parfors.parfor.internal_prange(len(in_arr)):
                val += in_arr[i]
                ^

During: lowering "$val.72.315 = inplace_binop(fn=<built-in function iadd>, immutable_fn=<built-in function add>, lhs=val.72, rhs=$expr_out_var.117, static_lhs=Undefined, static_rhs=Undefined)" 
```


xref: https://github.com/numba/numba/issues/6774#issuecomment-788789663 reported by @ivirshup.

CC @DrTodd13 

user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6782: state: open
title: parfors invalid result from nested reduction
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This
```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def test_simple_1(X):
    M, N = X.shape
    out = np.zeros(M, dtype=np.float_)
    for k in prange(M):
        x = X[k, :].astype(np.float_)
        total = 0.0
        for i in prange(N):
            i_indices = np.arange(5)
            i_data = np.ones(5)
            val = np.sum(i_data)
            total += val
        out[k] = total
    return out

X = np.ones((3, 4))

print(test_simple_1(X))
```
produces `[0. 0. 0.]`, should be all `20.0`.

xref: https://github.com/numba/numba/issues/6774#issuecomment-788789663 reported by @ivirshup.

CC @DrTodd13 

user: stuartarchibald
labels: bug - miscompile: Bugs: miscompile
issue_6781: state: open
title: Multiple overload method/attribute templates for same type overlap
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi,

I was trying to extend Numba types with a new type family in a similar way it's done for typed.Dict that uses overloading of TypeRef's method `empty` to create instances of concrete typed dict types, but ran into the problem when it's not possible to overload TypeRef's `empty` since it breaks Dict methods compilation.

After a bit of debugging I found that problem is likely caused by `@overload_method` and `@overload_attribute` decorators not supporting multiple entries for the same type-family (each providing separate specializations for concrete types) since it ends up in multiple OverloadAttributeTemplate-s registered for the same key (which is a metaclass name).

Here's the reproducer:
```
import numba
from numba import types
from numba.extending import (
    make_attribute_wrapper,
    overload,
    overload_method,
    models,
    register_model,
)
from numba.core.types.abstract import TypeRef


class DummyType(types.Type):
    def __init__(self, name):
        self.name = name
        super(DummyType, self).__init__(name=f"Dummy({name})")

# we have several concrete types created from DummyType
dummy_type_a = DummyType('a')
dummy_type_b = DummyType('b')


@register_model(DummyType)
class DummyModel(models.StructModel):
    def __init__(self, dmm, fe_type):
        value_type = types.int64 if fe_type.name == 'a' else types.unicode_type
        members = [("value", value_type)]
        models.StructModel.__init__(self, dmm, fe_type, members)

make_attribute_wrapper(DummyType, "value", "_value")


'''
# singe overload_method registering all specializations works OK
@overload_method(TypeRef, 'get')
def dummy_get_ovld(self):

    if not isinstance(self.instance_type, DummyType):
        return None

    if self.instance_type is dummy_type_a:
        def dummy_type_a_get_impl(self):
            return 'a'
        return dummy_type_a_get_impl

    def dummy_type_b_get_impl(self):
        return 'b'
    return dummy_type_b_get_impl
'''

# multiple overload methods (e.g. when they are placed in different files
# or like in this case when overloading internal Numba type - TypeRef)
# override themselves (don't work together, but work if only one is used)
@overload_method(TypeRef, 'get')
def dummy_type_a_get_ovld(self):

    if self.instance_type is not dummy_type_a:
        return None

    def dummy_type_a_get_impl(self):
        return 'a'
    return dummy_type_a_get_impl


@overload_method(TypeRef, 'get')
def dummy_type_b_get_ovld(self):

    if self.instance_type is not dummy_type_b:
        return None

    def dummy_type_b_get_impl(self):
        return 'b'
    return dummy_type_b_get_impl


@numba.njit
def test_func():
    a = dummy_type_a.get()
    b = dummy_type_b.get()
    return a, b

print(test_func())
# test_func.inspect_types()
```

While it works when there's a single `@overload_method(TypeRef, 'get')` entry that provides implementation for all TypeRef instances it doesn't work if multiple functions are decorated with overload_method. This actually prevents user from overloading on internal Numba types such as TypeRef.

Above reproducer gives:
```
Traceback (most recent call last):
  File "test_overload_method_1.py", line 79, in <module>
    print(test_func())
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 356, in error_rewrite
    raise e
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 367, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 819, in compile
    cres = self._compiler.compile(args, return_type)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 82, in compile
    raise retval
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 92, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py", line 105, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 627, in compile_extra
    return pipeline.compile_extra(func)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 363, in compile_extra
    return self._compile_bytecode()
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 425, in _compile_bytecode
    return self._compile_core()
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 405, in _compile_core
    raise e
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler.py", line 396, in _compile_core
    pm.run(self.state)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 341, in run
    raise patched_exception
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 332, in run
    self._runPass(idx, pass_inst, state)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 291, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\compiler_machinery.py", line 264, in check
    mangled = func(compiler_state)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typed_passes.py", line 92, in run_pass
    typemap, return_type, calltypes = type_inference_stage(
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typed_passes.py", line 70, in type_inference_stage
    infer.propagate(raise_errors=raise_errors)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typeinfer.py", line 1071, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
- Resolution failure for literal arguments:
No implementation of function Function(<function dummy_type_a_get_ovld at 0x0000018EB06659D0>) found for signature:

 >>> dummy_type_a_get_ovld(typeref[Dummy(b)])

There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload of function 'dummy_type_a_get_ovld': File: test_overload_method_1.py: Line 51.
    With argument(s): '(typeref[Dummy(b)])':
   No match.

- Resolution failure for non-literal arguments:
None

During: resolving callee type: BoundFunction((<class 'numba.core.types.abstract.TypeRef'>, 'get') for typeref[Dummy(b)])
During: typing of call at test_overload_method_1.py (76)


File "test_overload_method_1.py", line 76:
def test_func():
    <source elided>
    a = dummy_type_a.get()
    b = dummy_type_b.get()
    ^
```

And debugging shows there are multiple overload templates with the same signature registered:
>>> func
(<class 'numba.core.types.abstract.TypeRef'>, 'get')
>>> self.versions
[((<class 'numba.core.types.abstract.TypeRef'>, *any), <function _OverloadMethodTemplate.do_class_init.<locals>.method_impl at 0x00000259E3185AF0>), ((<class 'numba.core.types.abstract.TypeRef'>, *any), <function _OverloadMethodTemplate.do_class_init.<locals>.method_impl at 0x00000259E3185B80>)]

I verified problem can be reproduced on numba=0.52.0

Best Regards,
Alexey.

user: kozlov-alexey
issue_6754: state: open
title: Add the ability to alias a function/module within the compiler registry
body: I don't know how useful this would actually be but I figured I would make a feature request anyway (it might even be implemented and I just haven't found it in the code base)

I noticed within the code base there are a few sections (like numba/numba/cuda/mathimpl.py) where functions, in this example the math functions from the math library, are mapped to their equivalent functions from another library, here libdevice, for generating llvm code. I am having to do this on my own as well when defining my own library. If I only want to extend a select few functions but want to maintain the ability for the user to type LIBRARY.func for every function within the original library I need to go through and do this mapping all over again. It seems like it would be beneficial to have some sort of aliasing ability.

Example:
registry.alias(libdevice.sqrt, math.sqrt)

The idea here is that now, when a user calls math.sqrt internally it will simply look to libdevice.sqrt for lowering, etc.
user: uchytilc
labels: CUDA: CUDA related issue/PR
issue_6745: state: open
title: Feature request: np.searchsorted(array, range)
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

I would like `np.searchsorted` to work when the second argument `v` is a `range`. That is:

```python
from numba import njit
import numpy as np

def foo(a, i):
    return np.searchsorted(a, range(i))  # Can't pass ranges into numba

foo(np.arange(10), 5)
# array([0, 1, 2, 3, 4])

njit(foo)(np.arange(10), 5)
# TypingError: Failed in nopython mode pipeline (step: nopython frontend)
```

<details>
<summary> Full traceback </summary>

```pytb
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-3-578a0a37211c> in <module>
----> 1 njit(foo)(np.arange(10), 5)

/usr/local/lib/python3.8/site-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    412                 e.patch_message(msg)
    413 
--> 414             error_rewrite(e, 'typing')
    415         except errors.UnsupportedError as e:
    416             # Something unsupported is present in the user code, add help info

/usr/local/lib/python3.8/site-packages/numba/core/dispatcher.py in error_rewrite(e, issue_type)
    355                 raise e
    356             else:
--> 357                 raise e.with_traceback(None)
    358 
    359         argtypes = []

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<function searchsorted at 0x150d6b5e0>) found for signature:
 
 >>> searchsorted(array(int64, 1d, C), range_state_int64)
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'searchsorted': File: numba/np/arraymath.py: Line 3549.
    With argument(s): '(array(int64, 1d, C), range_state_int64)':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<function _searchsorted.<locals>.searchsorted_inner at 0x16cda1790>) found for signature:
    
    >>> searchsorted_inner(array(int64, 1d, C), range_state_int64)
    
   There are 2 candidate implementations:
         - Of which 2 did not match due to:
         Overload in function 'register_jitable.<locals>.wrap.<locals>.ov_wrap': File: numba/core/extending.py: Line 151.
           With argument(s): '(array(int64, 1d, C), range_state_int64)':
          Rejected as the implementation raised a specific error:
            TypingError: Failed in nopython mode pipeline (step: nopython frontend)
          No implementation of function Function(<ufunc 'isnan'>) found for signature:
           
           >>> isnan(range_state_int64)
           
          There are 2 candidate implementations:
                - Of which 2 did not match due to:
                Overload in function 'Numpy_rules_ufunc.generic': File: numba/core/typing/npydecl.py: Line 96.
                  With argument(s): '(range_state_int64)':
                 Rejected as the implementation raised a specific error:
                   TypingError: can't resolve ufunc isnan for types (range_state_int64,)
            raised from /usr/local/lib/python3.8/site-packages/numba/core/typing/npydecl.py:102
          
          During: resolving callee type: Function(<ufunc 'isnan'>)
          During: typing of call at /usr/local/lib/python3.8/site-packages/numba/np/arraymath.py (3522)
          
          
          File "../../../../usr/local/lib/python3.8/site-packages/numba/np/arraymath.py", line 3522:
              def searchsorted_inner(a, v):
                  <source elided>
                  n = len(a)
                  if np.isnan(v):
                  ^
   
     raised from /usr/local/lib/python3.8/site-packages/numba/core/typeinfer.py:1071
   
   During: resolving callee type: Function(<function _searchsorted.<locals>.searchsorted_inner at 0x16cda1790>)
   During: typing of call at /usr/local/lib/python3.8/site-packages/numba/np/arraymath.py (3579)
   
   
   File "../../../../usr/local/lib/python3.8/site-packages/numba/np/arraymath.py", line 3579:
           def searchsorted_impl(a, v, side='left'):
               return loop_impl(a, v)
               ^

  raised from /usr/local/lib/python3.8/site-packages/numba/core/typeinfer.py:1071

During: resolving callee type: Function(<function searchsorted at 0x150d6b5e0>)
During: typing of call at <ipython-input-1-41f38546fafb> (5)


File "<ipython-input-1-41f38546fafb>", line 5:
def foo(a, i):
    return np.searchsorted(a, range(i))  # Can't pass ranges into numba
    ^
```

</details>

I think the most appropriate way to implement this is to make sure the range types are `Sequence` subtypes (which I don't think is the case currently).

### More details

Right now, I think the reason this doesn't work is these lines: https://github.com/numba/numba/blob/3fd158f79a12ac5276bc5a72c2404464487c91f0/numba/np/arraymath.py#L3591-L3597, since (I think) a `numba` range isn't a `numba` `Sequence`. I'd suggest a range should be a sequence, since:

```python
from collections.abc import Sequence
assert issubclass(range, Sequence)
```

Since the above case is failing, the next case is:

https://github.com/numba/numba/blob/3fd158f79a12ac5276bc5a72c2404464487c91f0/numba/np/arraymath.py#L3598-L3603

So `np.isnan` is called directly on `v` in `loop_impl`. Arguably this also shouldn't error the way it does since: 

```python
np.isnan(range(5))
# array([False, False, False, False, False])
```

but this will cause problems anyways.
user: ivirshup
issue_6740: state: open
title: Support for advanced/fancy indexing support in the cuda target
body: ---

## Feature request

Having support for [advanced/fancy indexing](https://numpy.org/doc/stable/reference/arrays.indexing.html#advanced-indexing) would be awesome! Being able to do something like 

```
def my_kernel(ARR: np.ndarray, INDS: np.ndarray, RESULT: np.ndarray):
    for permutation in range(10):
        RESULT[permutation] = do_something(ARR[INDS[permutation], 0:5], ARR[INDS[permutation], 5:10])

```
would be super cool.

This might be related to https://github.com/numba/numba/issues/5894 .


user: srcoulombe
labels: CUDA: CUDA related issue/PR
issue_6738: state: open
title: Objmode guard for multiply defined variables
body: The following should get better error message:


```python
from numba import njit, objmode
import numpy as np

@njit
def moderror(pred):
    if pred:
        x = 'intp'
    else:
        x = 'float32'
    with objmode(val=x):
        val = 12.3
    return val

moderror(False)
```
not necessarily to be fixed here, but https://github.com/numba/numba/blob/d89d34105cc0e1dc9402b14bbc0e4a7abf3c0a3e/numba/core/transforms.py#L382 should guard for multiply defined variables.

_Originally posted by @stuartarchibald in https://github.com/numba/numba/pull/6680#discussion_r579214479_


Currently the error is:

```
KeyError: 'Failed in nopython mode pipeline (step: Handle with contexts)\n"more than one definition for \'x\'"'
```

A better error is to suggest that `objmode()` doesn't support multiply defined variables. Only compile-time constants for this case.
user: sklam
labels: good second issue: A good issue for second time contributors
issue_6714: state: open
title: support np.dot() for integer types
body: As discussed privately, this will depend on `dot()` support an integer version.  We will defer this problem.

_Originally posted by @sklam in https://github.com/numba/numba/pull/2134#discussion_r80932581_
user: slayoo
issue_6712: state: open
title: Option/configuration/extension for smaller exception tracebacks
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Following on from today's public meeting: https://github.com/numba/numba/wiki/Minutes_2021_02_09 where an idea along these lines was discussed:

> A configuration or extension point to make Numba do a short "single line error report" might be useful for use cases where a product wraps or consumes Numba and also takes user input as something to attempt to compile. In this case simply conveying to the user that "Numba could not compile line X" may be sufficient for the needs of the project.

As noted at the meeting, I have a strong preference for Numba to continue with its current default of it having compiler-like error messages, enhancements to improve these are welcomed. However, as noted above, having a way to request Numba to act more in a "consumption" mode where tracebacks are squashed sounds like a good fit for the use cases described.

This ticket is to track and discuss.

CC @ehsantn
CC @jpivarski
user: stuartarchibald
issue_6707: state: open
title: Migrate from MCJIT to OrcV2
body: Followup to https://github.com/numba/numba/issues/2290

user: esc
labels: llvm: LLVM related issues
issue_6706: state: open
title: It seems that stencil doesn't cache the compiled result.
body: numba 0.52.0

Here is test code in Jupyter Notebook:

```python
import numba as nb
import numpy as np

@nb.stencil
def kernel(a):
    return 0.2 * (a[0, 0] + a[0, 1] + a[1, 0] + a[0, -1] + a[-1, 0])

arr = np.random.randn(1000, 1000)
%time kernel(arr)
```

```
Wall time: 334 ms
```

run the function again, the run time is the same:

```
%time kernel(arr)
```

```
Wall time: 299 ms
```

Compile first and check the run time, it is fast:

```python
from numba.core import typing
args = (arr,)
result = None
array_types = tuple([typing.typeof.typeof(x) for x in args])
array_types_full = array_types

(real_ret, typemap, calltypes) = kernel.get_return_type(array_types)
new_func = kernel._stencil_wrapper(result, None, real_ret, typemap,
                                 calltypes, *array_types_full)
%time new_func.entry_point(arr)
```

```
Wall time: 4.99 ms
```
user: ruoyu0088
labels: performance - compile time: Performance issue occurring at compile time.
issue_6701: state: open
title: Add support for CUDA device selection by UUID
body: #6700 adds the `uuid` of devices to the `Device` class. A further enhancement would be to enable device selection by UUID, e.g.:

```python
with cuda.gpus['GPU-e6489c45-5b68-3b03-bab7-0e7c8e809643']
    # ... do something
```

This is motivated by the ability of `CUDA_VISIBLE_DEVICES` to affect the numeric ID of devices - there are some cases in which a user would want a particular device to be selected, regardless of its ID as a result of the `CUDA_VISIBLE_DEVICES` setting.

Ideally the addition of this feature will be consistent in that anywhere an integer ID can be passed, a UUID can be passed instead.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_6694: state: open
title: WIP Fix #6690 'Bad token in signature' with @guvectorize where bad token is NUMBER
body: WIP Fix #6690 

Currently it is not possible to use constants when defining the dimensions signature of a gufunc, i.e. nothing like `"(x),(5)->(x,5)"`

This PR enables `tokenize.NUMBER` as a valid token type in the signature parser, which is enough to propagate these signatures through numba.

Since numpy supports frozen dimensions (as far as I can tell its documented since version 1.16), this luckily just seems to work out of the box for sufficiently new numpy versions.

It's a fairly blunt solution for now:
1) No optimisation to the IR generation yet. It seems like frozen dimensions should technically allow exchanging some variables for constants, but I would need help with that.
2) Using numbers for describing the array dimensions currently still follows the same rules as with symbols. I.e. a constant output dimension must have previously been declared in one of the input arrays, too. I am not sure if numpy generally forsees gufuncs that do not follow this rule, and if it should be possible to do so (ex. `"(n), (20)->(10)"`). I can think of this being useful, but I don't know what behind the scenes implications a signature like this could have.

Useful links:
https://numpy.org/doc/stable/reference/c-api/generalized-ufuncs.html?highlight=generalized%20universal%20function%20api#details-of-signature
user: HPLegion
issue_6690: state: open
title: 'Bad token in signature' with @guvectorize
body: - [x] I have tried using the version 0.51.2 of Numba
- [x] I have included a self contained code sample to reproduce the problem

Hi,
I am sorry, I am aware it is more a 'usage' question or perhaps a 'feature request'.
I have posted the question on [SO here](https://stackoverflow.com/questions/66052723/bad-token-in-signature-with-numba-guvectorize), but it does not meet much success.

Please, can we setup a constant number of columns for a result array in function signature?
I have tried this way, but get here below error message.

```python
import numpy as np
from numba import guvectorize

@guvectorize('void(float64[:], float64, uint32[:,2])', '(m),()->(m,2)', nopython=True)
def array_copy(data, delta, result):
    for i, val in np.ndenumerate(data):
        # Open i.
        i, = i
        result[i,:] = [i, int(val)+delta]

data = np.arange(3, dtype='float64')
res = np.zeros((data.shape[0], 2), dtype='uint32')
array_copy(data, 3, res)
```

```python
Traceback (most recent call last):

  File "<ipython-input-17-63f8983bbf61>", line 5, in <module>
    def array_copy(data, delta, result):

  File "/home/pierre/anaconda3/lib/python3.8/site-packages/numba/np/ufunc/decorators.py", line 177, in wrap
    guvec = GUVectorize(func, signature, **kws)

  File "/home/pierre/anaconda3/lib/python3.8/site-packages/numba/np/ufunc/decorators.py", line 49, in __new__
    return imp(func, signature, identity=identity, cache=cache,

  File "/home/pierre/anaconda3/lib/python3.8/site-packages/numba/np/ufunc/ufuncbuilder.py", line 298, in __init__
    self.sin, self.sout = parse_signature(signature)

  File "/home/pierre/anaconda3/lib/python3.8/site-packages/numba/np/ufunc/sigparse.py", line 49, in parse_signature
    outputs = list(parse(outs))

  File "/home/pierre/anaconda3/lib/python3.8/site-packages/numba/np/ufunc/sigparse.py", line 35, in parse
    raise ValueError('bad token in signature "%s"' % tok[1])

ValueError: bad token in signature "2"
```
user: yohplala
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6686: state: open
title: LoweringError when using prange with types.Optional array
body: - [ ] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi, 

We found an issue with `types.Optional` variabes breaking parfor lowering. An example below shows that if inner function returns an instance of none or numpy array, which would be typed as `types.Optional(types.Array(...))`, then using this result in a parfor loop breaks compilation because of mismatching types.

```
import numba
from numba import types, njit, prange
from numba.extending import overload
import numpy as np

@njit
def get_sortorder(arr):
    argsort_res = np.argsort(arr)
    is_sorted = np.array_equal(argsort_res, np.arange(len(arr)))
    ret = None if is_sorted else argsort_res

    return ret

@njit(parallel=True)
def get_nth_smallest(data, n):

    sort_order = get_sortorder(data)
    if sort_order is None:
        return data[:n]
    else:
        ret = np.empty(n, dtype=data.dtype)
        for i in prange(n):
        # for i in np.arange(n):        # this can be a workaround
            ret[i] = data[sort_order[i]]

        return ret

data = np.array([1, 3, 5, 7, 0, 8, 6, 4, 2, -1])
print(get_nth_smallest(data, 3))
```

And above gives:
```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
cannot store {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i1} to {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i8}*: mismatching types

File "test_numba_optional.1.py", line 56:
def get_nth_smallest(data, n):
    <source elided>
        ret = np.empty(n, dtype=data.dtype)
        for i in prange(n):
        ^

During: lowering "id=0[LoopNest(index_variable = parfor_index.14, range = (0, n, 1))]{56: <ir.Block at test_numba_optional.1.py (56)>}Var(parfor_index.14, test_numba_optional.1.py:56)" at test_numba_optional.1.py (56)
```

The workaround we use now is to apply `_nonoptional()` from [typedobjectutils.py](https://github.com/numba/numba/blob/1f66f137a7f2c7bd9e8288de863349fe7a05b105/numba/typed/typedobjectutils.py#L92) in the else branch.
My local attempts to fix this in `call_parallel_gufunc` in parfor_lowering.py by adding optional unpacking doesn't seem to work yet. So let's keep this on the issue tracker too.


Best Regards,
Alexey
user: kozlov-alexey
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6678: state: open
title: numba ufunc without explicit signature vs. xarray
body: numpy 1.20.0
numba 0.52.0
xarray 0.16.2
python 3.8

If I don't produce a list of signatures and rely on ``@vectorize``'d functions to be compiled upon first call, they crash if the first call is a xarray.DataArray.

FYI @shoyer

```python
import numba
import xarray


@numba.vectorize(nopython=True)
def double(x):
    return x * 2

a = xarray.DataArray(1)
double(a)
```
```
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-1-396b55cc58ef> in <module>
      8     return x * 2
      9 
---> 10 double(xarray.DataArray(1))

~/miniconda3/lib/python3.8/site-packages/numba/np/ufunc/dufunc.py in _compile_for_args(self, *args, **kws)
    185         argtys = []
    186         for arg in args[:nin]:
--> 187             argty = typeof(arg)
    188             if isinstance(argty, types.Array):
    189                 argty = argty.dtype

~/miniconda3/lib/python3.8/site-packages/numba/core/typing/typeof.py in typeof(val, purpose)
     33         msg = _termcolor.errmsg(
     34             f"Cannot determine Numba type of {type(val)}")
---> 35         raise ValueError(msg)
     36     return ty
     37 

ValueError: Cannot determine Numba type of <class 'xarray.core.dataarray.DataArray'>
```

## Workarounds
1. Explicitly declare signatures
2. Do a dummy call to a plain numpy array first
3. ``a.copy(data=double(a.data))``
user: crusaderky
issue_6677: state: open
title: Guiding users and search engines to latest docs
body: With the switchover to ReadTheDocs for Numba documentation hosting (https://numba.readthedocs.io/en/stable/), we need to figure out what to do with the historical docs hosted on gh-pages: http://numba.pydata.org/numba-doc/latest/

The `latest` doc on gh-pages is a symlink to http://numba.pydata.org/numba-doc/0.50.0/, and all past versions of the Numba docs have that same URL pattern.  Due to the age of the project, there is substantial search engine preference for the old docs, which leads users to outdated information.  For posterity, I think it would be good to preserve the old docs at their original URLs, but try to guide users (and search engines) to the new docs.  Since the likelihood of being able to regenerate 6+ years of historical documentation is low, we should plan to make changes to the HTML in place on the `gh-pages`  branch.  Also, I'm not aware of a way to implement an HTTP redirect for an entire subdirectory in gh-pages.

Following some out-of-band discussion, I can capture the suggestions here:

1. For all `latest/` doc pages, insert a `<meta http-equiv="refresh" content="0; URL=https://numba.readthedocs.io/en/stable/[rest of url]">` tag in the header to bounce browsers to the current docs.  Any pages linking to `latest/` should be prepared for docs that will change over time.
2. For all versioned docs (`0.50.0/` etc) we should insert a notification banner at the top (like RTD does: https://numba.readthedocs.io/en/0.51.1/) with a link to the RTD stable docs.
3. For all HTML pages, insert a `<link rel="canonical" href="https://numba.readthedocs.io/en/stable/[rest of url]">` tag to the RTD site.

Given the huge number of individual HTML pages, the above will require a script (that someone will have to create).
user: seibert
issue_6675: state: open
title: Parallelize (or fastmath) some methods of a jitclass
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

I was wondering if it would be possible to make certain methods inside of a jitclass be parallelised, or fastmath'd, etc.

Something like:

```python
import numba as nb

@nb.jitclass([('a',nb.float32)])
class JC:
    def __init__(self, a):
        self.a = a
    @nb.njit(parallel=True, fastmath=True)
    def fastfunc(self, b):
        for i in range(b):
            self.a += nb.float32(0.1)
```
user: sunwoo-kim
issue_6673: state: open
title: Requesting Implementation of Asynchronous Data Copies and Asynchronous Barrier since CUDA 11
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Hi,

I am kindly requesting the implementation of the two new functionality since Ampere/CUDA 11, i.e., [Asynchronous Data Copies](https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#memcpy_async) and [Asynchronous Barrier](https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#aw-barrier). They allow more flexible control flow and reduces kernel latency, respectively, and are accelerated by dedicated hardware since Ampere.

Thank you.

Best Regards,
Kun

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: K-Wu
labels: CUDA: CUDA related issue/PR
issue_6670: state: open
title: Fast path for overload attribute matching
body: Attribute typing tries all the templates for a data type, since a generic function of any template may match an attribute.
However, overload_method/overload_attribute only match a single attribute and have `_attr` stored, so there is no need for testing all templates. Some complex types have hundreds of attributes so this can matter sometimes. This PR provides a fast path for overloads, which would accelerate the common cases. Some benchmarking shows compilation time difference (not massive but significant).

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
forum https://numba.discourse.group/.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: ehsantn
labels: Effort - medium: Medium size effort needed
issue_6665: state: open
title: Nested dictionary construction erroneously accepting heterogeneous value types
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This:
```python
from numba import njit
import numpy as np

@njit
def foo():
    d = {0: {(0, 0, 0): 0.}, 1: {(1, 1): 0.}}
    return d

print(foo())
```
compiles when it shouldn't. The dictionary is heterogeneous in type which is unsupported, result is essentially a corrupt dictionary.

Note:
* key `0` maps to a dictionary of `3-tuple->float`
* key `1` maps to a dictionary of `2-tuple->float`

Originally reported here: https://gitter.im/numba/numba?at=601087fb063b6c68d51cb42a
thanks @ulupo.

user: stuartarchibald
labels: bug - miscompile: Bugs: miscompile
issue_6662: state: open
title: Update C code with Python API calls parsing tuples/kwargs to use bools where possible
body: From comment https://github.com/numba/numba/pull/6432/files#r534512470
user: stuartarchibald
labels: good second issue: A good issue for second time contributors
issue_6659: state: open
title: Memory alignment errors on ARM in unittests
body: Continuing to track memory alignment errors causing SIGBUS  on various ARM system from: https://github.com/numba/numba/issues/6345#issuecomment-765602660

user: stuartarchibald
labels: ISA: ARM: Issue related to ARM ISA
bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_6657: state: open
title: Need a method of identifying hardware/kernel combinations that can't handle unaligned loads
body: From https://github.com/numba/numba/issues/6345#issuecomment-764138674

Some tests are failing on the debian build farm because `arm64` kernels don't fix memory alignment errors https://github.com/numba/numba/issues/6345#issuecomment-764391346. Numba needs a way of checking if a system cannot handle unaligned loads such that unit tests which stress this behaviour are skipped. Currently:
https://github.com/numba/numba/blob/ca8132ba5e43fc3f79767046ed55217aeeabb35e/numba/tests/support.py#L79
is used as the "test", this being the only condition where this issue was observed until debian builds hit the same.
user: stuartarchibald
issue_6648: state: open
title: AOT compilation of jitclass
body: I couldnt find a way to AOT compile a whole class. 
So I guess it will be great to have that feature. I know methods can be AOT compiled which is a great feature but classes will add so much to it.  
The use cases are many, one can compile a whole class of methods instead of one by one. Also, a great way to obfuscate the code. 

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: zaheeroz
issue_6644: state: open
title: typed.List segfault, maybe from empty list.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This segfaults.
```python
from numba import njit
import numpy as np
from numba.typed import List

@njit
def demo_list_keys(nkeys):
    np.random.seed(0)
    # create some random sized lists for keys
    tl = List()
    for _ in range(nkeys):
        tl.append(List([x for x in range(np.random.randint(10))]))
    print(tl)

    for item in tl:
        print(item)

demo_list_keys(5)
```
user: stuartarchibald
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_6640: state: open
title: Nested dict-of-jitclass throws pickling error
body: Numba 0.52.0, 64-bit Python 3.7.3 on Windows
Discourse discussion is [here](https://numba.discourse.group/t/how-do-i-nest-dict-of-jitclass/434)

The code below doesn't work, but seems like it ought to

```python
from numba import types, typed, njit
from numba.experimental import jitclass

@jitclass([
    ("x", types.int64),
])
class Level1:
    def __init__(self):
        self.x = 12

level1 = Level1()  # Okay, I can create a Level1 instance
level1_instance_type = Level1.class_type.instance_type
level1_kv = (types.int64, level1_instance_type)

@jitclass([
    ("level1s", types.DictType(*level1_kv)),
])
class Level2(object):
    def __init__(self):
        self.level1s = typed.Dict.empty(*level1_kv)
        self.level1s[0] = Level1()


level2 = Level2()  # Okay, I can create a Level2 instance
level2_instance_type = Level2.class_type.instance_type
level2_kv = (types.int64, level2_instance_type)

@jitclass([
    ("level2s", types.DictType(*level2_kv)),
])
class Level3(object):
    def __init__(self):
        self.level2s = typed.Dict.empty(*level2_kv)

# _pickle.PicklingError: Can't pickle <class 'numba.experimental.jitclass.base.Level1'>: it's not found as numba.experimental.jitclass.base.Level1
# level3 = Level3()
```


user: nelson2005
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6633: state: open
title: list not cast to numpy ndarray
body: numba 0.52
numpy 1.19.5
python 3.8.6

The following code gives the stack trace below, however if I rerun it with line:8 uncommented it works just fine.

```
import numba

@numba.vectorize(nopython=True)
def if_(cond, a, b):
    return a if cond else b


# out = if_(True, 1, 2)
out = if_(True, [1, 2], [3, 4])
print(out)
```


```
Traceback (most recent call last):
  File "lib/python3.8/site-packages/IPython/core/interactiveshell.py", line 3418, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-2-53cd775debb9>", line 1, in <module>
    runfile('scratches/poc.py', wdir='scratches')
  File "Contents/plugins/python/helpers/pydev/_pydev_bundle/pydev_umd.py", line 197, in runfile
    pydev_imports.execfile(filename, global_vars, local_vars)  # execute the script
  File "Contents/plugins/python/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "scratches/poc.py", line 9, in <module>
    out = if_(True, [1, 2], [3, 4])
  File "lib/python3.8/site-packages/numba/np/ufunc/dufunc.py", line 201, in _compile_for_args
    return self._compile_for_argtys(tuple(argtys))
  File "lib/python3.8/site-packages/numba/np/ufunc/dufunc.py", line 218, in _compile_for_argtys
    cres, argtys, return_type = ufuncbuilder._compile_element_wise_function(
  File "lib/python3.8/site-packages/numba/np/ufunc/ufuncbuilder.py", line 144, in _compile_element_wise_function
    cres = nb_func.compile(sig, **targetoptions)
  File "lib/python3.8/site-packages/numba/np/ufunc/ufuncbuilder.py", line 93, in compile
    return self._compile_core(sig, flags, locals)
  File "lib/python3.8/site-packages/numba/np/ufunc/ufuncbuilder.py", line 125, in _compile_core
    cres = compiler.compile_extra(typingctx, targetctx,
  File "lib/python3.8/site-packages/numba/core/compiler.py", line 602, in compile_extra
    return pipeline.compile_extra(func)
  File "lib/python3.8/site-packages/numba/core/compiler.py", line 352, in compile_extra
    return self._compile_bytecode()
  File "lib/python3.8/site-packages/numba/core/compiler.py", line 414, in _compile_bytecode
    return self._compile_core()
  File "lib/python3.8/site-packages/numba/core/compiler.py", line 394, in _compile_core
    raise e
  File "lib/python3.8/site-packages/numba/core/compiler.py", line 385, in _compile_core
    pm.run(self.state)
  File "lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 339, in run
    raise patched_exception
  File "lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 330, in run
    self._runPass(idx, pass_inst, state)
  File "lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "lib/python3.8/site-packages/numba/core/typed_passes.py", line 94, in run_pass
    typemap, return_type, calltypes = type_inference_stage(
  File "lib/python3.8/site-packages/numba/core/typed_passes.py", line 72, in type_inference_stage
    infer.propagate(raise_errors=raise_errors)
  File "lib/python3.8/site-packages/numba/core/typeinfer.py", line 1071, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type pyobject
During: typing of argument at scratches/poc.py (5)
File "poc.py", line 5:
def if_(cond, a, b):
    return a if cond else b

user: marouane-miftah
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6627: state: open
title: Passing elements by reference to CUDA device kernel
body: # Passing element by reference to CUDA device kernel
I am trying to make a function that modifies the data of some array in-place. I also would like to do it in a way that can be compiled for CPU or GPU targets. This can be accomplished by passing a reference to an array element, but modifying that element requires some confusing semantics.

### Minimal example on CPU 
using classic broadcast semantics. This works in numpy and numba no_python mode.
```python
def f1(x):
    x *= 2.
    # x[:] = x * 2.  # Alternatively
    # x = x * 2.  # This would be wrong because "x" would refer to a new array

assert_working(f1, cpu=True)  # success
f1_jit = numba.njit(f1)
assert_working(f1_jit, cpu=True)  # success
```
Here's that assert function used above and below.
```python
def assert_working(some_kernel_or_function):
    x0 = np.ones(3)
    xtruth = np.ones(3) * 2.
    if cpu:
        some_kernel_or_function(x0)
    else:
        dx0 = cuda.to_device(x0)
        some_kernel_or_function(dx0)
        x0 = dx0.copy_to_host()
    assert np.all(x0 == xtruth)
```

### Minimal non-working example with CUDA
CUDA does not broadcast, so it fails to compile. 
```python
f1_gpu_onethread = cuda.jit(f1)[1,1]
assert_working(f1_gpu_onethread, cpu=False)  # fails to compile. No implementation of imul(DeviceArray 1x3, float32)
```
That example is naive because there is one thread dealing with a 3-element array. That can be parallelized by element; however, `f1` modifies in-place. That means you have to pass data references as opposed to data values.

### More realistic non-working example with CUDA
using thread parallelism. First off, here's a wrapper that should turn a regular python function with broadcast semantics into a CUDA kernel. This kind of helper is very useful to put in a library when you have a user working with `f1` without any idea how CUDA or numba work. In this simple example, it's very similar to `vectorize`.
```python
def get_wrapped_kernel(py_func):
    device_corekernel = cuda.jit(device=True, inline=True)(py_func)
    @cuda.jit(device=False)
    def f1_launchable_wrapper(x):
        i = cuda.threadIdx.x
        thread_x = x[i:i+1]  # View onto one element of x
        device_corekernel(thread_x)
    return f1_launchable_wrapper
```
and here is the ideal situation that is my desired functionality
```python
f1_gpu_parallel = get_wrapped_kernel(f1)[1,3]
assert_working(f1_gpu_parallel, cpu=False)  # fails to compile. No implementation of imul(DeviceArray 1x1, float32)
```
Note that we have successfully passed a 1x1 reference to an element of the DeviceArray, but `numba.cuda` does not like the "imul".

### Working example with confusing semantics
In-place modification with deindexing does work. Problem is that `f2` is not CPU-compatible, and it is unfamiliar/confusing to a user familiar with numpy.
```python
def f2(x):
    x[0] *= 2

f2_gpu_parallel = get_wrapped_kernel(f2)[1,3]
assert_working(f2_gpu_parallel, cpu=False)  # success
assert_working(f2, cpu=True)  # fails because only first element is modified
```

My question is how to get the CUDA compiler to recognize `imul(DeviceArray 1x1, float)` semantics, plus `iadd`, `isub`, `mul`, etc. Even if it disallows non-1x1 shaped arrays, it would still solve the problem. I think this is possible because of the working example above.

`vectorize(..., target='cuda')` might work for this simple example. The problem with that approach is the wrapper can't be compiled as a device kernel to be used elsewhere, and one cannot pass additional arguments with strange shapes, such as tuples of parameters. Perhaps I am wrong on that?

I would be happy to take a stab at adding this feature, but I don't know where to begin - still trying to wrap my head around the CUDA compiler.

user: atait
labels: CUDA: CUDA related issue/PR
stale: Marker label for stale issues.
issue_6624: state: open
title: np.where fails in @vectorize
body: numba 0.52
numpy 0.19.4
python 3.8.6

numpy.where seems to only work inside ``@jit``; I can't make it work inside ``@vectorize`` or ``@guvectorize``: 
```python
@numba.vectorize(["f8(f8)"], nopython=True)
def f(a):
    return np.where(a, 1.0, 2.0)
```
Output:
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No conversion from array(float64, 0d, C) to float64 for '$14return_value.6', defined at None
```
#### Workaround:
Use the ternary pure Python operator ``a if cond else b``.

#### Impact:
This issue impacts me because I'm trying to generate code that transparently works both with and without ``@vectorize`` decorator, and I'm forced to change the code I emit inside the function because of this issue.


user: crusaderky
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6617: state: open
title: Add support for more complex signatures to guvectorize
body: 
## Feature request

I usually work with histograms, where one array contains the bin content and one array the edges. That means that the edges array is always one element larger than the data array. In order to have this supported properly we would need a `guvectorize` signature of the form:

```
'(n)->(n+1)'
```

Would it be possible to maybe in general allow some form of arithmetic operations in the signature (i.e. addition, multiplication, etc) of given inputs? For example I can imagine this one also to be quite useful:

```
'(n),(m)->(m*n)'
```

Thanks.

By the way I am very happy with how `numba` has been evolving recently, it is quite straight forward to even use it with quite complex `numpy` functions these days.
user: cosama
issue_6613: state: open
title: Wrong result when call numba function which returns structured array inside of other numba function 
body: The wrong result when getting an item from a structured array returned by numba function ONLY if this function is called inside of other numba function.

```python
import numpy as np
import numba as nb

DATA = np.dtype([("A", np.uint16), ("B", np.uint16)])

@nb.njit()
def get_data(data):
    result = np.zeros(1, dtype=DATA)
    result[0]["A"] = data
    result[0]["B"] = data
    return result

@nb.njit()
def inside_call():
    print(get_data(100))
    print(get_data(100)[0])

inside_call()
print(get_data(100))
print(get_data(100)[0])
```

returns:

> [(100, 100)]
(57054, 57054)   <--- wrong
[(100, 100)]
(100, 100)
user: ceo-domido
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6611: state: open
title: Feature Request: Support ddof argument in np.nan[std | var]
body: ---

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Related to https://github.com/numba/numba/issues/6610, it would also be great if the `ddof` argument could be supported in `np.nanstd` and `np.nanvar`

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

user: mroeschke
labels: good first issue: A good issue for a first time contributor
issue_6606: state: open
title: [ppc64le] RuntimeDyldELF/TOC problem (segfaults)
body: (spawned from #4026) 

## Summary

A missing `nop` after a branch-instruction results in RuntimeDyldELF overwriting an instruction with the TOC restoration code. This happnes only in reloc-mode=static.

The workaround in numba was to change (for ppc) `reloc_mode`  back to `pic` (https://github.com/numba/numba/commit/31ddd81d559c4aa79fb25e4c7b45b44451df95d5)

See bug-identification by `obilaniu` within https://github.com/numba/numba/issues/4026#issuecomment-487296000

## Reproduction

```sh
# DRAFT
# on ppc64le, tested on ubuntu 16.04, Power8, Power9, qemu ppc64le

### Install Miniconda

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-ppc64le.sh
bash Miniconda3-latest-Linux-ppc64le.sh 

### Setup Conda Environment

conda create -n ppc-segfault python=3.6 numpy=1.15 llvmlite=0.35.* scipy jinja2 cffi conda-build -y
conda activate ppc-segfault
conda install gcc_linux-ppc64le gxx_linux-ppc64le conda-build make  -y

### use your preferred location

cd ~ && mkdir numba-6606 && cd numba-6606

### get a 0.52.0 version of numba patched to use `static` for `ppc`

git clone -b 0.52.0-static https://github.com/abebeos/numba.git numba-static
cd numba-static
python setup.py build_ext --inplace

### this segfaults

./runtests.py -v numba.tests.npyufunc.test_parallel_ufunc_issues.TestParGUfuncIssues

```

## Suggested Fix

The fix was identified during the work-in to the compiler-side of the problem. Whilst looking for similar work on the relevant (pointed out by `nemanjai` within https://github.com/numba/numba/issues/4026#issuecomment-657941602) `PPCISelLowering.cpp / callsShareTOCBase()`, the comments on the following commit indicated its relevance for the problem:

https://reviews.llvm.org/rG2812c1515627904e31605bbd4f25a887a1f8eb12

The backported (llvm-10.x) patch (incl. adopted tests):

* for llvm-10.x: https://reviews.llvm.org/D94183 (cannot merge, no maintenance )
* for llvm-10.x via llvmlite: https://github.com/numba/llvmlite/pull/684
* for llvm-11.x via llvmlite: https://github.com/numba/llvmlite/pull/691
* for llvm-12.x: original patch is already in

### Binaries

Patched llvm-10 / llvmlite-0.35.0 available (temporarily, for testing):

```sh
conda install llvm -c abebeos
conda install llvmlite -c abebeos
```

## Validation

(numba repo does not automatically test on PowerPC, see https://github.com/numba/llvmlite/pull/684#issuecomment-753946728)

I've validated the fix manually on Power8 hardware, see https://github.com/numba/llvmlite/pull/684#issuecomment-755295463.

The validation should be trivial for any dev with a ready dev-system.

Validation with pre-compiled binaries (After doing the Reproduction steps above):

```sh
# Ensure you've executed the reproduction steps

### this llvm contains the fix

conda install llvmlite -c abebeos

### rebuild numba (just to be sure)

cd ~/numba-6606/numba-static
python setup.py build_ext --inplace 

### should work now
./runtests.py -v numba.tests.npyufunc.test_parallel_ufunc_issues.TestParGUfuncIssues

# full tests
./runtests.py -m16 #your machine thread count

```




user: ghost
labels: llvm: LLVM related issues
ISA: POWER: Issue related to POWER ISA
issue_6602: state: open
title: Never add multiply defined scalars to shape data structures.
body: Resolves #6597. 

Previously, we would add scalars and detect multiple definitions along the way and then we'd remove them at the end.  The problem with that approach is that intermediate steps consult the data structures and may think that a variable is a constant at some point (and then use the constant in some build_tuple expr) when in reality the variable is in a loop and may be updated by the later part of the loop in a previous iteration.  Now, we exclude non-array variables with multiple definitions from ever going in the data structures.

user: DrTodd13
issue_6600: state: open
title: Numba accepts floats as array index
body: ## Reporting a bug
Hi everyone :-)

While I was playing around with #6597 I noticed that numba seems to accept floats as indices for numpy arrays when using a range expression, i.e. ```:```. 

~As far as I can tell numba does return what you would naturally expect, but~ the same operation does throw an exception in the pure Python/numpy implementation. (And that is probably a good thing :-P)

Cheers and happy Holidays!

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

## Reproducer and output
```python
import numba as nb
import numpy as np

print("Numba Version:", nb.__version__)

def slicer(arr, idx):
    return arr[idx]

def range_slicer(arr, idx):
    return arr[:idx]

nb_range_slicer = nb.njit(range_slicer)
nb_slicer = nb.njit(slicer)

ARR = np.arange(10)
TESTS = {
    "Python Slice":slicer,
    "Numba Slice":nb_slicer,
    "Python Range Slice": range_slicer,
    "Numba Range Slice": nb_range_slicer
}

for name, fun in TESTS.items():
    print(f"\n{name}: ", end="")
    try:
        print(fun(ARR, 4.5))
    except Exception as e:
        print("Exception raised!")
        print(e)
```

```terminal
Numba Version: 0.52.0

Python Slice: Exception raised!
only integers, slices (`:`), ellipsis (`...`), numpy.newaxis (`None`) and integer or boolean arrays are valid indices

Numba Slice: Exception raised!
Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function getitem>) found for signature:
 
 >>> getitem(array(int64, 1d, C), float64)
 
There are 22 candidate implementations:
  - Of which 20 did not match due to:
  Overload of function 'getitem': File: <numerous>: Line N/A.
    With argument(s): '(array(int64, 1d, C), float64)':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'GetItemBuffer.generic': File: numba/core/typing/arraydecl.py: Line 162.
    With argument(s): '(array(int64, 1d, C), float64)':
   Rejected as the implementation raised a specific error:
     TypeError: unsupported array index type float64 in [float64]
  raised from /home/hpahl/anaconda3/lib/python3.7/site-packages/numba/core/typing/arraydecl.py:69

During: typing of intrinsic-call at bugs/float_slice.py (7)

File "bugs/float_slice.py", line 7:
def slicer(arr, idx):
    return arr[idx]
    ^


Python Range Slice: Exception raised!
slice indices must be integers or None or have an __index__ method

Numba Range Slice: [0 1 2 3]
```
user: HPLegion
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6597: state: open
title: Parallel loop prange gives wrong outcomes
body: Hi, I've encountered wrong outcomes when prange is used. The issue can be reproduced with the code below.

```
import numba
import numpy as np

def foo(a, b):
    n_rows = b.shape[0]
    for x in numba.prange(1):
        i_row = 0
        for _ in range(n_rows):
            bi = b[i_row]
            print(i_row, a[i_row, :bi])
            i_row += 1
            if i_row >= n_rows:
                i_row -= n_rows


a = np.arange(10).reshape((10, 1))
b = np.ones(10, np.int64)

# This prints the expected result, i.e. prints 0,[0] \n 1,[1] \n 2,[2], etc
numba.njit(foo, parallel=False)(a,b)

# This produces a wrong result, i.e. prints 0,[0] \n 0,[0] \n 0,[0], etc
numba.njit(foo, parallel=True)(a,b)

```

This started to happen with numba 0.47, until 0.46 was running as expected (though with numba 0.46 and 0.47 I had to use llvmlite 0.32 since more recent versions give an error at compile time).
user: stavoltafunzia
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6592: state: open
title: Fix `python -We` support wrt the threading backend loading sequence.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

See: https://github.com/numba/numba/issues/6350#issuecomment-728174860

This needs fixing.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: stuartarchibald
issue_6588: state: open
title: dict getitem in list comprehension results in LLVM IR parsing error
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

#### Example Code
```python
from numba import jit

@jit(forceobj=True)
def foo():
    mydict = {'zero': 0}
    return [mydict['zero'] for x in (1,)]

print(foo())
```
#### Traceback
```
$ python repr.py
Traceback (most recent call last):
  File "repr.py", line 8, in <module>
    print(foo())
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 433, in _compile_for_args
    raise e
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 366, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 857, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 104, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 602, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 352, in compile_extra
    return self._compile_bytecode()
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 414, in _compile_bytecode
    return self._compile_core()
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 394, in _compile_core
    raise e
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 385, in _compile_core
    pm.run(self.state)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 339, in run
    raise patched_exception
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 330, in run
    self._runPass(idx, pass_inst, state)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 289, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 262, in check
    mangled = func(compiler_state)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/object_mode_passes.py", line 120, in run_pass
    lowered = backend_object_mode()
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/object_mode_passes.py", line 115, in backend_object_mode
    return self._py_lowering_stage(state.targetctx,
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/object_mode_passes.py", line 78, in _py_lowering_stage
    lower.lower()
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/lowering.py", line 174, in lower
    self.library.add_ir_module(self.module)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/numba/core/codegen.py", line 648, in add_ir_module
    ll_module = ll.parse_assembly(ir)
  File "/home/cebtenzzre/.local/lib/python3.8/site-packages/llvmlite/binding/module.py", line 25, in parse_assembly
    raise RuntimeError("LLVM IR parsing error\n{0}".format(errmsg))
RuntimeError: Failed in object mode pipeline (step: object mode backend)
LLVM IR parsing error
<string>:553:48: error: expected value token
  %".427" = call i8* @"PyLong_FromSsize_t"(i64 zero)
                                               ^
```

#### Software Versions
numba 0.52.0
Python 3.8
user: cebtenzzre
labels: objectmode: object mode related issue
bug - ice: Bugs: internal compiler error
issue_6581: state: open
title: Error iterating over the values of a dictionary
body: - [ ] (I am using the Conda release.) I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG). 
- [X] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.
-------------

I'm getting a perplexing key error when trying to remove the values of a dictionary from a set -- it works differently depending on whether I compile the code or not.

Here is a minimum working example:

```

import numba as nb
from numba.typed import Dict

params_default = nb.typed.Dict.empty(
    key_type=nb.typeof('1'),
    value_type=nb.typeof('1')
)

  
@nb.njit
def remove_values(dictionary, input_set):
    #removes values of the dictionary from the input set
    print(dictionary, input_set)
    for value in dictionary.values():
        print(input_set)
        print(value)
        if value in input_set:
            input_set.remove(value)
    print(input_set)
    return input_set
    
test_set = set([1,2,3,4,5,6])
test_dictionary = Dict() 
for x in [1,2,3,4,5,6]:
    test_dictionary[x] = 1
    
print(test_dictionary)

test_set = remove_values(test_dictionary, test_set)
print(test_set)

test_set = set([1,2,3,4,5,6])
input_set = test_set
dictionary = test_dictionary

print(dictionary, input_set)
for value in dictionary.values():
    print(input_set)
    print(value)
    if value in input_set:
        input_set.remove(value)
print(input_set)
```

This should output the same result twice. Instead, I get the following -- where you can see that the compiled version removes every element of the set:

```
{1: 1, 2: 1, 3: 1, 4: 1, 5: 1, 6: 1}
{1: 1, 2: 1, 3: 1, 4: 1, 5: 1, 6: 1} {1, 2, 3, 4, 5, 6}
{1, 2, 3, 4, 5, 6}
1
{1, 2, 3, 4, 5, 6}
2
{1, 2, 3, 4, 5, 6}
3
{1, 2, 3, 4, 5, 6}
4
{1, 2, 3, 4, 5, 6}
5
{1, 2, 3, 4, 5, 6}
6
{1, 2, 3, 4, 5, 6}
set()
{1: 1, 2: 1, 3: 1, 4: 1, 5: 1, 6: 1} {1, 2, 3, 4, 5, 6}
{1, 2, 3, 4, 5, 6}
1
{2, 3, 4, 5, 6}
1
{2, 3, 4, 5, 6}
1
{2, 3, 4, 5, 6}
1
{2, 3, 4, 5, 6}
1
{2, 3, 4, 5, 6}
1
{2, 3, 4, 5, 6}
```

I was given the following warning:

```
C:\Users\lnajt\anaconda3\lib\site-packages\numba\ir_utils.py:2041: NumbaPendingDeprecationWarning: 
Encountered the use of a type that is scheduled for deprecation: type 'reflected set' found for argument 'input_set' of function 'remove_values'.

For more information visit http://numba.pydata.org/numba-doc/latest/reference/deprecation.html#deprecation-of-reflection-for-list-and-set-types

File "Removing_Elements_Debugging.py", line 12:
@nb.njit
def remove_values(dictionary, input_set):
^

  warnings.warn(NumbaPendingDeprecationWarning(msg, loc=loc))
```
user: ElleNajt
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6571: state: open
title: All Numba internal registrations should happen before extensions are run.
body: We have a Numba extension that would like to look at, derive from and re-use some of the type inference functions that Numba already has internally.  What I think I am seeing is that the hook where the Numba extension callbacks are run is happening before some of Numba's internal function registrations.  Therefore, my extension can't see those and re-use them.

To get specific, I put a print in numba.core.typing.templates.Registry.register_attr.  I see a bunch of Numba register_attrs and then I see my extension code run and then after that I see more Numba register_attrs shown below.  In particular, I need the arraydecl.ArrayAtrribute one and not only is it not in the list of attributes that I see when my extension runs (because again I think the Numba registration is happening after that) but that class (and arraydecl itself) doesn't seem to be exported by Numba so I can't just hard-code numba.core.typing.arraydecl.ArrayAttribute either.

```numba register_attr: <class 'numba.core.typing.cffi_utils.FFIAttribute'>
numba register_attr: <class 'numba.core.typing.enumdecl.EnumAttribute'>
numba register_attr: <class 'numba.core.typing.enumdecl.EnumClassAttribute'>
numba register_attr: <class 'numba.core.typing.collections.NamedTupleAttribute'>
numba register_attr: <class 'numba.core.typing.collections.NamedTupleClassAttribute'>
numba register_attr: <class 'numba.core.typing.listdecl.ListAttribute'>
numba register_attr: <class 'numba.core.typing.setdecl.SetAttribute'>
numba register_attr: <class 'numba.core.typing.arraydecl.ArrayAttribute'>
numba register_attr: <class 'numba.core.typing.arraydecl.DTypeAttr'>
numba register_attr: <class 'numba.core.typing.arraydecl.RecordAttribute'>
numba register_attr: <class 'numba.core.typing.arraydecl.ArrayCTypesAttribute'>
numba register_attr: <class 'numba.core.typing.arraydecl.ArrayFlagsAttribute'>
numba register_attr: <class 'numba.core.typing.arraydecl.NestedArrayAttribute'>
numba register_attr: <class 'numba.core.typing.templates.OverloadAttributeTemplate_<class 'numba.core.types.containers.BaseTuple'>_index'>
numba register_attr: <class 'numba.core.typing.templates.OverloadAttributeTemplate_<class 'numba.core.types.scalars.Float'>_view'>
numba register_attr: <class 'numba.core.typing.templates.OverloadAttributeTemplate_<class 'numba.core.types.scalars.Integer'>_view'>
numba register_attr: <class 'numba.core.typing.templates.OverloadAttributeTemplate_<class 'numba.core.types.npytypes.Array'>_all'>
numba register_attr: <class 'numba.core.typing.templates.OverloadAttributeTemplate_<class 'numba.core.types.npytypes.Array'>_any'>
```
user: DrTodd13
issue_6559: state: open
title: RISC-V Support
body: Hi.
It doesn't seem that you have migrated - so I am reminding about the current situation:


> $ python3 setup.py build
> /usr/lib/python3.8/site-packages/setuptools/dist.py:473: UserWarning: Normalizing '0.36.0dev0+8.ge0e03f3' to '0.36.0.dev0+8.ge0e03f3'
>   warnings.warn(
> running build
> got version from VCS {'version': '0.36.0dev0+8.ge0e03f3', 'full': 'e0e03f3d8fc8f5b616381b0814bfec3cfc0769f9'}
> running build_ext
> /usr/bin/python3 /home/oceanfish81/llvmlite/ffi/build.py
> LLVM version... 11.0.0
> 

> The LLVM version check for supported versions has been overridden.
> This is unsupported behaviour, llvmlite may not work as intended.
> Requested LLVM version: 11.0.0
> 
> 
> SVML not detected
> # static-libstdc++ avoids runtime dependencies on a
> # particular libstdc++ version.
> g++  -shared   -fPIC -I/usr/include -std=c++14 -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -g -flto assembly.cpp bitcode.cpp core.cpp initfini.cpp module.cpp value.cpp executionengine.cpp transforms.cpp passmanagers.cpp targets.cpp dylib.cpp linker.cpp object_file.cpp custom_passes.cpp -o libllvmlite.so  -L/usr/lib64 -flto -Wl,--exclude-libs=ALL -lLLVM
> 
> transforms.cpp:10:32: error: redefinition of ‘llvm::PassManagerBuilder* llvm::unwrap(LLVMPassManagerBuilderRef)’
>    10 |     inline PassManagerBuilder *unwrap(LLVMPassManagerBuilderRef P) {
>       |                                ^~~~~~
> In file included from transforms.cpp:4:
> /usr/include/llvm/Transforms/IPO/PassManagerBuilder.h:255:28: note: ‘llvm::PassManagerBuilder* llvm::unwrap(LLVMPassManagerBuilderRef)’ previously defined here
>   255 | inline PassManagerBuilder *unwrap(LLVMPassManagerBuilderRef P) {
>       |                            ^~~~~~
> transforms.cpp:14:38: error: redefinition of ‘LLVMOpaquePassManagerBuilder* llvm::wrap(llvm::PassManagerBuilder*)’
>    14 |     inline LLVMPassManagerBuilderRef wrap(PassManagerBuilder *P) {
>       |                                      ^~~~
> In file included from transforms.cpp:4:
> /usr/include/llvm/Transforms/IPO/PassManagerBuilder.h:259:34: note: ‘LLVMOpaquePassManagerBuilder* llvm::wrap(llvm::PassManagerBuilder*)’ previously defined here
>   259 | inline LLVMPassManagerBuilderRef wrap(PassManagerBuilder *P) {
>       |                                  ^~~~
> custom_passes.cpp:408:2: error: #error Invalid LLVM version/LLVM_VERSION_MAJOR not defined
>   408 | #error Invalid LLVM version/LLVM_VERSION_MAJOR not defined
>       |  ^~~~~
> custom_passes.cpp:446:9: error: expected unqualified-id before ‘return’
>   446 |         return mutated;
>       |         ^~~~~~
> custom_passes.cpp:447:6: error: expected ‘;’ after struct definition
>   447 |     }
>       |      ^
>       |      ;
> custom_passes.cpp: In member function ‘virtual bool RefPrunePass::runOnFunction(llvm::Function&)’:
> custom_passes.cpp:216:34: error: ‘runFanoutPrune’ was not declared in this scope; did you mean ‘runDiamondPrune’?
>   216 |                 local_mutated |= runFanoutPrune(F, /*prune_raise*/false);
>       |                                  ^~~~~~~~~~~~~~
>       |                                  runDiamondPrune
> custom_passes.cpp:218:34: error: ‘runFanoutPrune’ was not declared in this scope; did you mean ‘runDiamondPrune’?
>   218 |                 local_mutated |= runFanoutPrune(F, /*prune_raise*/true);
>       |                                  ^~~~~~~~~~~~~~
>       |                                  runDiamondPrune
> custom_passes.cpp: In member function ‘bool RefPrunePass::runPerBasicBlockPrune(llvm::Function&)’:
> custom_passes.cpp:271:26: error: ‘isNonNullFirstArg’ was not declared in this scope
>   271 |                     if (!isNonNullFirstArg(ci)) {
>       |                          ^~~~~~~~~~~~~~~~~
> custom_passes.cpp:302:35: error: ‘isRelatedDecref’ was not declared in this scope
>   302 |                     if (decref && isRelatedDecref(incref, decref)) {
>       |                                   ^~~~~~~~~~~~~~~
> custom_passes.cpp: In member function ‘bool RefPrunePass::runDiamondPrune(llvm::Function&)’:
> custom_passes.cpp:379:9: error: ‘listRefOps’ was not declared in this scope
>   379 |         listRefOps(F, IsIncRef, incref_list);
>       |         ^~~~~~~~~~
> custom_passes.cpp:396:22: error: ‘isRelatedDecref’ was not declared in this scope
>   396 |                 if (!isRelatedDecref(incref, decref)) continue;
>       |                      ^~~~~~~~~~~~~~~
> custom_passes.cpp:414:27: error: ‘verifyFanoutBackward’ was not declared in this scope
>   414 |                     if ( !verifyFanoutBackward(incref, incref->getParent(), &tail_nodes) )
>       |                           ^~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp:419:25: error: ‘hasDecrefBetweenGraph’ was not declared in this scope
>   419 |                     if (hasDecrefBetweenGraph(incref->getParent(), decref->getParent())) {
>       |                         ^~~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp:445:9: warning: no return statement in function returning non-void [-Wreturn-type]
>   445 |         }
>       |         ^
> custom_passes.cpp: In function ‘bool runFanoutPrune(llvm::Function&, bool)’:
> custom_passes.cpp:521:9: error: ‘listRefOps’ was not declared in this scope
>   521 |         listRefOps(F, IsIncRef, incref_list);
>       |         ^~~~~~~~~~
> custom_passes.cpp:524:9: error: ‘SmallBBSet’ was not declared in this scope
>   524 |         SmallBBSet bad_blocks;
>       |         ^~~~~~~~~~
> custom_passes.cpp:528:17: error: ‘bad_blocks’ was not declared in this scope
>   528 |             if (bad_blocks.count(incref->getParent())) {
>       |                 ^~~~~~~~~~
> custom_passes.cpp:534:17: error: ‘hasAnyDecrefInNode’ was not declared in this scope
>   534 |             if (hasAnyDecrefInNode(incref->getParent())){
>       |                 ^~~~~~~~~~~~~~~~~~
> custom_passes.cpp:539:23: error: expected ‘;’ before ‘decref_blocks’
>   539 |             SmallBBSet decref_blocks;
>       |                       ^~~~~~~~~~~~~~
>       |                       ;
> custom_passes.cpp:541:37: error: ‘bad_blocks’ was not declared in this scope
>   541 |             if ( findFanout(incref, bad_blocks, &decref_blocks, prune_raise_exit) ) {
>       |                                     ^~~~~~~~~~
> custom_passes.cpp:541:50: error: ‘decref_blocks’ was not declared in this scope
>   541 |             if ( findFanout(incref, bad_blocks, &decref_blocks, prune_raise_exit) ) {
>       |                                                  ^~~~~~~~~~~~~
> custom_passes.cpp:541:18: error: ‘findFanout’ was not declared in this scope
>   541 |             if ( findFanout(incref, bad_blocks, &decref_blocks, prune_raise_exit) ) {
>       |                  ^~~~~~~~~~
> custom_passes.cpp:560:40: error: ‘isRelatedDecref’ was not declared in this scope
>   560 |                         if ( (decref = isRelatedDecref(incref, &ii)) ) {
>       |                                        ^~~~~~~~~~~~~~~
> custom_passes.cpp:569:53: error: ‘stats_fanout_raise’ was not declared in this scope
>   569 |                             if (prune_raise_exit)   stats_fanout_raise += 1;
>       |                                                     ^~~~~~~~~~~~~~~~~~
> custom_passes.cpp:570:53: error: ‘stats_fanout’ was not declared in this scope
>   570 |                             else                    stats_fanout += 1;
>       |                                                     ^~~~~~~~~~~~
> custom_passes.cpp:579:41: error: ‘stats_fanout_raise’ was not declared in this scope
>   579 |                 if (prune_raise_exit)   stats_fanout_raise += 1;
>       |                                         ^~~~~~~~~~~~~~~~~~
> custom_passes.cpp:580:41: error: ‘stats_fanout’ was not declared in this scope
>   580 |                 else                    stats_fanout += 1;
>       |                                         ^~~~~~~~~~~~
> custom_passes.cpp: At global scope:
> custom_passes.cpp:607:39: error: ‘SmallBBSet’ has not been declared
>   607 |     bool findFanout(CallInst *incref, SmallBBSet &bad_blocks, SmallBBSet *decref_blocks, bool prune_raise_exit) {
>       |                                       ^~~~~~~~~~
> custom_passes.cpp:607:63: error: ‘SmallBBSet’ has not been declared
>   607 |     bool findFanout(CallInst *incref, SmallBBSet &bad_blocks, SmallBBSet *decref_blocks, bool prune_raise_exit) {
>       |                                                               ^~~~~~~~~~
> custom_passes.cpp: In function ‘bool findFanout(llvm::CallInst*, int&, int*, bool)’:
> custom_passes.cpp:614:9: error: ‘SmallBBSet’ was not declared in this scope
>   614 |         SmallBBSet raising_blocks, *p_raising_blocks = NULL;
>       |         ^~~~~~~~~~
> custom_passes.cpp:616:32: error: ‘p_raising_blocks’ was not declared in this scope
>   616 |         if( prune_raise_exit ) p_raising_blocks = &raising_blocks;
>       |                                ^~~~~~~~~~~~~~~~
> custom_passes.cpp:616:52: error: ‘raising_blocks’ was not declared in this scope
>   616 |         if( prune_raise_exit ) p_raising_blocks = &raising_blocks;
>       |                                                    ^~~~~~~~~~~~~~
> custom_passes.cpp:618:87: error: ‘p_raising_blocks’ was not declared in this scope
>   618 |         if ( findFanoutDecrefCandidates(incref, head_node, bad_blocks, decref_blocks, p_raising_blocks) ) {
>       |                                                                                       ^~~~~~~~~~~~~~~~
> custom_passes.cpp:618:14: error: ‘findFanoutDecrefCandidates’ was not declared in this scope
>   618 |         if ( findFanoutDecrefCandidates(incref, head_node, bad_blocks, decref_blocks, p_raising_blocks) ) {
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp:620:78: error: request for member ‘size’ in ‘* decref_blocks’, which is of non-class type ‘int’
>   620 |                 errs() << "forward pass candids.size() = " << decref_blocks->size() << "\n";
>       |                                                                              ^~~~
> custom_passes.cpp:624:32: error: request for member ‘size’ in ‘* decref_blocks’, which is of non-class type ‘int’
>   624 |             if (decref_blocks->size() == 0) {
>       |                                ^~~~
> custom_passes.cpp:627:61: error: ‘raising_blocks’ was not declared in this scope
>   627 |                     errs() << "missing decref blocks = " << raising_blocks.size() << "\n";
>       |                                                             ^~~~~~~~~~~~~~
> custom_passes.cpp:632:22: error: ‘raising_blocks’ was not declared in this scope
>   632 |                 if ( raising_blocks.size() == 0) {
>       |                      ^~~~~~~~~~~~~~
> custom_passes.cpp:636:41: error: ‘begin’ was not declared in this scope
>   636 |                         for (auto bb : *decref_blocks){
>       |                                         ^~~~~~~~~~~~~
> custom_passes.cpp:636:41: note: suggested alternatives:
> In file included from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/bits/range_access.h:108:37: note:   ‘std::begin’
>   108 |   template<typename _Tp> const _Tp* begin(const valarray<_Tp>&);
>       |                                     ^~~~~
> In file included from /usr/include/c++/10/bits/range_access.h:36,
>                  from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/initializer_list:90:5: note:   ‘std::begin’
>    90 |     begin(initializer_list<_Tp> __ils) noexcept
>       |     ^~~~~
> In file included from /usr/include/llvm/Support/YAMLTraits.h:23,
>                  from /usr/include/llvm/IR/DiagnosticInfo.h:24,
>                  from /usr/include/llvm/Analysis/OptimizationRemarkEmitter.h:19,
>                  from /usr/include/llvm/Analysis/InlineCost.h:18,
>                  from /usr/include/llvm/Transforms/IPO/Attributor.h:108,
>                  from /usr/include/llvm/LinkAllPasses.h:44,
>                  from custom_passes.cpp:19:
> /usr/include/llvm/Support/YAMLParser.h:380:35: note:   ‘llvm::yaml::begin’
>   380 | typename CollectionType::iterator begin(CollectionType &C) {
>       |                                   ^~~~~
> custom_passes.cpp:636:41: error: ‘end’ was not declared in this scope
>   636 |                         for (auto bb : *decref_blocks){
>       |                                         ^~~~~~~~~~~~~
> custom_passes.cpp:636:41: note: suggested alternatives:
> In file included from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/bits/range_access.h:110:37: note:   ‘std::end’
>   110 |   template<typename _Tp> const _Tp* end(const valarray<_Tp>&);
>       |                                     ^~~
> In file included from /usr/include/c++/10/bits/range_access.h:36,
>                  from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/initializer_list:101:5: note:   ‘std::end’
>   101 |     end(initializer_list<_Tp> __ils) noexcept
>       |     ^~~
> custom_passes.cpp:644:41: error: ‘begin’ was not declared in this scope
>   644 |                 for ( BasicBlock* bb : *decref_blocks ) {
>       |                                         ^~~~~~~~~~~~~
> custom_passes.cpp:644:41: note: suggested alternatives:
> In file included from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/bits/range_access.h:108:37: note:   ‘std::begin’
>   108 |   template<typename _Tp> const _Tp* begin(const valarray<_Tp>&);
>       |                                     ^~~~~
> In file included from /usr/include/c++/10/bits/range_access.h:36,
>                  from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/initializer_list:90:5: note:   ‘std::begin’
>    90 |     begin(initializer_list<_Tp> __ils) noexcept
>       |     ^~~~~
> In file included from /usr/include/llvm/Support/YAMLTraits.h:23,
>                  from /usr/include/llvm/IR/DiagnosticInfo.h:24,
>                  from /usr/include/llvm/Analysis/OptimizationRemarkEmitter.h:19,
>                  from /usr/include/llvm/Analysis/InlineCost.h:18,
>                  from /usr/include/llvm/Transforms/IPO/Attributor.h:108,
>                  from /usr/include/llvm/LinkAllPasses.h:44,
>                  from custom_passes.cpp:19:
> /usr/include/llvm/Support/YAMLParser.h:380:35: note:   ‘llvm::yaml::begin’
>   380 | typename CollectionType::iterator begin(CollectionType &C) {
>       |                                   ^~~~~
> custom_passes.cpp:644:41: error: ‘end’ was not declared in this scope
>   644 |                 for ( BasicBlock* bb : *decref_blocks ) {
>       |                                         ^~~~~~~~~~~~~
> custom_passes.cpp:644:41: note: suggested alternatives:
> In file included from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/bits/range_access.h:110:37: note:   ‘std::end’
>   110 |   template<typename _Tp> const _Tp* end(const valarray<_Tp>&);
>       |                                     ^~~
> In file included from /usr/include/c++/10/bits/range_access.h:36,
>                  from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/initializer_list:101:5: note:   ‘std::end’
>   101 |     end(initializer_list<_Tp> __ils) noexcept
>       |     ^~~
> custom_passes.cpp:645:21: error: ‘raising_blocks’ was not declared in this scope
>   645 |                     raising_blocks.insert(bb);
>       |                     ^~~~~~~~~~~~~~
> custom_passes.cpp:647:22: error: ‘verifyFanoutBackward’ was not declared in this scope
>   647 |                 if ( verifyFanoutBackward(incref, head_node, p_raising_blocks) )
>       |                      ^~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp:650:25: error: ‘verifyFanoutBackward’ was not declared in this scope
>   650 |             } else if ( verifyFanoutBackward(incref, head_node, decref_blocks) ) {
>       |                         ^~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp: At global scope:
> custom_passes.cpp:692:37: error: ‘SmallBBSet’ has not been declared
>   692 |                                     SmallBBSet &bad_blocks,
>       |                                     ^~~~~~~~~~
> custom_passes.cpp:693:37: error: ‘SmallBBSet’ has not been declared
>   693 |                                     SmallBBSet *decref_blocks,
>       |                                     ^~~~~~~~~~
> custom_passes.cpp:694:37: error: ‘SmallBBSet’ has not been declared
>   694 |                                     SmallBBSet *raising_blocks) {
>       |                                     ^~~~~~~~~~
> custom_passes.cpp: In function ‘bool findFanoutDecrefCandidates(llvm::CallInst*, llvm::BasicBlock*, int&, int*, int*)’:
> custom_passes.cpp:696:34: error: ‘FANOUT_RECURSE_DEPTH’ was not declared in this scope
>   696 |         SmallVector<BasicBlock*, FANOUT_RECURSE_DEPTH> path_stack;
>       |                                  ^~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp:696:54: error: template argument 2 is invalid
>   696 |         SmallVector<BasicBlock*, FANOUT_RECURSE_DEPTH> path_stack;
>       |                                                      ^
> custom_passes.cpp:703:85: error: no matching function for call to ‘raiiStack<llvm::SmallVectorImpl<llvm::BasicBlock*> >::raiiStack(int&, llvm::BasicBlock*&)’
>   703 |         raiiStack<SmallVectorImpl<BasicBlock*>> raii_path_stack(path_stack, cur_node);
>       |                                                                                     ^
> custom_passes.cpp:97:5: note: candidate: ‘raiiStack<Tstack>::raiiStack(Tstack&, raiiStack<Tstack>::value_type&) [with Tstack = llvm::SmallVectorImpl<llvm::BasicBlock*>; raiiStack<Tstack>::value_type = llvm::BasicBlock*]’
>    97 |     raiiStack(Tstack &stack, value_type& elem) :stack(stack) {
>       |     ^~~~~~~~~
> custom_passes.cpp:97:23: note:   no known conversion for argument 1 from ‘int’ to ‘llvm::SmallVectorImpl<llvm::BasicBlock*>&’
>    97 |     raiiStack(Tstack &stack, value_type& elem) :stack(stack) {
>       |               ~~~~~~~~^~~~~
> custom_passes.cpp:89:8: note: candidate: ‘constexpr raiiStack<llvm::SmallVectorImpl<llvm::BasicBlock*> >::raiiStack(const raiiStack<llvm::SmallVectorImpl<llvm::BasicBlock*> >&)’
>    89 | struct raiiStack {
>       |        ^~~~~~~~~
> custom_passes.cpp:89:8: note:   candidate expects 1 argument, 2 provided
> custom_passes.cpp:713:21: error: ‘walkChildForDecref’ was not declared in this scope
>   713 |             found = walkChildForDecref(
>       |                     ^~~~~~~~~~~~~~~~~~
> custom_passes.cpp: At global scope:
> custom_passes.cpp:746:9: error: ‘SmallBBSet’ has not been declared
>   746 |         SmallBBSet &bad_blocks,
>       |         ^~~~~~~~~~
> custom_passes.cpp:747:9: error: ‘SmallBBSet’ has not been declared
>   747 |         SmallBBSet *decref_blocks,
>       |         ^~~~~~~~~~
> custom_passes.cpp:748:9: error: ‘SmallBBSet’ has not been declared
>   748 |         SmallBBSet *raising_blocks
>       |         ^~~~~~~~~~
> custom_passes.cpp: In function ‘bool walkChildForDecref(llvm::CallInst*, llvm::BasicBlock*, llvm::SmallVectorImpl<llvm::BasicBlock*>&, unsigned int&, int&, int*, int*)’:
> custom_passes.cpp:752:35: error: ‘FANOUT_RECURSE_DEPTH’ was not declared in this scope
>   752 |         if ( path_stack.size() >= FANOUT_RECURSE_DEPTH ) return false;
>       |                                   ^~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp:755:31: error: ‘subgraph_limit’ was not declared in this scope; did you mean ‘subgraph_size’?
>   755 |         if (++subgraph_size > subgraph_limit) {
>       |                               ^~~~~~~~~~~~~~
>       |                               subgraph_size
> custom_passes.cpp:758:24: error: request for member ‘insert’ in ‘bad_blocks’, which is of non-class type ‘int’
>   758 |             bad_blocks.insert(incref->getParent());
>       |                        ^~~~~~
> custom_passes.cpp:764:14: error: ‘basicBlockInList’ was not declared in this scope
>   764 |         if ( basicBlockInList(cur_node, path_stack) ) {
>       |              ^~~~~~~~~~~~~~~~
> custom_passes.cpp:772:28: error: request for member ‘insert’ in ‘bad_blocks’, which is of non-class type ‘int’
>   772 |                 bad_blocks.insert(incref->getParent());
>       |                            ^~~~~~
> custom_passes.cpp:780:14: error: ‘hasDecrefInNode’ was not declared in this scope
>   780 |         if ( hasDecrefInNode(incref, cur_node) ) {
>       |              ^~~~~~~~~~~~~~~
> custom_passes.cpp:782:28: error: request for member ‘insert’ in ‘* decref_blocks’, which is of non-class type ‘int’
>   782 |             decref_blocks->insert(cur_node);
>       |                            ^~~~~~
> custom_passes.cpp:787:14: error: ‘hasAnyDecrefInNode’ was not declared in this scope
>   787 |         if ( hasAnyDecrefInNode(cur_node) ) {
>       |              ^~~~~~~~~~~~~~~~~~
> custom_passes.cpp:791:24: error: request for member ‘insert’ in ‘bad_blocks’, which is of non-class type ‘int’
>   791 |             bad_blocks.insert(incref->getParent());
>       |                        ^~~~~~
> custom_passes.cpp:798:31: error: ‘isRaising’ was not declared in this scope
>   798 |         if (raising_blocks && isRaising(cur_node)) {
>       |                               ^~~~~~~~~
> custom_passes.cpp:799:29: error: request for member ‘insert’ in ‘* raising_blocks’, which is of non-class type ‘int’
>   799 |             raising_blocks->insert(cur_node);
>       |                             ^~~~~~
> custom_passes.cpp: At global scope:
> custom_passes.cpp:845:15: error: ‘SmallBBSet’ does not name a type
>   845 |         const SmallBBSet *tail_nodes
>       |               ^~~~~~~~~~
> custom_passes.cpp: In function ‘bool verifyFanoutBackward(llvm::CallInst*, llvm::BasicBlock*, const int*)’:
> custom_passes.cpp:849:31: error: ‘begin’ was not declared in this scope
>   849 |         for (BasicBlock *bb: *tail_nodes) {
>       |                               ^~~~~~~~~~
> custom_passes.cpp:849:31: note: suggested alternatives:
> In file included from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/bits/range_access.h:108:37: note:   ‘std::begin’
>   108 |   template<typename _Tp> const _Tp* begin(const valarray<_Tp>&);
>       |                                     ^~~~~
> In file included from /usr/include/c++/10/bits/range_access.h:36,
>                  from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/initializer_list:90:5: note:   ‘std::begin’
>    90 |     begin(initializer_list<_Tp> __ils) noexcept
>       |     ^~~~~
> In file included from /usr/include/llvm/Support/YAMLTraits.h:23,
>                  from /usr/include/llvm/IR/DiagnosticInfo.h:24,
>                  from /usr/include/llvm/Analysis/OptimizationRemarkEmitter.h:19,
>                  from /usr/include/llvm/Analysis/InlineCost.h:18,
>                  from /usr/include/llvm/Transforms/IPO/Attributor.h:108,
>                  from /usr/include/llvm/LinkAllPasses.h:44,
>                  from custom_passes.cpp:19:
> /usr/include/llvm/Support/YAMLParser.h:380:35: note:   ‘llvm::yaml::begin’
>   380 | typename CollectionType::iterator begin(CollectionType &C) {
>       |                                   ^~~~~
> custom_passes.cpp:849:31: error: ‘end’ was not declared in this scope
>   849 |         for (BasicBlock *bb: *tail_nodes) {
>       |                               ^~~~~~~~~~
> custom_passes.cpp:849:31: note: suggested alternatives:
> In file included from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/bits/range_access.h:110:37: note:   ‘std::end’
>   110 |   template<typename _Tp> const _Tp* end(const valarray<_Tp>&);
>       |                                     ^~~
> In file included from /usr/include/c++/10/bits/range_access.h:36,
>                  from /usr/include/c++/10/string:54,
>                  from /usr/include/llvm/Pass.h:31,
>                  from custom_passes.cpp:5:
> /usr/include/c++/10/initializer_list:101:5: note:   ‘std::end’
>   101 |     end(initializer_list<_Tp> __ils) noexcept
>       |     ^~~
> custom_passes.cpp:855:9: error: ‘SmallBBSet’ was not declared in this scope
>   855 |         SmallBBSet visited;
>       |         ^~~~~~~~~~
> custom_passes.cpp:858:38: error: ‘FANOUT_RECURSE_DEPTH’ was not declared in this scope
>   858 |             SmallVector<BasicBlock*, FANOUT_RECURSE_DEPTH> workstack;
>       |                                      ^~~~~~~~~~~~~~~~~~~~
> custom_passes.cpp:858:58: error: template argument 2 is invalid
>   858 |             SmallVector<BasicBlock*, FANOUT_RECURSE_DEPTH> workstack;
>       |                                                          ^
> custom_passes.cpp:860:23: error: request for member ‘push_back’ in ‘workstack’, which is of non-class type ‘int’
>   860 |             workstack.push_back(todo.pop_back_val());
>       |                       ^~~~~~~~~
> custom_passes.cpp:863:30: error: request for member ‘size’ in ‘workstack’, which is of non-class type ‘int’
>   863 |             while (workstack.size() > 0) {
>       |                              ^~~~
> custom_passes.cpp:865:50: error: request for member ‘pop_back_val’ in ‘workstack’, which is of non-class type ‘int’
>   865 |                 BasicBlock *cur_node = workstack.pop_back_val();
>       |                                                  ^~~~~~~~~~~~
> custom_passes.cpp:867:22: error: ‘visited’ was not declared in this scope
>   867 |                 if ( visited.count(cur_node) ) {
>       |                      ^~~~~~~
> custom_passes.cpp:881:17: error: ‘visited’ was not declared in this scope
>   881 |                 visited.insert(cur_node);
>       |                 ^~~~~~~
> custom_passes.cpp:889:38: error: request for member ‘count’ in ‘* tail_nodes’, which is of non-class type ‘const int’
>   889 |                     if ( tail_nodes->count(pred) ) {
>       |                                      ^~~~~
> custom_passes.cpp:897:35: error: request for member ‘push_back’ in ‘workstack’, which is of non-class type ‘int’
>   897 |                         workstack.push_back(pred);
>       |                                   ^~~~~~~~~
> custom_passes.cpp: In function ‘bool hasDecrefInNode(llvm::CallInst*, llvm::BasicBlock*)’:
> custom_passes.cpp:980:17: error: ‘isRelatedDecref’ was not declared in this scope
>   980 |             if (isRelatedDecref(incref, &ii) != NULL) {
>       |                 ^~~~~~~~~~~~~~~
> custom_passes.cpp: At global scope:
> custom_passes.cpp:1015:54: error: virt-specifiers in ‘getAnalysisUsage’ not allowed outside a class definition
>  1015 |     void getAnalysisUsage(AnalysisUsage &Info) const override {
>       |                                                      ^~~~~~~~
> custom_passes.cpp:1015:54: error: non-member function ‘void getAnalysisUsage(llvm::AnalysisUsage&)’ cannot have cv-qualifier
> custom_passes.cpp: In function ‘bool hasDecrefBetweenGraph(llvm::BasicBlock*, llvm::BasicBlock*)’:
> custom_passes.cpp:1073:9: error: ‘SmallBBSet’ was not declared in this scope
>  1073 |         SmallBBSet visited;
>       |         ^~~~~~~~~~
> custom_passes.cpp:1082:17: error: ‘visited’ was not declared in this scope
>  1082 |             if (visited.count(cur_node)) {
>       |                 ^~~~~~~
> custom_passes.cpp:1086:13: error: ‘visited’ was not declared in this scope
>  1086 |             visited.insert(cur_node);
>       |             ^~~~~~~
> custom_passes.cpp: At global scope:
> custom_passes.cpp:1146:1: error: expected declaration before ‘}’ token
>  1146 | }; // end of struct RefPrunePass
>       | ^
> make: *** [Makefile.linux:22: libllvmlite.so] Error 1
> Traceback (most recent call last):
>   File "/home/oceanfish81/llvmlite/ffi/build.py", line 191, in <module>
>     main()
>   File "/home/oceanfish81/llvmlite/ffi/build.py", line 181, in main
>     main_posix('linux', '.so')
>   File "/home/oceanfish81/llvmlite/ffi/build.py", line 173, in main_posix
>     subprocess.check_call(['make', '-f', makefile])
>   File "/usr/lib64/python3.8/subprocess.py", line 364, in check_call
>     raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['make', '-f', 'Makefile.linux']' returned non-zero exit status 2.
> error: command '/usr/bin/python3' failed with exit status 1
> 

Hence that I am using

> $ clang --version
> clang version 11.0.0
> Target: riscv64-unknown-linux-gnu
> Thread model: posix

under https://en.opensuse.org/openSUSE:RISC-V
.







user: advancedwebdeveloper
labels: llvm: LLVM related issues
ISA: RISC-V: Issue related to RISC-V ISA
issue_6556: state: open
title: Error in compiled function using CFFI to call BLAS
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

I have a Numba-compiled function that wraps the BLAS `dposv` function. This function was working correctly up through Numba 0.51. With Numba 0.52, it fails with a DPOSV error. The following code demonstrates the problem.

- Under Numba 0.51, it runs correctly
- Under Numba 0.52 (on Windows, installed from conda-forge), the assertion fails (indicating a DPOSV argument error) and the BLAS implementation (tested with both MKL and OpenBLAS) complains about an invalid argument

As near as I can tell, Numba 0.52 changed something about how this function compiles so it no longer functions. This function is a part of [LensKit](https://github.com/lenskit/lkpy), and it can be run with LensKit's tests as well:

    python -m pytest -k dposv

```python
import numpy as np
import numba as n
import cffi
from numba.extending import get_cython_function_address

__ffi = cffi.FFI()

__uplo_U = np.array([ord('U')], dtype=np.int8)
__uplo_L = np.array([ord('L')], dtype=np.int8)
__dposv = __ffi.cast("void (*) (char*, int*, int*, double*, int*, double*, int*, int*)",
                     get_cython_function_address("scipy.linalg.cython_lapack", "dposv"))


@n.njit(n.intc(n.float64[:, ::1], n.float64[::1], n.boolean))
def _dposv(A, b, lower):
    if A.shape[0] != A.shape[1]:
        return -11
    if A.shape[0] != b.shape[0]:
        return -12

    # dposv uses Fortran-layout arrays. Because we use C-layout arrays, we will
    # invert the meaning of 'lower' and 'trans', and the function will work fine.
    # We also need to swap index orders
    uplo = __uplo_U if lower else __uplo_L
    n_p = __ffi.from_buffer(np.array([A.shape[0]], dtype=np.intc))
    nrhs_p = __ffi.from_buffer(np.ones(1, dtype=np.intc))
    info = np.zeros(1, dtype=np.intc)
    info_p = __ffi.from_buffer(info)

    __dposv(__ffi.from_buffer(uplo), n_p, nrhs_p,
            __ffi.from_buffer(A), n_p,
            __ffi.from_buffer(b), n_p,
            info_p)

    return info[0]

A = np.array([[106014.2749504 ,  53086.26042087],
       [ 53086.26042087, 252421.30232019]])
b = np.array([ 4875.45574154, -4608.45667769])
rv = _dposv(A, b, True)
assert rv >= 0
```

user: mdekstrand
labels: bug - miscompile: Bugs: miscompile
issue_6555: state: open
title: Cannot create datetime inside njit
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

By reading in https://numba.readthedocs.io/en/stable/reference/numpysupported.html#scalar-types that Numba supports NumPy datetimes and timestamps of any unit, I tried creating one inside a `@njit`ted function, but it failed:

```
$ cat dt_test.py 
import numpy as np
from numba import njit


@njit
def f(dt64):
    return dt64

print(f(np.datetime64(100, "D")))  # Works


@njit
def d():
    return np.datetime64(100, "D")

print(d())  # Fails
$ python dt_test.py 
1970-04-11
Traceback (most recent call last):
  File "dt_test.py", line 16, in <module>
    print(d())  # Fails
  File "/home/juanlu/.pyenv/versions/sgp38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 414, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/juanlu/.pyenv/versions/sgp38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 357, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(datetime64[]) found for signature:
 
 >>> <unknown function>(Literal[int](100), Literal[str](D))
 
There are 2 candidate implementations:
 - Of which 2 did not match due to:
 Overload in function 'make_callable_template.<locals>.generic': File: numba/core/typing/templates.py: Line 170.
   With argument(s): '(int64, unicode_type)':
  Rejected as the implementation raised a specific error:
    TypeError: typer() takes 1 positional argument but 2 were given
  raised from /home/juanlu/.pyenv/versions/sgp38/lib/python3.8/site-packages/numba/core/typing/templates.py:399

During: resolving callee type: class(datetime64[])
During: typing of call at dt_test.py (14)


File "dt_test.py", line 14:
def d():
    return np.datetime64(100, "D")
    ^
```

Tested on Python 3.8, Linux, latest numba installed from pip using manylinux wheels.
user: astrojuanlu
issue_6550: state: open
title: Array comprehension fails against multidimensional array with nopython and typed List
body: ## Reporting a bug

I'm reporting a regression bug for https://github.com/numba/numba/issues/3659 when `@njit` and typed lists are used.

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

```python
import numba
import numpy as np
from numba.typed import List


@numba.njit
def main(a):
    return np.array([x[0] for x in a])


a = [np.array([1,2]), np.array([3, 4, 5])]
a = List(a)
print(main(a))
```

```
Traceback (most recent call last):
  File "/home/ulianych/PycharmProjects/elephant/elephant/temp2.py", line 13, in <module>
    print(main(a))
  File "/home/ulianych/anaconda3/envs/elephant/lib/python3.8/site-packages/numba/core/dispatcher.py", line 414, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/ulianych/anaconda3/envs/elephant/lib/python3.8/site-packages/numba/core/dispatcher.py", line 357, in error_rewrite
    raise e.with_traceback(None)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<intrinsic range_iter_len>) found for signature:
 
 >>> <unknown function>(iter[ListType[array(int64, 1d, C)]->array(int64, 1d, C)])
 
There are 2 candidate implementations:
   - Of which 2 did not match due to:
   Intrinsic of function '<unknown function>': File: numba/cpython/rangeobj.py: Line 183.
     With argument(s): '(iter[ListType[array(int64, 1d, C)]->array(int64, 1d, C)])':
    No match.

During: resolving callee type: Function(<intrinsic range_iter_len>)
During: typing of call at /home/ulianych/PycharmProjects/elephant/elephant/temp2.py (8)


File "temp2.py", line 8:
def main(a):
    return np.array([x[0] for x in a])
    ^
```

Works fine for ragged lists (not typed).

Numba v0.52.0
Python 3.8.5
user: dizcza
issue_6549: state: open
title: CUDA: Allow dynamic allocation of local arrays
body: Dynamic allocation is supported on CC 2.0 and above devices, so it would be nice if `cuda.local.array` shape could be variable instead of constant, e.g.:

```python
@cuda.jit
def kernel(nx, ny):
    arr = cuda.local.array((nx, ny), dtype=dt)
```
user: gmarkall
labels: CUDA: CUDA related issue/PR
good second issue: A good issue for second time contributors
issue_6548: state: open
title: Support literal_unroll without type unification on loop body variables
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Hi, 

I came across one use-case where literal_unroll currently fails, due to type-inference trying to unify types of the same variable from different iterations. This makes it not possible to support heterogeneous tuple-transformation functions, when you need to build a new tuple from existing one (e.g. by dropping or applying some function to it's elements ).

So this script:
```
import numpy as np
import numba
from numba.misc.special import literal_unroll

@numba.njit
def test_func_1():
    data = ('a', [2, 3], np.nan, 600)
    res = ()

    res = res + (data[0], )
    res = res + (data[1], )
    res = res + (data[2], )
    res = res + (data[3], )

    return res

@numba.njit
def test_func_2():
    data = ('a', [2, 3], np.nan, 600)
    res = ()

    for a in literal_unroll(data):
        res = res + (a, )

    return res

# res = test_func_1()
res = test_func_2()
print(f"DEBUG: res={res}")
```

fails with:
> numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
> Cannot unify Tuple() and UniTuple(unicode_type x 1) for 'res.5', defined at test_literal_unroll.py (25)
> 
> File "test_literal_unroll.py", line 25:
> def test_func_2():
>     <source elided>
> 
>     return res
>     ^
 
At the same type manually unrolling works fine, so `test_func_1` compiles and runs.
I think this is worth supporting, since using `tuple_setitem` mentioned in #5332 is not always enough and making unroll behave more like manually unrolled loop is worth trying. 

Also it seems below fails due to the same reason:

```
@numba.njit
def test_func_3():
    data = ('a', 'b', 1)

    for a in literal_unroll(data):
        new_a = (a, )
    return new_a
```

Best Regards,
Alexey.
user: kozlov-alexey
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6547: state: open
title: Performance regression on 0.52.0 wrt accumulation
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Commit f4000439daac2aaefc20994c80e8fe9d903ce31a slows down my workload from ~60s to ~200s. I've slimmed down a repo to:

```python
from numba import njit
from numpy import random, uint64, empty_like
from timeit import timeit

@njit
def fn(x, out):
    for i in range(len(x)):
        for j in range(1, 63):
            out[i] = x[i] << j  # no accumulation here but the shift exhibits the perf problem

rng = random.default_rng(0)
x = rng.integers(~uint64(0), size=500, dtype=uint64)
out = empty_like(x)
print(timeit(lambda: fn(x, out)))
```

on my server, f4000439daac2aaefc20994c80e8fe9d903ce31a gives ~11s and 9381206a03a3e7231d417f147474577745f6a720 gives ~3s.

user: s22chan
labels: performance - run time: Performance issue occurring at run time.
issue_6543: state: open
title: Operation "element in set" never returns
body: Bug: After a series of add and remove operations on a set in nopython mode the operation "in set" does not return and gets stuck at 100% CPU load.

Isolated code example:
```python
import numba as nb

@ nb.njit()
def problem():

    # init
    openSet = set()

    openSet.add((0, 0))
    openSet.add((1, 0))
    openSet.add((2, 0))
    openSet.add((3, 0))
    openSet.add((4, 0))
    openSet.add((5, 0))
    openSet.add((6, 0))
    openSet.add((7, 0))
    openSet.add((8, 0))

    openSet.remove((2, 0))
    openSet.add((2, 1))
    openSet.remove((2, 1))
    openSet.remove((4, 0))
    openSet.add((5, 1))
    openSet.add((4, 1))
    openSet.remove((7, 0))
    openSet.add((8, 1))
    openSet.add((7, 1))
    openSet.add((6, 1))
    openSet.remove((8, 0))
    openSet.remove((1, 0))
    openSet.remove((0, 0))
    openSet.remove((5, 0))
    openSet.remove((6, 0))
    openSet.remove((3, 0))
    openSet.remove((7, 1))
    openSet.add((8, 2))
    openSet.add((7, 2))
    openSet.add((6, 2))
    openSet.remove((8, 1))
    openSet.remove((6, 1))
    openSet.add((5, 2))
    openSet.remove((4, 1))
    openSet.add((4, 2))
    openSet.remove((5, 1))
    openSet.remove((6, 2))
    openSet.add((7, 3))
    openSet.add((6, 3))
    openSet.add((5, 3))
    openSet.remove((7, 2))
    openSet.add((8, 3))
    openSet.remove((8, 2))
    openSet.remove((4, 2))
    openSet.add((4, 3))
    openSet.add((3, 3))
    openSet.remove((5, 2))
    openSet.remove((7, 3))
    openSet.add((8, 4))
    openSet.add((7, 4))
    print('About to check (6,4) in openSet')
    return (6, 4) in openSet


if __name__ == "__main__":
    print(problem())
    print('DONE')
```

The code gets stuck with numba 0.52.0 with Python 3.8.5 on Ubuntu 20.04.1 LTS x86_64.

However, @esc on gitter.im also confirmed that the issue persists on OSX.

Isolated code example:
https://github.com/icezyclon/astart-pathfinding/blob/main/isolated.py
Original code example (from A* search):
https://github.com/icezyclon/astart-pathfinding/blob/main/problem.py
user: icezyclon
labels: bug - miscompile: Bugs: miscompile
issue_6541: state: open
title: Dead branch (optional argument test) not being pruned before type inference
body: - [0.51.2] I have tried using the latest released version of Numba: I actually used 0.51.2, which is the most recent in Anaconda, rather than the bleeding edge 0.52.0.
- [x] I have included a self contained code sample to reproduce the problem.

With the following code, I expect both of the `f` calls to succeed:

```
@nb.njit()
def f(xs, out=None):
    N, = xs.shape
    if out is None:
        out = np.arange(N)
    else:
        assert np.all((0 <= out) & (out < N))
    out[:] = N
    return out


f(np.array([3, 1, 2]))
f(np.array([3, 1, 2]), out=np.arange(3, dtype='i8'))
```

But in fact the first call fails with a `TypingError` because numba can't compare `None` to an `int` when compliing the `is not None` branch of the else (full stack trace below). The second call is OK.

Judging by https://github.com/numba/numba/issues/3585#issuecomment-446302215, I think the expected behaviour is that when `out` is None, the `else` branch will be pruned before type checking so this type error shouldn't happen. I suppose that in this example something must be blocking the pruning from taking place.

For what it's worth, I think this code did work in some earlier version of numba. (I haven't run the affected file for maybe 1-2 years so I'm not quite sure which numba version it was working with.)

```
TypingError                               Traceback (most recent call last)
<ipython-input-4-1e4e60a654dd> in <module>
----> 1 f(np.array([3, 1, 2]))

~\Anaconda3\envs\py3_1\lib\site-packages\numba\core\dispatcher.py in _compile_for_args(self, *args, **kws)
    413                 e.patch_message(msg)
    414
--> 415             error_rewrite(e, 'typing')
    416         except errors.UnsupportedError as e:
    417             # Something unsupported is present in the user code, add help info

~\Anaconda3\envs\py3_1\lib\site-packages\numba\core\dispatcher.py in error_rewrite(e, issue_type)
    356                 raise e
    357             else:
--> 358                 reraise(type(e), e, None)
    359
    360         argtypes = []

~\Anaconda3\envs\py3_1\lib\site-packages\numba\core\utils.py in reraise(tp, value, tb)
     78         value = tp()
     79     if value.__traceback__ is not tb:
---> 80         raise value.with_traceback(tb)
     81     raise value
     82

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function le>) found for signature:

 >>> le(Literal[int](0), none)

There are 20 candidate implementations:
  - Of which 18 did not match due to:
  Overload of function 'le': File: <numerous>: Line N/A.
    With argument(s): '(int64, none)':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'le': File: unknown: Line unknown.
    With argument(s): '(int64, none)':
   No match for registered cases:
    * (bool, bool) -> bool
    * (int8, int8) -> bool
    * (int16, int16) -> bool
    * (int32, int32) -> bool
    * (int64, int64) -> bool
    * (uint8, uint8) -> bool
    * (uint16, uint16) -> bool
    * (uint32, uint32) -> bool
    * (uint64, uint64) -> bool
    * (float32, float32) -> bool
    * (float64, float64) -> bool

During: typing of intrinsic-call at <ipython-input-3-162a2050856a> (7)

File "<ipython-input-3-162a2050856a>", line 7:
def f(xs, out=None):
    <source elided>
    else:
        assert np.all((0 <= out) & (out < N))
        ^
```
user: batterseapower
labels: SSA: Problem due to SSA (or lack of)
bug - failure to compile: Bugs: failed to compile valid code
issue_6537: state: open
title: Launch CUDA kernels from cfuncs
body: ---

## Feature request

I would like a  nopython `@cfunc` to be able to launch a `@cuda.jit` kernel.

```python3
import numba.types as nt

@numba.cuda.jit(nt.void(nt.CPointer(nt.float32), nt.CPointer(nt.float32))
def kernel_gpu(input, output):
  i = numba.cuda.grid(1)
  output[i] = input[i] + 1

@numba.cfunc(nt.void(nt.voidptr, nt.CPointer(nt.voidptr), nt.CPointer(nt.char), nt.ulong))
def kernel_launcher(stream, buffers, opaque, opaque_len):
  blockspergrid, threadsperblock = some_calculation(opaque, opaque_len)
  kernel_gpu[blockspergrid, threadsperblock, stream](buffers[0], buffers[1])
```

I've been doing some experiments in [JAX issue 1870](https://github.com/google/jax/issues/1870) which is about allowing Numba CUDA kernels to be consumed by JAX's XLA JIT. Most of the pieces are there to put this together, but launching CUDA kernels is proving problematic.

We can already integrate Numba CPU kernels; it's simply a matter of creating a `@cfunc` with the right signature and patching it into the JAX API.

The most basic thing we would need to be able to do to launch a Numba CUDA kernel is get its handle. I found `kernel_gpu[1,10]._func.get().handle` which I thought might be a sufficient hacky way of doing that, but it turns out that that broke sometime between Numba 0.48 and 0.52. It's clear that that isn't a public API, so JAX shouldn't consume it or whatever the 0.52 equivalent is.

I believe that that means that this JAX feature cannot happen without a Numba change to expose an appropriate API.

If a `@cfunc` were able to launch a CUDA kernel then all of this handle wrangling could be avoided. Both the CPU and GPU kernels could be written as simple `@cfunc`s; the GPU ones would simply launch a CUDA kernel. This would allow JAX to neatly integrate with Numba without having to write CUDA code to handle launching.

@seibert [mentioned on the mailing list](https://groups.google.com/a/continuum.io/g/numba-users/c/SPe8qlRAfM8/m/xBPFFrDwAQAJ) that this is a feature Numba would like to implement, and mentioned that it may also have the advantage of reducing repeated kernel launch overhead. 
user: SamPruden
labels: CUDA: CUDA related issue/PR
issue_6536: state: open
title: Inspect_cfg doc needs updating
body: The inspect_cfg doc needs to be updated https://github.com/numba/numba/blame/484925571c7caaadd2170434ea889afed788a6f3/docs/source/reference/jit-compilation.rst#L195

_Originally posted by @sklam in https://github.com/numba/numba-examples/pull/27#discussion_r533794334_
user: sklam
issue_6535: state: open
title: Unable to assign 0 as NULL to void** local
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

Pointers can be set to `NULL` by assigning 0. This appears not to work with pointers to pointers.

```python3
import numba

# Succeeds
@numba.cfunc("void()", locals = {"bar": numba.types.voidptr})
def foo():
  bar = 0

# Fails
@numba.cfunc("void()", locals = {"bar": numba.types.CPointer(numba.types.voidptr)})
def foo():
  bar = 0
```
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No conversion from Literal[int](0) to void** for 'bar', defined at None
```

I would assume that if this works with pointers generally, it shouldn't fail for the specific case of a pointer to a pointer.

This is actually blocking progress on something for me at the moment, so any comments on workarounds would be appreciated! I need to pass a `NULL` `void**` into a ctypes function from inside a cfunc.

This seems to work fine, but I can't alter the signature of my cfunc to accommodate so it's not a solution for me.
```python3
@numba.cfunc(numba.types.void(numba.types.CPointer(numba.types.voidptr)))
def foo(a):
  return

foo(0)
```

The pointer types don't appear to have casting support.
user: SamPruden
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6532: state: open
title: CUDA functions do not support tuple expansion
body: In Datashader we recently ran into an issue with a function that uses tuple expansion, which would compile for CPU targets but not on CUDA. This seemed to be because it didn't expand out the tuple and would then perform the wrong operation. Specifically this was [this function](https://github.com/holoviz/datashader/pull/973/commits/000b4d2fba53fbcb4c153e32de04a7150551bcd6#diff-ae5ee553653ed93841afb6b56ee2c5204a9800038c184518d85c0f6d66d69946R716):

```python
def _bresenham(i, sx, tx, sy, ty, xmin, xmax, ymin, ymax, segment_start,
                  x0, x1, y0, y1, clipped, append, *aggs_and_cols
                 ):
    ...
    append(i, x0, y0, *aggs_and_cols)
```

This would fail during compilation with this error:

```
 >>> add(Tuple(int32, int64, int64), array(uint32, 2d, C))
There are 12 candidate implementations:
      - Of which 2 did not match due to:
      Operator Overload in function 'add': File: unknown: Line unknown.
        With argument(s): '(Tuple(int32, int64, int64), array(uint32, 2d, C))':
       No match for registered cases:
        * (int64, int64) -> int64
        * (int64, uint64) -> int64
        * (uint64, int64) -> int64
        * (uint64, uint64) -> uint64
        * (float32, float32) -> float32
        * (float64, float64) -> float64
        * (complex64, complex64) -> complex64
        * (complex128, complex128) -> complex128
      - Of which 10 did not match due to:
      Overload of function 'add': File: <numerous>: Line N/A.
        With argument(s): '(Tuple(int32, int64, int64), array(uint32, 2d, C))':
       No match.
During: typing of intrinsic-call at /home/philippjfr/development/datashader/datashader/glyphs/line.py (736)
```

Presumably because the `aggs_and_cols` tuple was not being unpacked causing `append` to try to add the whole tuple to 2D array, which would fail the type check. If CUDA could support tuple unpacking that would be great although not hugely important for datashader since we have a macro that automatically expands out functions using tuple unpacking by manipulating the AST and recompiling a fully expanded function (which we implemented for optimization reasons).
user: philippjfr
labels: CUDA: CUDA related issue/PR
issue_6522: state: open
title: Caching a function that takes in a jitclass instance
body: ```python
@jitclass([])
class NumbaClass():
    def __init__(self):
        pass

@njit(cache=True)
def calc(numbaObj):
    pass

numbaObject = NumbaClass()
calc(numbaObject)
```

Each time the script above is ran, it generates a new cache entry for "calc", likely because NumbaClass.class_type.instance_type changes on every run, making the cache flag effectively not work and growing the \_\_pycache__ folder on every run (mine eneded up being a few gigs). Is there a work-around for this? Numba 0.51.2


user: strukalex
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_6513: state: open
title: Can't compile recursive function ahead of time
body: When trying to compile a simple recursive function

```python
@cc.export('flood_fill', 'b1(u1[:,:], i8, i8, f8[:])')
def flood_fill(mat, i, j, coord):
    if mat[i, j] == 0:
        return
    
    directions = np.asarray([(-1, -1), (0, -1), (1, -1), (-1, 0), (1, 0), (-1, 1), (0, 1), (1, 1)])
    
    mat[i, j] = 0
    coord[0] = min(coord[0], j)
    coord[1] = min(coord[1], i)
    coord[2] = max(coord[2], j)
    coord[3] = max(coord[3], i)
    
    for dx, dy in directions:
        flood_fill(mat, i+dy, j+dx, coord)
        
    return True
```

i get

```bash
Untyped global name 'flood_fill': cannot determine Numba type of <class 'function'>
```

with the arrow pointing at the recursive call, added a dummy boolean return to ensure explicit typing of the function but still the error persists.
user: nubol23
labels: AOT: ahead of time compilation issue
issue_6512: state: open
title: Error using np.int32(np.random.random(n_spins))
body: Traceback (most recent call last):
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\targets\base.py", line 691, in cast
    impl = self._casts.find((fromty, toty))
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\targets\base.py", line 50, in find
    out = self._find(sig)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\targets\base.py", line 59, in _find
    raise NotImplementedError(self, sig)
NotImplementedError: (<numba.targets.base.OverloadSelector object at 0x0000026B60B3FD48>, (array(float64, 1d, C), int32))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\errors.py", line 662, in new_error_context
    yield
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 258, in lower_block
    self.lower_inst(inst)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 301, in lower_inst
    val = self.lower_assign(ty, inst)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 459, in lower_assign
    return self.lower_expr(ty, value)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 919, in lower_expr
    res = self.lower_call(resty, expr)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 711, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 890, in _lower_call_normal
    res = impl(self.builder, argvals, self.loc)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\targets\base.py", line 1132, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\targets\base.py", line 1157, in wrapper
    return fn(*args, **kwargs)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\targets\builtins.py", line 278, in number_constructor
    return context.cast(builder, val, valty, sig.return_type)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\targets\base.py", line 695, in cast
    "Cannot cast %s to %s: %s" % (fromty, toty, val))
NotImplementedError: Cannot cast array(float64, 1d, C) to int32: %".760" = load {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}, {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}* %"$88.8"

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "aprogram.py", line 158, in <module>
    twoXtwo(L, temp, max_cycles)
  File "aprogram.py", line 139, in twoXtwo
    numerical_solution(spin_matrix, n_cycles, temp, L)
  File "aprogram.py", line 108, in numerical_solution
    quantities       = MC(spin_matrix, n_cycles, temp)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\dispatcher.py", line 395, in _compile_for_args
    raise e
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\dispatcher.py", line 352, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\dispatcher.py", line 693, in compile
    cres = self._compiler.compile(args, return_type)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\dispatcher.py", line 76, in compile
    status, retval = self._compile_cached(args, return_type)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\dispatcher.py", line 90, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\dispatcher.py", line 108, in _compile_core
    pipeline_class=self.pipeline_class)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 972, in compile_extra
    return pipeline.compile_extra(func)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 390, in compile_extra
    return self._compile_bytecode()
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 903, in _compile_bytecode
    return self._compile_core()
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 890, in _compile_core
    res = pm.run(self.status)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 266, in run
    raise patched_exception
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 257, in run
    stage()
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 764, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 703, in _backend
    lowered = lowerfn()
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 690, in backend_nopython_mode
    self.metadata)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\compiler.py", line 1143, in native_lowering_stage
    lower.lower()
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 177, in lower
    self.lower_normal_function(self.fndesc)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 218, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 243, in lower_function_body
    self.lower_block(block)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\lowering.py", line 258, in lower_block
    self.lower_inst(inst)
  File "C:\Users\Anna-\Anaconda3\lib\contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\errors.py", line 670, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "C:\Users\Anna-\Anaconda3\lib\site-packages\numba\six.py", line 659, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
←[1m←[1mCannot cast array(float64, 1d, C) to int32: %".760" = load {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}, {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}* %"$88.8"
←[1m
File "aprogram.py", line 70:←[0m
←[1mdef MC(spin_matrix, n_cycles, temp):
    <source elided>

←[1m            ix = np.int32(np.random.random(n_spins))
←[0m            ←[1m^←[0m←[0m
←[0m
←[0m←[1m[1] During: lowering "$88.9 = call $88.3($88.8, func=$88.3, args=[Var($88.8, aprogram.py (70))], kws=(), vararg=None)" at aprogram.py (70)←[0m
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.45.1.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
user: kwsgd
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6504: state: open
title: Long time to jit an expression
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).


I would like to jit the expression below but it takes a long time to do it (I stopped the execution after 30 min without success). The expression is a multiplication of cos, sin, sinh, cosh and sqrt. It returns a float but contains a lot of terms. 

Does it exist a "maximal" number of terms for an expression? 

Regards,

Robin. 

```
import numpy as np
from numpy import cos, sqrt, sin, sinh, cosh
from numba import njit
@njit()
def equation1() -> np.float:

    bx0: float = 1.0
    ax0: float = 0.0
    by0: float = 1.0
    ay0: float = 0.0
    Ld0: float = 1.0
    Ld1: float = 0.2
    Ld2: float = 2.5
    Ld3: float = 0.2
    Ld4: float = 0.2
    Ld5: float = 0.2
    Ld6: float = 0.75
    Lq0: float = 0.3
    Lq1: float = 0.6
    Lq2: float = 0.4
    Lq3: float = 0.3
    Lq4: float = 0.7
    Lq5: float = 0.5
    K0: float = 1.6140820926749506
    K1: float = 4.048456548797032
    K2: float = 2.783664552710494
    K3: float = 2.257877224659944e-06
    K4: float = 1.06690453895745
    K5: float = 2.2870254417439186

    return -(by0*(cosh(sqrt(K0)*Lq0)*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))) + sqrt(K0)*sinh(sqrt(K0)*Lq0)*((sin(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))/sqrt(K1) + cos(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))) + Ld1*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))))))**2) + 2*ay0*(cosh(sqrt(K0)*Lq0)*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))) + sqrt(K0)*sinh(sqrt(K0)*Lq0)*((sin(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))/sqrt(K1) + cos(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))) + Ld1*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))))))*((sinh(sqrt(K0)*Lq0)*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))))/sqrt(K0) + cosh(sqrt(K0)*Lq0)*((sin(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))/sqrt(K1) + cos(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))) + Ld1*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))))) + Ld0*(cosh(sqrt(K0)*Lq0)*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))) + sqrt(K0)*sinh(sqrt(K0)*Lq0)*((sin(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))/sqrt(K1) + cos(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))) + Ld1*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))))))) - (1 + ay0**2/by0)*((sinh(sqrt(K0)*Lq0)*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))))/sqrt(K0) + cosh(sqrt(K0)*Lq0)*((sin(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))/sqrt(K1) + cos(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))) + Ld1*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))))) + Ld0*(cosh(sqrt(K0)*Lq0)*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))) + sqrt(K0)*sinh(sqrt(K0)*Lq0)*((sin(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))/sqrt(K1) + cos(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))))) + Ld1*(cos(sqrt(K1)*Lq1)*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))) - sqrt(K1)*sin(sqrt(K1)*Lq1)*((sinh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))/sqrt(K2) + cosh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))))) + Ld2*(cosh(sqrt(K2)*Lq2)*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))) + sqrt(K2)*sinh(sqrt(K2)*Lq2)*((sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))/sqrt(K3) + cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4))) + Ld3*(cos(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)) - sqrt(K3)*sin(sqrt(K3)*Lq3)*(cosh(sqrt(K4)*Lq4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))) + ((cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5))*sinh(sqrt(K4)*Lq4))/sqrt(K4) + Ld4*(cosh(sqrt(K4)*Lq4)*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)) + sqrt(K4)*(Ld6*cos(sqrt(K5)*Lq5) + sin(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cos(sqrt(K5)*Lq5) - sqrt(K5)*Ld6*sin(sqrt(K5)*Lq5)))*sinh(sqrt(K4)*Lq4)))))))))))**2 + bx0*(cos(sqrt(K0)*Lq0)*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))) - sqrt(K0)*sin(sqrt(K0)*Lq0)*((sinh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))/sqrt(K1) + cosh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))) + Ld1*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))))))**2 - 2*ax0*(cos(sqrt(K0)*Lq0)*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))) - sqrt(K0)*sin(sqrt(K0)*Lq0)*((sinh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))/sqrt(K1) + cosh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))) + Ld1*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))))))*((sin(sqrt(K0)*Lq0)*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))))/sqrt(K0) + cos(sqrt(K0)*Lq0)*((sinh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))/sqrt(K1) + cosh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))) + Ld1*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))))) + Ld0*(cos(sqrt(K0)*Lq0)*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))) - sqrt(K0)*sin(sqrt(K0)*Lq0)*((sinh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))/sqrt(K1) + cosh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))) + Ld1*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))))))) + (1 + ax0**2/bx0)*((sin(sqrt(K0)*Lq0)*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))))/sqrt(K0) + cos(sqrt(K0)*Lq0)*((sinh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))/sqrt(K1) + cosh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))) + Ld1*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))))) + Ld0*(cos(sqrt(K0)*Lq0)*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))) - sqrt(K0)*sin(sqrt(K0)*Lq0)*((sinh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))/sqrt(K1) + cosh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))))) + Ld1*(cosh(sqrt(K1)*Lq1)*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))) + sqrt(K1)*sinh(sqrt(K1)*Lq1)*((sin(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))/sqrt(K2) + cos(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))))) + Ld2*(cos(sqrt(K2)*Lq2)*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))) - sqrt(K2)*sin(sqrt(K2)*Lq2)*((sinh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))/sqrt(K3) + cosh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))))) + Ld3*(cosh(sqrt(K3)*Lq3)*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))) + sqrt(K3)*sinh(sqrt(K3)*Lq3)*((sin(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))/sqrt(K4) + cos(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5))) + Ld4*(cos(sqrt(K4)*Lq4)*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)) - sqrt(K4)*sin(sqrt(K4)*Lq4)*(Ld6*cosh(sqrt(K5)*Lq5) + sinh(sqrt(K5)*Lq5)/sqrt(K5) + Ld5*(cosh(sqrt(K5)*Lq5) + sqrt(K5)*Ld6*sinh(sqrt(K5)*Lq5)))))))))))))**2
```

user: rtesse
labels: performance - compile time: Performance issue occurring at compile time.
issue_6494: state: open
title: Boxing LiteralList fails
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
See example. Tested with 0.52.0rc2 as well.

```python
import numba

@numba.njit
def f():
    return ["A", 2]

f()
```
```
  File "/Users/ehsan/dev/numba/numba/core/lowering.py", line 242, in create_cpython_wrapper
    self.context.create_cpython_wrapper(self.library, self.fndesc,
  File "/Users/ehsan/dev/numba/numba/core/cpu.py", line 162, in create_cpython_wrapper
    builder.build()
  File "/Users/ehsan/dev/numba/numba/core/callwrapper.py", line 122, in build
    self.build_wrapper(api, builder, closure, args, kws)
  File "/Users/ehsan/dev/numba/numba/core/callwrapper.py", line 176, in build_wrapper
    obj = api.from_native_return(retty, retval, env_manager)
  File "/Users/ehsan/dev/numba/numba/core/pythonapi.py", line 1389, in from_native_return
    out = self.from_native_value(typ, val, env_manager)
  File "/Users/ehsan/dev/numba/numba/core/pythonapi.py", line 1403, in from_native_value
    return impl(typ, val, c)
  File "/Users/ehsan/dev/numba/numba/core/boxing.py", line 1081, in box_literal
    return c.pyapi.unserialize(c.pyapi.serialize_object(retval))
  File "/Users/ehsan/dev/numba/numba/core/pythonapi.py", line 1362, in serialize_object
    gv = self.module.__serialized[obj]
TypeError: Failed in nopython mode pipeline (step: nopython mode backend)
unhashable type: 'list'
```
user: ehsantn
labels: good second issue: A good issue for second time contributors
issue_6491: state: open
title: try/except in objmode fails with NameError
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the ~latest released~ mainline version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This
```python
from numba import jit

@jit(forceobj=True)
def foo():
    try:
        pass
    except:
        pass

foo()
```
fails with:
```
NameError: global name 'mark_try_block' is not defined
```
works fine in `nopython` mode.
user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6488: state: open
title: Dict in njitted function
body: Minimum example:

```

import numba as nb
from numba.core import types
from numba.typed import Dict

d_test = Dict.empty(
    key_type=types.unicode_type,
    value_type=types.float64,
)

d_test['a'] = 0.1
d_test['b'] = 0.2


@nb.njit()
def nb_dict_test():
    v1 = d_test['a']
    v2 = d_test['b']
    summed_v = v1 + v2
    return summed_v

nb_dict_test()
```



or 

```
d_test = Dict.empty(
    key_type=types.float64,
    value_type=types.float64,
)

d_test[0.1] = 0.1
d_test[0.2] = 0.2


@nb.njit()
def nb_dict_test():
    v1 = d_test[0.1]
    v2 = d_test[0.2]
    summed_v = v1 + v2
    return summed_v

nb_dict_test()
```

do not work with the error message
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: ensure IR is legal prior to lowering)
The use of a DictType[unicode_type,float64]<iv=None> type, assigned to variable 'd_test' in globals, is not supported as globals are considered compile-time constants and there is no known way to compile a DictType[unicode_type,float64]<iv=None> type as a constant.
File "<string>", line 12:
<source missing, REPL/exec in use?>
```


Putting the dict into the function does work, but this is not the desired solution as it is slow for my case:

```

@nb.njit()
def nb_dict_test():
    d_test = Dict.empty(
        key_type=types.float64,
        value_type=types.float64,
    )

    d_test[0.1] = 0.1
    d_test[0.2] = 0.2

    v1 = d_test[0.1]
    v2 = d_test[0.2]
    summed_v = v1 + v2
    return summed_v

nb_dict_test()
```



Not sure if this is indeed not implemented or if there is an error in my implementation? The goal is to have a lookup table inside of a @nb.njit() function - is there any recommended way to do it?
user: BEpresent
issue_6484: state: open
title: Cannot convert unicode or char dtype to longer fixed size
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
I'm trying to increase the (fixed) length string/unicode dtype of an array. I've tried a number of ways, but none of them work. I think the following two methods should work however, but fail with the error given in the comments:

```python
import numba
import numpy as np

@numba.njit
def assign_in_array(source, destination):
    destination[:] = source

@numba.njit
def using_astype(source, destination):
    converted =source.astype(destination.dtype)
    destination[:] = converted


if __name__ == '__main__':
    assert numba.__version__ == '0.51.2'
    src = np.array(['val'], dtype='S4') # also U4/U8 doesn't work
    dst = np.empty_like(src, dtype='S8')

    assign_in_array(src, dst)
    # numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
    # No implementation of function Function(<built-in function setitem>) found for signature:
    #
    #  >>> setitem(array([unichr x 8], 1d, C), slice<a:b>, array([unichr x 4], 1d, C))
    #
    # There are 16 candidate implementations:
    #   - Of which 16 did not match due to:
    #   Overload of function 'setitem': File: <numerous>: Line N/A.
    #     With argument(s): '(array([unichr x 8], 1d, C), slice<a:b>, array([unichr x 4], 1d, C))':
    #    No match.

    using_astype(src, dst)
    # numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
    # - Resolution failure for literal arguments:
    # astype([char x 8]) not supported on array([char x 4], 1d, C): cannot convert from [char x 4] to [char x 8]
    # - Resolution failure for non-literal arguments:
    # None
```

Is there any other way that might work?

user: elfjes
issue_6481: state: open
title: slicing c-contiguous array in row-major way yields non-c-contiguous array in numba (though not in numpy)
body: I have a four-d array (let's call it four_d_arr) that is C-contiguous. In Python, slicing the array like three_d_arr = four_d_arr[0,:,:,:] yields a three dimensional array that's C-contiguous. However, this behavior is not the same in numba (and I'm not sure why?). I detected this behavior when trying to reshape the three-d array from the slice (reshape() supports contiguous array only). 
I included code below that shows how such a slice maintains C-contiguity in numpy, but when compiled with numba the slice is no longer contiguous.
I am able to reshape the three_d array by copying it with np.ascontiguousarray, which seems to indicate that the slicing process in numba is breaking the c-contiguity...

Here's a minimal script that reproduces the problem:
---------------------------------------------------------------------------------------------------------------------------------      

```
import numpy as np                                                                                                                                                                                                                                                                                                           
import numba                                                                                                                                                                                                                                                                                                                 
from numba import jit                                                                                                                                                                                                                                                                                                        
                                                                                                                                                                                                                                                                                                                             
def reshape_arr(four_d_array):                                                                                                                                                                                                                                                                                               
    """                                                                                                                                                                                                                                                                                                                      
    Demonstrate that a sliced four d array along its first                                                                                                                                                                                                                                                                   
    dimension is still C contiguous                                                                                                                                                                                                                                                                                          
    """                                                                                                                                                                                                                                                                                                                      
    print('Input array flags\n', four_d_array.flags)                                                                                                                                                                                                                                                                         
    three_d_array = four_d_array[0,:,:,:]                                                                                                                                                                                                                                                                                    
    print('Sliced array flags (sliced on the first axis, so should still be c contiguous)\n')                                                                                                                                                                                                                                
    print(three_d_array.flags)                                                                                                                                                                                                                                                                                               
    last_axis_dim = three_d_array.shape[1]*three_d_array.shape[2]                                                                                                                                                                                                                                                            
    first_axis_dim = three_d_array.shape[0]                                                                                                                                                                                                                                                                                  
    three_d_array = three_d_array.reshape(first_axis_dim, last_axis_dim)                                                                                                                                                                                                                                                     
    return                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                             
@jit(nopython=True)                                                                                                                                                                                                                                                                                                          
def jit_reshape_arr_as_cont(four_d_array):                                                                                                                                                                                                                                                                                   
    """                                                                                                                                                                                                                                                                                                                      
    Demonstrate that copying the array with                                                                                                                                                                                                                                                                                  
    np.ascontiguousarray permits successful                                                                                                                                                                                                                                                                                  
    compilation                                                                                                                                                                                                                                                                                                              
    """                                                                                                                                                                                                                                                                                                                      
    three_d_array = four_d_array[0,:,:,:]                                                                                                                                                                                                                                                                                    
    last_axis_dim = three_d_array.shape[1]*three_d_array.shape[2]                                                                                                                                                                                                                                                            
    first_axis_dim = three_d_array.shape[0]                                                                                                                                                                                                                                                                                  
    three_d_array = np.ascontiguousarray(three_d_array)                                                                                                                                                                                                                                                                      
    three_d_array = three_d_array.reshape(first_axis_dim, last_axis_dim)                                                                                                                                                                                                                                                     
    return                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                             
@jit(nopython=True)                                                                                                                                                                                                                                                                                                          
def jit_reshape_arr(four_d_array):                                                                                                                                                                                                                                                                                           
    """                                                                                                                                                                                                                                                                                                                      
    Demonstrate that the sliced array fails                                                                                                                                                                                                                                                                                  
    to be reshaped, apparently because the                                                                                                                                                                                                                                                                                   
    C-contiguity is broken by slicing                                                                                                                                                                                                                                                                                        
    """                                                                                                                                                                                                                                                                                                                      
    three_d_array = four_d_array[0,:,:,:]                                                                                                                                                                                                                                                                                    
    last_axis_dim = three_d_array.shape[1]*three_d_array.shape[2]                                                                                                                                                                                                                                                            
    first_axis_dim = three_d_array.shape[0]                                                                                                                                                                                                                                                                                  
    three_d_array = three_d_array.reshape(first_axis_dim, last_axis_dim)                                                                                                                                                                                                                                                     
    return                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                             
                                                                                                                                                                                                                                                                                                                             
if __name__ == '__main__':                                                                                                                                                                                                                                                                                                   
    arr = np.ones((3,4,5,6))                                                                                                                                                                                                                                                                                                 
    print(arr.flags)                                                                                                                                                                                                                                                                                                         
    print('Run without jit. Note that at all stages of this function the array is c contiguous')                                                                                                                                                                                                                             
    reshape_arr(arr)                                                                                                                                                                                                                                                                                                         
    print('Run with jit, but copy sliced array with "as contiguous array". It succeeds')                                                                                                                                                                                                                                     
    jit_reshape_arr_as_cont(arr)                                                                                                                                                                                                                                                                                             
    print('Now run with jit, but without copying array. reshape throws error \'reshape() supports contiguous arrays only\'')                                                                                                                                                                                                                          
    jit_reshape_arr(arr)                    
```

---------------------------------------------------------------------------------------------------------------------------------      
The output from running this on my machine yields

```
>>> python bug_test.py                                                                                                                                                            
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
```

Run without jit. Note that at all stages of this function the array is c contiguous
Input array flags
```
   C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
```

Sliced array flags (sliced on the first axis, so should still be c contiguous)

```
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
```

Run with jit, but copy sliced array with "as contiguous array". It succeeds
Now run with jit, but without copying array. reshape throws error \'reshape() supports contiguous arrays only'

```
Traceback (most recent call last):
  File "bug_test.py", line 42, in <module>
    jit_reshape_arr(arr)
  File "/home/hunter/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/hunter/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 358, in error_rewrite
    reraise(type(e), e, None)
  File "/home/hunter/anaconda3/lib/python3.8/site-packages/numba/core/utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
- Resolution failure for literal arguments:
reshape() supports contiguous array only
- Resolution failure for non-literal arguments:
None

During: resolving callee type: BoundFunction(array.reshape for array(float64, 3d, A))
During: typing of call at bug_test.py (29)


File "bug_test.py", line 29:
def jit_reshape_arr(four_d_array):
    <source elided>
    first_axis_dim = three_d_array.shape[0]
    three_d_array = three_d_array.reshape(first_axis_dim, last_axis_dim)
```


user: hunterakins
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6475: state: open
title: MLIR based backend for Numba
body: Just to share and discuss our ongoing work on MLIR based backend for Numba.

https://github.com/IntelPython/numba/pull/115

It is very limited at the moment but it already can run simple codes
user: Hardcode84
labels: discussion: An issue requiring discussion
issue_6465: state: open
title: PPC lowering error from changes on optimization passes
body: Happening on the https://github.com/numba/numba/commit/4334a6caaf693e66879fa3f50fb1e4aeaa33c569 on the buildfarm

```python
python: /opt/conda/conda-bld/llvmdev_1601977481024/work/lib/Target/PowerPC/PPCISelLowering.cpp:6450: llvm::SDValue llvm::PPCTargetLowering::LowerCall_64SVR4(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, bool, bool, const llvm::SmallVectorImpl<llvm::ISD::OutputArg>&, const llvm::SmallVectorImpl<llvm::SDValue>&, const llvm::SmallVectorImpl<llvm::ISD::InputArg>&, const llvm::SDLoc&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::ImmutableCallSite) const: Assertion `(!HasParameterArea || NumBytesActuallyUsed == ArgOffset) && "mismatch in size of parameter area"' failed.
Fatal Python error: Aborted
```

likely from tests:
```
numba.tests.test_record_dtype.TestRecordDtypeWithCharSeq.test_py_argument_char_seq_near_overflow
numba.tests.test_record_dtype.TestRecordDtypeWithCharSeq.test_py_argument_char_seq_truncate
numba.tests.test_record_dtype.TestRecordDtypeWithCharSeq.test_py_argument_charseq
```
user: sklam
labels: llvm: LLVM related issues
ISA: POWER: Issue related to POWER ISA
issue_6462: state: open
title: Feature request: bytes.decode
body: # Feature request

I would like to do `b"abc".decode("utf-8")` in no python mode.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

My use case is that h5py has decided to return text data as bytes. I would like to be able to quickly decode text data stored in structured arrays without having the loop be in python. I'm sure there are more common use cases for this as well.

I would hope that cpython's utf-8 decoding (https://github.com/python/cpython/blob/master/Objects/stringlib/codecs.h) could be reused here, but don't really know enough about how unicode strings work to comment more.
user: ivirshup
issue_6459: state: open
title: ByteArray doesn't support boxing or slicing
body: When working with a byte array type it seems that unboxing is supported, but boxing is not supported. Here is an example reproducer.

```python
import numba

arr = bytearray([1, 2, 3, 4])
print(numba.njit(lambda x: x)(arr))
```

with output:
```python
Traceback (most recent call last):
  File "test_bytearray.py", line 4, in <module>
    print(numba.njit(lambda x: x)(arr))
TypeError: cannot convert native bytearray(uint8, 1d, C) to Python object
```

In addition ByteArrays doesn't seems to support getitem with slices. Here is the reproducer:
```python
import numba

arr = bytearray([1, 2, 3, 4])
print(numba.njit(lambda x: x)(arr))
```

with output:
```python
Traceback (most recent call last):
  File "test_bytearray.py", line 4, in <module>
    print(numba.njit(lambda x: x[1:3])(arr))
  File "/Users/nicholasriasanovsky/Documents/bodo/numba/numba/core/dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/Users/nicholasriasanovsky/Documents/bodo/numba/numba/core/dispatcher.py", line 358, in error_rewrite
    reraise(type(e), e, None)
  File "/Users/nicholasriasanovsky/Documents/bodo/numba/numba/core/utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function getitem>) found for signature:
 
 >>> getitem(bytearray(uint8, 1d, C), slice<a:b>)
 
There are 22 candidate implementations:
  - Of which 22 did not match due to:
  Overload of function 'getitem': File: <numerous>: Line N/A.
    With argument(s): '(bytearray(uint8, 1d, C), slice<a:b>)':
   No match.

During: typing of intrinsic-call at test_bytearray.py (4)
During: typing of static-get-item at test_bytearray.py (4)

File "test_bytearray.py", line 4:
arr = bytearray([1, 2, 3, 4])
print(numba.njit(lambda x: x[1:3])(arr))
```

This appears to be because the getitem overload for buffer types works with borrowed references and ByteArray has `slice_is_copy` set to True. As a result `getitem_arraynd_intp` is never entered, so I assume this requires a separate overload that makes a fresh copy.
user: njriasan
issue_6448: state: open
title: CUDA: Add accessors for function attributes beyond just register use per thread
body: PR #6447 adds a public API to get the maximum number of registers per thread (`numba.cuda.Dispatcher.get_regs_per_thread()`). There are other attributes that might be nice to provide - shared memory per block, local memory per thread, const memory usage, maximum block size.

These are all available in the `FuncAttr` named tuple: https://github.com/numba/numba/blob/master/numba/cuda/cudadrv/driver.py#L2023, set by `_read_func_attr_all`: https://github.com/numba/numba/blob/master/numba/cuda/cudadrv/driver.py#L2067

Cross ref: adding these would provide some of the info in the ptxas output requested in #3482. 
user: gmarkall
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_6426: state: open
title: Mutually-recursive nopython functions compile error
body: 
Numba 0.51.2, Python 3.7.1 on Windows

This is the tracked issue for the discussion [here](https://numba.discourse.group/t/mutual-recursion/317/2)

I’m attempting to port ntdr.c to njitted python. There are a couple of mutually recursive functions that are tripping up the compiler. The program works in regular python but in nopython mode I get a cascading signature error like below. I’ve tried various bits, like explicitly specifying function signatures with @njit(‘f8(f8)’) to no avail. I assume I’m making a fundamental mistake and hoping for a pointer about where.  Error and code are below

> numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
> No implementation of function Function(<function ndtr at 0x0000026EEB7662F0>) found for signature:
> 
> ndtr(float64)
> 
> There are 2 candidate implementations:
> 
> Of which 2 did not match due to:
> Overload in function ‘register_jitable..wrap..ov_wrap’: File: numba\core\extending.py: Line 150.
> With argument(s): ‘(float64)’:
> Rejected as the implementation raised a specific error:
> TypingError: Failed in nopython mode pipeline (step: nopython frontend)
> No implementation of function Function(<function erf at 0x0000026EEB766950>) found for signature:
> erf(float64)

```python
import math
from numba import njit
import numpy as np
from numba.extending import register_jitable

MAXLOG = 7.09782712893383996843E2
M_PI = 3.1415926535897932384626433832795

P = [
    2.46196981473530512524E-10,
    5.64189564831068821977E-1,
    7.46321056442269912687E0,
    4.86371970985681366614E1,
    1.96520832956077098242E2,
    5.26445194995477358631E2,
    9.34528527171957607540E2,
    1.02755188689515710272E3,
    5.57535335369399327526E2
]

P_rev = tuple(reversed(P))

Q = [
    #
    # 1.00000000000000000000E0,
    #
    1.32281951154744992508E1,
    8.67072140885989742329E1,
    3.54937778887819891062E2,
    9.75708501743205489753E2,
    1.82390916687909736289E3,
    2.24633760818710981792E3,
    1.65666309194161350182E3,
    5.57535340817727675546E2
]

Q_rev = tuple(reversed(Q))


R = [
    5.64189583547755073984E-1,
    1.27536670759978104416E0,
    5.01905042251180477414E0,
    6.16021097993053585195E0,
    7.40974269950448939160E0,
    2.97886665372100240670E0
]

R_rev = tuple(reversed(R))

S = [
    #
    # 1.00000000000000000000E0,
    #
    2.26052863220117276590E0,
    9.39603524938001434673E0,
    1.20489539808096656605E1,
    1.70814450747565897222E1,
    9.60896809063285878198E0,
    3.36907645100081516050E0
]
S_rev = tuple(reversed(S))

T = [
    9.60497373987051638749E0,
    9.00260197203842689217E1,
    2.23200534594684319226E3,
    7.00332514112805075473E3,
    5.55923013010394962768E4
]
T_rev = tuple(reversed(T))

U = [
    #
    # 1.00000000000000000000E0,
    #
    3.35617141647503099647E1,
    5.21357949780152679795E2,
    4.59432382970980127987E3,
    2.26290000613890934246E4,
    4.92673942608635921086E4
]
U_rev = tuple(reversed(U))

UTHRESH = 37.519379347
NPY_SQRT1_2 = 0.707106781186547524400844362104849039

@njit
def polevl_rev(x, coefs):
    ans = 0
    x_power = 1
    for coef in coefs:
        ans += coef * x_power
        x_power = x_power * x
    return ans


@njit
def p1evl_rev(x, coefs):
    ans = 0
    x_power = 1
    for coef in coefs:
        ans += coef * x_power
        x_power = x_power * x
    return ans + x_power


@register_jitable
def ndtr(a):
    if np.isnan(a):
        return np.nan

    x = a * NPY_SQRT1_2
    z = np.fabs(x)

    if z < NPY_SQRT1_2:
        y = 0.5 + 0.5 * erf(x)
    else:
        y = 0.5 * erfc(z)

        if x > 0:
            y = 1.0 - y

    return y


@register_jitable
def under(a):
    return 2.0 if a < 0 else 0.0


@register_jitable
def erf_positive(x):
    """
    erf for positive number.  attempting to reduce recursion
    :param x:
    :return:
    """
    if x > 1.0:
        return 1.0 - erfc(x)

    z = x * x
    y = x * polevl_rev(z, T_rev) / p1evl_rev(z, U_rev)
    return y


@register_jitable
def erf(x):
    if np.isnan(x):
        return np.nan

    if x < 0.0:
        return -erf_positive(-x)

    return erf_positive(x)

@register_jitable
def erfc(a):
    if np.isnan(a):
        return np.nan

    if a < 0.0:
        x = -a
    else:
        x = a

    if x < 1.0:
        return 1.0 - erf(a)

    z = -a * a

    if z < -MAXLOG:
        return under(a)

    z = math.exp(z)

    if x < 8.0:
        p = polevl_rev(x, P_rev)
        q = p1evl_rev(x, Q_rev)
    else:
        p = polevl_rev(x, R_rev)
        q = p1evl_rev(x, S_rev)
    y = (z * p) / q

    if a < 0:
        y = 2.0 - y

    if y == 0.0:
        return under(a)

    return y


#@njit  # program works until I uncomment this line
def jit_ndtr(x):
    return ndtr(x)

jit_ndtr(2.0)
```

user: nelson2005
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6424: state: open
title: Parallel AOT compilation
body: I'd like to improve the compilation time for doing AOT compilation using pycc by adding parallelism. Here is an example of the sort of thing I am talking about, which takes several minutes to compile

```py
from __future__ import absolute_import, division, print_function

import numba
import numba.pycc
import numpy as np

cc = numba.pycc.CC('extension')

# An iterative quicksort implementation which sorts multiple arrays doing row-wise comparisons.
# It uses numba and code generation to generate efficient code.
# The quicksort implementation in this file is a slightly adapted version of numpy's quicksort:
# https://github.com/numpy/numpy/blob/master/numpy/core/src/npysort/quicksort.c.src
_quicksort_template = '''
def quicksort(idxs, s, e, stack, {arr_names}):
    def lt(x, y):
        return {lt_impl_x_y}

    def swap(x, y):
        t = idxs[x]
        idxs[x] = idxs[y]
        idxs[y] = t

    stack[0] = s
    stack[1] = e - 1
    sptr = 2

    SMALL_QUICKSORT = 15

    while sptr > 0:
        # pop interval to be sorted from stack
        pr = stack[sptr - 1]
        pl = stack[sptr - 2]
        sptr -= 2

        # use quicksort iteratively until interval is too small
        while pr - pl > SMALL_QUICKSORT:
            # compute median element of left, median, right and swap
            pm = pl + ((pr - pl) >> 1)
            if lt(idxs[pm], idxs[pl]):
                swap(pm, pl)
            if lt(idxs[pr], idxs[pm]):
                swap(pr, pm)
            if lt(idxs[pm], idxs[pl]):
                swap(pm, pl)

            # this is our pivot value
            vp = idxs[pm]

            # stash pivot in last unknown element of interval (pr has to be greater than pm from above)
            pi = pl
            pj = pr - 1
            swap(pm, pj)

            # swap left and right according to pivot
            while True:
                pi += 1
                while lt(idxs[pi], vp):
                    pi += 1
                pj -= 1
                while lt(vp, idxs[pj]):
                    pj -= 1
                if pi >= pj:
                    break
                swap(pi, pj)

            # put pivot in its place
            pk = pr - 1
            swap(pi, pk)

            # push largest partition on stack
            assert sptr + 2 <= len(stack)
            if pi - pl < pr - pi:
                stack[sptr] = pi + 1
                stack[sptr + 1] = pr
                sptr += 2
                pr = pi - 1
            else:
                stack[sptr] = pl
                stack[sptr + 1] = pi - 1
                sptr += 2
                pl = pi + 1

        # insertion sort
        for pi in range(pl + 1, pr + 1):
            vp = idxs[pi]
            pj = pi
            pk = pi - 1
            while pj > pl and lt(vp, idxs[pk]):
                idxs[pj] = idxs[pk]
                pj -= 1
                pk -= 1
            idxs[pj] = vp
'''


def _get_quicksort(n_arrs):
    arr_names = tuple('a{}'.format(i) for i in range(n_arrs))
    lt_impl_x_y = '{an}[x] < {an}[y]'.format(an=arr_names[-1])
    for an in reversed(arr_names[:-1]):
        lt_impl_x_y = 'True if {an}[x] < {an}[y] else (False if {an}[x] > {an}[y] else ({lt_impl_x_y}))' \
            .format(an=an, lt_impl_x_y=lt_impl_x_y)
    quicksort_code = _quicksort_template.format(lt_impl_x_y=lt_impl_x_y, arr_names=', '.join(arr_names))
    quicksort_module = compile(quicksort_code, __file__, 'exec')
    globals_dict = {}
    locals_dict = {}
    exec(quicksort_module, globals_dict, locals_dict)
    return locals_dict['quicksort']


AOT_SORT_SUPPORTED_DTYPES = [np.dtype('int64'), np.dtype('int32'), np.dtype('float64')]

for dt1 in AOT_SORT_SUPPORTED_DTYPES:
    cc.export(
        'quicksort_{}'.format(dt1),
        'none(int64[:], int64, int64, int64[:], {}[:])'.format(dt1)
    )(_get_quicksort(1))

for dt1 in AOT_SORT_SUPPORTED_DTYPES:
    for dt2 in AOT_SORT_SUPPORTED_DTYPES:
        cc.export(
            'quicksort_{}_{}'.format(dt1, dt2),
            'none(int64[:], int64, int64, int64[:], {}[:], {}[:])'.format(dt1, dt2)
        )(_get_quicksort(2))

for dt1 in AOT_SORT_SUPPORTED_DTYPES:
    for dt2 in AOT_SORT_SUPPORTED_DTYPES:
        for dt3 in AOT_SORT_SUPPORTED_DTYPES:
            cc.export(
                'quicksort_{}_{}_{}'.format(dt1, dt2, dt3),
                'none(int64[:], int64, int64, int64[:], {}[:], {}[:], {}[:])'.format(dt1, dt2, dt3)
            )(_get_quicksort(3))

for dt1 in AOT_SORT_SUPPORTED_DTYPES:
    for dt2 in AOT_SORT_SUPPORTED_DTYPES:
        for dt3 in AOT_SORT_SUPPORTED_DTYPES:
            for dt4 in AOT_SORT_SUPPORTED_DTYPES:
                cc.export(
                    'quicksort_{}_{}_{}_{}'.format(dt1, dt2, dt3, dt4),
                    'none(int64[:], int64, int64, int64[:], {}[:], {}[:], {}[:], {}[:])'.format(dt1, dt2, dt3, dt4)
                )(_get_quicksort(4))

if __name__ == "__main__":
    cc.compile()
```

A suggestion is to compile each function to a separate object file and then merge them together in the linking step in `CC.compile` and `CC._compile_object_files`.
user: asmeurer
issue_6423: state: open
title: Print over previous output
body: ## Feature request

To write over previous statement without numba, I can just do
```python
print(x, end='\r')
```
I'd like to do the same in njit-compiled functions, but numba doesn't support keywords in print apparently. Would it be possible to implement? Or is there perhaps some other workaround to get the same behavior?

user: bdch1234
issue_6421: state: open
title: Broadcasting doesn't works for cuda target
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

It seems the broadcasting doesn't works as expected, when compiling for 'cuda' target. Here is an example for the same:

Minimal example:

```python
import math
import numpy as np
import cupy

from numba import guvectorize

@guvectorize(  # type: ignore
    [
        "void(float32[:], float32[:], float32[:])",
        "void(float64[:], float64[:], float64[:])",
        "void(int8[:], int8[:], float64[:])",
    ],
    "(n),(n)->()", target='cuda'
)
def g(x, y, out) -> None:
    diff = 0.0
    for i in range(x.shape[0]):
        diff += x[i] - y[i]
    out[0] = diff

def foo_working(x, y):
    x, y = x[:, None, :], y[None, :, :]
    x, y = np.repeat(x, x.shape[0], axis=-2), np.repeat(y, y.shape[1], axis=-3) 
    return g(x, y)

def foo_not_working(x, y):
    return g(x[:, None, :], y[None, :, :])

cs = cupy.random.RandomState(0)
x = cs.randint(0, 3, size=(2, 10)).astype('f8')
y = cs.randint(0, 3, size=(2, 10)).astype('f8')
```

### This works
```python
>>> cupy.asarray(foo_working(x, y))
array([[ 3.,  8.],
       [-1.,  4.]])
```

### This doesn't works
```python
>>> cupy.asarray(foo_not_working(x, y))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-28-d2e9da8d9aa9> in <module>
     31 y = cs.randint(0, 3, size=(2, 10)).astype('f8')
     32 
---> 33 cupy.asarray(foo_not_working(x, y))

<ipython-input-28-d2e9da8d9aa9> in foo_not_working(x, y)
     25 
     26 def foo_not_working(x, y):
---> 27     return g(x[:, None, :], y[None, :, :])
     28 
     29 cs = cupy.random.RandomState(0)

~/.conda/envs/sgkit/lib/python3.8/site-packages/numba/np/ufunc/deviceufunc.py in __call__(self, *args, **kws)
    649                                      args, kws)
    650         callsteps.prepare_inputs()
--> 651         indtypes, schedule, outdtype, kernel = self._schedule(
    652             callsteps.norm_inputs, callsteps.output)
    653         callsteps.adjust_input_types(indtypes)

~/.conda/envs/sgkit/lib/python3.8/site-packages/numba/np/ufunc/deviceufunc.py in _schedule(self, inputs, out)
    662     def _schedule(self, inputs, out):
    663         input_shapes = [a.shape for a in inputs]
--> 664         schedule = self.engine.schedule(input_shapes)
    665 
    666         # find kernel

~/.conda/envs/sgkit/lib/python3.8/site-packages/numba/np/ufunc/deviceufunc.py in schedule(self, ishapes)
    611                     #print(f'outer_shapes: {outer_shapes}, i: {i}, d: {d}, loopdims: {loopdims}')
    612                     fmt = "arg #%d: outer dimension mismatch"
--> 613                     raise ValueError(fmt % (i + 1,))
    614 
    615         return GUFuncSchedule(self, inner_shapes, oshapes, loopdims, pinned)

ValueError: arg #2: outer dimension mismatch
```

user: aktech
labels: CUDA: CUDA related issue/PR
issue_6417: state: open
title: Issue creating list of dictionaries with constant keys and heterogenous data
body: I was trying to work with dictionaries inside an njit function and I encountered some issues while trying to create a list with constant keys and heterogeneous data. Based on this documentation, https://numba.readthedocs.io/en/stable/reference/pysupported.html#heterogeneous-literal-string-key-dictionary, I believe this usage should be supported.

Here are two reproducers demonstrating my issues:

```python
In [10]: @numba.njit
    ...: def f():
    ...:     s = []
    ...:     for i in range(10):
    ...:       d = {'a': 1, 'b': 'data'}
    ...:       s.append(d)
    ...:     return s
    ...:
    ...:
In [11]: f()
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-11-c43e34e6d405> in <module>
----> 1 f()
~/dev/numba/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    413                 e.patch_message(msg)
    414
--> 415             error_rewrite(e, 'typing')
    416         except errors.UnsupportedError as e:
    417             # Something unsupported is present in the user code, add help info
~/dev/numba/numba/core/dispatcher.py in error_rewrite(e, issue_type)
    356                 raise e
    357             else:
--> 358                 reraise(type(e), e, None)
    359
    360         argtypes = []
~/dev/numba/numba/core/utils.py in reraise(tp, value, tb)
     78         value = tp()
     79     if value.__traceback__ is not tb:
---> 80         raise value.with_traceback(tb)
     81     raise value
     82
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Poison type used in arguments; got Poison<LiteralStrKey[Dict]({Literal[str](a): Literal[int](1), Literal[str](b): Literal[str](data)})>
During: resolving callee type: BoundFunction(list.append for list(undefined)<iv=None>)
During: typing of call at <ipython-input-10-4ad4bb8e6cc0> (6)
File "<ipython-input-10-4ad4bb8e6cc0>", line 6:
def f():
    <source elided>
      d = {'a': 1, 'b': 'data'}
      s.append(d)
      ^
which produces the output
```python
@numba.njit
    ...: def f():
    ...:     s = []
    ...:     for i in range(10):
    ...:       d = {'a': 1, 'b': 'data'}
    ...:       s.append(d)
    ...:     return s
```

```python
In [12]: @numba.njit
    ...: def f():
    ...:     s = []
    ...:     for i in range(10):
    ...:       d = {'a': 1, 'b': 2.2}
    ...:       s.append(d)
    ...:     return s
    ...:
    ...:
In [13]: f()
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-13-c43e34e6d405> in <module>
----> 1 f()
~/dev/numba/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    413                 e.patch_message(msg)
    414
--> 415             error_rewrite(e, 'typing')
    416         except errors.UnsupportedError as e:
    417             # Something unsupported is present in the user code, add help info
~/dev/numba/numba/core/dispatcher.py in error_rewrite(e, issue_type)
    356                 raise e
    357             else:
--> 358                 reraise(type(e), e, None)
    359
    360         argtypes = []
~/dev/numba/numba/core/utils.py in reraise(tp, value, tb)
     78         value = tp()
     79     if value.__traceback__ is not tb:
---> 80         raise value.with_traceback(tb)
     81     raise value
     82
TypingError: Failed in nopython mode pipeline (step: nopython mode backend)
Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function setitem>) found for signature:
 >>> setitem(DictType[unicode_type,int64]<iv=None>, Literal[str](b), float64)
There are 16 candidate implementations:
  - Of which 14 did not match due to:
  Overload of function 'setitem': File: <numerous>: Line N/A.
    With argument(s): '(DictType[unicode_type,int64]<iv=None>, unicode_type, float64)':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'impl_setitem': File: numba/typed/dictobject.py: Line 671.
    With argument(s): '(DictType[unicode_type,int64]<iv=None>, unicode_type, float64)':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<intrinsic _cast>) found for signature:
    >>> <unknown function>(float64, class(int64))
   There are 2 candidate implementations:
         - Of which 2 did not match due to:
         Intrinsic in function '_cast': File: numba/typed/typedobjectutils.py: Line 23.
           With argument(s): '(float64, class(int64))':
          Rejected as the implementation raised a specific error:
            TypingError: cannot safely cast float64 to int64. Please cast explicitly.
     raised from /Users/ehsan/dev/numba/numba/typed/typedobjectutils.py:76
   During: resolving callee type: Function(<intrinsic _cast>)
   During: typing of call at /Users/ehsan/dev/numba/numba/typed/dictobject.py (680)
   File "../numba/numba/typed/dictobject.py", line 680:
       def impl(d, key, value):
           <source elided>
           castedkey = _cast(key, keyty)
           castedval = _cast(value, valty)
           ^
  raised from /Users/ehsan/dev/numba/numba/core/typeinfer.py:1071
During: typing of setitem at /Users/ehsan/dev/numba/numba/typed/dictobject.py (1106)
File "../numba/numba/typed/dictobject.py", line 1106:
                def put(d, k, v):
                    d[k] = v
                    ^
During: lowering "$24build_const_key_map.7 = build_map(items=[(Var($24build_const_key_map.5, <ipython-input-12-4ee2dbb48a06>:5), Var($const18.2, <ipython-input-12-4ee2dbb48a06>:5)), (Var($24build_const_key_map.6, <ipython-input-12-4ee2dbb48a06>:5), Var($const20.3, <ipython-input-12-4ee2dbb48a06>:5))], size=2, literal_value={'a': 1, 'b': 2.2}, value_indexes={'a': 0, 'b': 1})" at <ipython-input-12-4ee2dbb48a06> (5)
```

user: njriasan
issue_6413: state: open
title: Make parfor array analysis store information only for integer types.
body: In parfor array analysis, due to calls to array.shape or manual construction of a shape tuple, we form correlations between arrays and the tuples that you get form accessing an array shape attribute or the tuples provided to create an array such as np.ones((3,5)).  Right now, we don't try to determine whether a tuple is used to create an array.  If we see a tuple then we track it but any kind of tuple could be created with any types.  Thus, a tuple containing strings would be tracked by array analysis when that could never be used to create an array.  This just results in wasted space and time and makes the code more prone to error if we have assumptions in the code about expecting integer types.  Thus, I propose that we only track integer types.  Some questions then is if a tuple is a mix of integer and non-integer types do we try to track the integer portion but not the non-integer.  Also, can we extend our current approach easily to handle nested-tuples?
user: DrTodd13
issue_6387: state: open
title: NumPy ndarray expression with broadcast is slower when not use local variable.
body: Numba 0.51.2

Here is the code, `f1()` is 24x faster than `f2()`.

```python
import numpy as np
from numba import njit
x = np.random.randn(1, 1000)
y = np.random.randn(100, 1)

@njit
def f1(x, y):
    a = np.sin(x**2)
    b = np.cos(y**2)
    return a + b

@njit
def f2(x, y):
    return np.sin(x**2) + np.cos(y**2)

f1(x, y)
f2(x, y)

%timeit f1(x, y)
%timeit f2(x, y)
```

and here is the result:

```
75.4 µs ± 2.57 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
1.81 ms ± 102 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```
user: ruoyu0088
labels: performance - run time: Performance issue occurring at run time.
issue_6382: state: open
title: Release global interpreter lock (GIL) in ahead-of-time-compiled code
body: ## Feature request

It would be nice if the global interpreter lock could be released for AOT-compiled code so that multiple functions can be run in parallel.

The syntax could be `@cc.export("foo", nogil=True)`, similar to how jit currently works:`@jit(nogil=True)`

The following code calls three test functions 10 times in parallel (run on a quad-core CPU) to demonstrate that releasing the GIL is a useful feature to improve performance on multi-core systems.

- Jitted function with GIL (0.95 seconds)
- Jitted function with GIL released (0.25 seconds)
- AOT-compiled function with GIL (1.05 seconds)

```python3
from numba import jit
from numba.pycc import CC
from threading import Thread
import time

@jit(nogil=False)
def testfunc_jit_withgil(n, x):
    s = 0.0
    for _ in range(n):
        s += x
    return s

@jit(nogil=True)
def testfunc_jit_nogil(n, x):
    s = 0.0
    for _ in range(n):
        s += x
    return s

cc = CC("mymodule")

@cc.export("testfunc_aot", "f8(i8, f8)")
def testfunc_aot(n, x):
    s = 0.0
    for _ in range(n):
        s += x
    return s

cc.compile()

from mymodule import testfunc_aot

def benchmark(func):
    # warmup
    for _ in range(10):
        func(10**6, 1.0)

    start_time = time.perf_counter()

    threads = [Thread(target=func, args=(10**8, 1.0)) for _ in range(10)]
    for thread in threads: thread.start()
    for thread in threads: thread.join()

    elapsed_time = time.perf_counter() - start_time
    print(elapsed_time, "seconds\n")

print("with JIT, with GIL:")
benchmark(testfunc_jit_withgil)
print("with JIT, without GIL:")
benchmark(testfunc_jit_nogil)
print("AOT-compiled:")
benchmark(testfunc_aot)
```
user: 99991
labels: AOT: ahead of time compilation issue
good second issue: A good issue for second time contributors
issue_6381: state: open
title: np.shift_left and np.shift_right unsupported for np.uint64
body: Hello. From what I can tell numpy arrays with 64 bit unsigned integers seem to fail in compilation. Here is a reproducer:

 
```python
In [48]: arr = np.array([1, 2, 1, 1, 1, 31,4], np.uint64)

In [49]: np.left_shift(arr, 1)
Out[49]: array([ 2,  4,  2,  2,  2, 62,  8], dtype=uint64)

In [50]: numba.njit(lambda arr: np.left_shift(arr, 1))
Out[50]: CPUDispatcher(<function <lambda> at 0x7fe165c65b80>)

In [51]: arr = np.array([1, 2, 1, 1, 1, 31,4], np.uint64)

In [52]: np.left_shift(arr, 1)
Out[52]: array([ 2,  4,  2,  2,  2, 62,  8], dtype=uint64)

In [53]: numba.njit(lambda arr: np.left_shift(arr, 1))(arr)
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-53-d08695da763c> in <module>
----> 1 numba.njit(lambda arr: np.left_shift(arr, 1))(arr)

~/Documents/bodo/Bodo/bodo/numba_compat.py in _compile_for_args(***failed resolving arguments***)
    919             e.patch_message(msg)
    920 
--> 921         error_rewrite(e, "typing")
    922     except errors.UnsupportedError as e:
    923         # Something unsupported is present in the user code, add help info

~/Documents/bodo/Bodo/bodo/numba_compat.py in error_rewrite(e, issue_type)
    843             raise e
    844         else:
--> 845             reraise(type(e), e, None)
    846 
    847     argtypes = []

~/Documents/bodo/numba/numba/core/utils.py in reraise(tp, value, tb)
     78         value = tp()
     79     if value.__traceback__ is not tb:
---> 80         raise value.with_traceback(tb)
     81     raise value
     82 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<ufunc 'left_shift'>) found for signature:
 
 >>> left_shift(array(uint64, 1d, C), Literal[int](1))
 
There are 5 candidate implementations:
      - Of which 1 did not match due to:
      Overload in function 'Numpy_rules_ufunc.generic': File: numba/core/typing/npydecl.py: Line 96.
        With argument(s): '(array(uint64, 1d, C), int64)':
       Rejected as the implementation raised a specific error:
         TypingError: can't resolve ufunc left_shift for types (array(uint64, 1d, C), int64)
  raised from /Users/nicholasriasanovsky/Documents/bodo/numba/numba/core/typing/npydecl.py:102
      - Of which 1 did not match due to:
      Overload in function 'Numpy_rules_ufunc.generic': File: numba/core/typing/npydecl.py: Line 96.
        With argument(s): '(array(uint64, 1d, C), Literal[int](1))':
       Rejected as the implementation raised a specific error:
         TypingError: can't resolve ufunc left_shift for types (array(uint64, 1d, C), Literal[int](1))
  raised from /Users/nicholasriasanovsky/Documents/bodo/numba/numba/core/typing/npydecl.py:102
      - Of which 3 did not match due to:
      Overload of function 'left_shift': File: <numerous>: Line N/A.
        With argument(s): '(array(uint64, 1d, C), Literal[int](1))':
       No match.

During: resolving callee type: Function(<ufunc 'left_shift'>)
During: typing of call at <ipython-input-53-d08695da763c> (1)


File "<ipython-input-53-d08695da763c>", line 1:
numba.njit(lambda arr: np.left_shift(arr, 1))(arr)
^


In [54]: np.right_shift(arr, 1)
Out[54]: array([ 0,  1,  0,  0,  0, 15,  2], dtype=uint64)

In [55]: numba.njit(lambda arr: np.right_shift(arr, 1))(arr)
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-55-bf0e79c0242b> in <module>
----> 1 numba.njit(lambda arr: np.right_shift(arr, 1))(arr)

~/Documents/bodo/Bodo/bodo/numba_compat.py in _compile_for_args(***failed resolving arguments***)
    919             e.patch_message(msg)
    920 
--> 921         error_rewrite(e, "typing")
    922     except errors.UnsupportedError as e:
    923         # Something unsupported is present in the user code, add help info

~/Documents/bodo/Bodo/bodo/numba_compat.py in error_rewrite(e, issue_type)
    843             raise e
    844         else:
--> 845             reraise(type(e), e, None)
    846 
    847     argtypes = []

~/Documents/bodo/numba/numba/core/utils.py in reraise(tp, value, tb)
     78         value = tp()
     79     if value.__traceback__ is not tb:
---> 80         raise value.with_traceback(tb)
     81     raise value
     82 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<ufunc 'right_shift'>) found for signature:
 
 >>> right_shift(array(uint64, 1d, C), Literal[int](1))
 
There are 5 candidate implementations:
      - Of which 1 did not match due to:
      Overload in function 'Numpy_rules_ufunc.generic': File: numba/core/typing/npydecl.py: Line 96.
        With argument(s): '(array(uint64, 1d, C), int64)':
       Rejected as the implementation raised a specific error:
         TypingError: can't resolve ufunc right_shift for types (array(uint64, 1d, C), int64)
  raised from /Users/nicholasriasanovsky/Documents/bodo/numba/numba/core/typing/npydecl.py:102
      - Of which 1 did not match due to:
      Overload in function 'Numpy_rules_ufunc.generic': File: numba/core/typing/npydecl.py: Line 96.
        With argument(s): '(array(uint64, 1d, C), Literal[int](1))':
       Rejected as the implementation raised a specific error:
         TypingError: can't resolve ufunc right_shift for types (array(uint64, 1d, C), Literal[int](1))
  raised from /Users/nicholasriasanovsky/Documents/bodo/numba/numba/core/typing/npydecl.py:102
      - Of which 3 did not match due to:
      Overload of function 'right_shift': File: <numerous>: Line N/A.
        With argument(s): '(array(uint64, 1d, C), Literal[int](1))':
       No match.

During: resolving callee type: Function(<ufunc 'right_shift'>)
During: typing of call at <ipython-input-55-bf0e79c0242b> (1)


File "<ipython-input-55-bf0e79c0242b>", line 1:
numba.njit(lambda arr: np.right_shift(arr, 1))(arr)
^
```
user: njriasan
issue_6355: state: open
title: NamedTuple type and List
body: ## Reporting a bug
- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

It seem that the `namedtuple` type is determined when creating an instance, which may not be compatible with the type of the existing list of `namedtuple`. Decimal numbers `float46` are also working. but integral types did not. The ordinary `tuple` seem working. 

```python
from __future__ import annotations

import collections

import numba
import numpy as np

print('version', numba.__version__)

# class Node(typing.NamedTuple):
#     count: int
#     index: int

Node = collections.namedtuple('Node', ('count', 'index'))


@numba.njit()
def example(seq):
    nodes = [
        Node(0, 0), # placeholder
    ]
    total = 0

    for count in seq:
        total += count
        nodes.append(Node(count, len(nodes)))

    nodes[0] = Node(total, 0) # this also cause an error because `total` is int32, not shown.

    print(nodes)


print(example(
    np.array(np.arange(10)),
))
```

Output:
```text
version 0.51.2
Traceback (most recent call last):
  File "numba_namedtuple.py", line 33, in <module>
    print(example(
  File "lib\site-packages\numba\core\dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "lib\site-packages\numba\core\dispatcher.py", line 358, in error_rewrite
    reraise(type(e), e, None)
  File "lib\site-packages\numba\core\utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of BoundFunction(list.append for list(Node(int64 x 2))<iv=None>) with parameters (Node(int32, int64))

During: resolving callee type: BoundFunction(list.append for list(Node(int64 x 2))<iv=None>)
During: typing of call at numba_namedtuple.py (26)


File "numba_namedtuple.py", line 26:
def example(seq):
    <source elided>
        total += count
        nodes.append(Node(count, len(nodes)))
        ^

```

user: tsangwpx
issue_6352: state: open
title: CUDA: Local memory kernel launch causes excessive memory allocation
body: First reported on Gitter and in https://numba.discourse.group/t/bug-numba-using-a-lot-of-gpu-memory/255, the following:

```python
import numba as nb
from numba import cuda


@cuda.jit("void(int32[:])", device=True)
def GPU_device_function(arr):
    return


@cuda.jit("void()")
def GPU_entry_point():
    # When this if is removed, it works normally
    if cuda.grid(1):
        return

    # Should use only 256 KB of memory.
    arr = cuda.local.array(shape=65536, dtype=nb.int32)

    # When this assigment is removed, it works normally
    arr[0] = 0

    # When this call is removed, it works normally
    GPU_device_function(arr)

######################


if __name__ == '__main__':
    print(cuda.select_device(0))

    ctx = cuda.current_context()
    print("\nInitial memory info:")
    print(ctx.get_memory_info())

    GPU_entry_point[1, 1]()
    print("\nAfter kernel launch:")
    print(ctx.get_memory_info())

    del GPU_entry_point
    ctx.deallocations.clear()
    print("\nAfter deleting function and clearing deallocations:")
    print(ctx.get_memory_info())

    ctx.reset()
    print("\nAfter resetting context:")
    print(ctx.get_memory_info())

    cuda.driver.driver.reset()
    ctx = cuda.current_context()
    print("\nAfter resetting driver:")
    print(ctx.get_memory_info())
```

produces the following output:

```
$ python repro.py 
<CUDA device 0 'b'Quadro RTX 8000''>

Initial memory info:
MemoryInfo(free=50777096192, total=50962169856)

After kernel launch:
MemoryInfo(free=31525240832, total=50962169856)

After deleting function and clearing deallocations:
MemoryInfo(free=31525240832, total=50962169856)

After resetting context:
MemoryInfo(free=31527337984, total=50962169856)

After resetting driver:
MemoryInfo(free=50779193344, total=50962169856)
```

i.e. launching the kernel consumes a large amount of memory (>18GB in this case). Deleting the function and resetting the context has no effect on the memory usage. The memory is only reclaimed when the driver is reset. The memory usage also correlates with output from `nvidia-smi`:

```
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 455.28       Driver Version: 455.28       CUDA Version: 11.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Quadro RTX 8000     Off  | 00000000:15:00.0 Off |                  Off |
| 33%   30C    P2    64W / 260W |  18534MiB / 48601MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  Quadro P2200        Off  | 00000000:2D:00.0  On |                  N/A |
| 45%   33C    P8     5W /  75W |    370MiB /  5049MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      1091      G   /usr/lib/xorg/Xorg                  4MiB |
|    0   N/A  N/A      2158      G   /usr/lib/xorg/Xorg                  4MiB |
|    0   N/A  N/A     11452      C   python                          18521MiB |
|    1   N/A  N/A      1091      G   /usr/lib/xorg/Xorg                 71MiB |
|    1   N/A  N/A      1695      G   /usr/bin/gnome-shell               54MiB |
|    1   N/A  N/A      2158      G   /usr/lib/xorg/Xorg                188MiB |
|    1   N/A  N/A      2475      G   /usr/lib/firefox/firefox            1MiB |
|    1   N/A  N/A      2480      G   /usr/lib/firefox/firefox           47MiB |
+-----------------------------------------------------------------------------+
```

The debug log confirms that the module is unloaded when the context is reset:

```
$ NUMBA_CUDA_LOG_LEVEL=DEBUG python repro.py 
== CUDA [262]  INFO -- init
== CUDA [262] DEBUG -- call driver api: cuInit(0)
== CUDA [301] DEBUG -- call driver api: cuCtxGetCurrent(<cparam 'P' (0x7f0f0c7a4c90)>)
== CUDA [301] DEBUG -- call driver api: cuDeviceGetCount(<cparam 'P' (0x7f0f0c7a4c90)>)
== CUDA [301] DEBUG -- call driver api: cuDeviceGet(<cparam 'P' (0x7f0f0c7a4c90)>, 0)
== CUDA [301] DEBUG -- call driver api: cuDeviceComputeCapability(<cparam 'P' (0x7f0f0c7a4390)>, <cparam 'P' (0x7f0f0c7a4a10)>, 0)
== CUDA [301] DEBUG -- call driver api: cuDeviceGetName(<numba.cuda.cudadrv.driver.c_char_Array_128 object at 0x7f0f0c7a4940>, 128, 0)
== CUDA [301] DEBUG -- call driver api: cuDeviceGet(<cparam 'P' (0x7f0f0c7a4990)>, 1)
== CUDA [301] DEBUG -- call driver api: cuDeviceComputeCapability(<cparam 'P' (0x7f0f0c7a4c10)>, <cparam 'P' (0x7f0f0c7a4a10)>, 1)
== CUDA [301] DEBUG -- call driver api: cuDeviceGetName(<numba.cuda.cudadrv.driver.c_char_Array_128 object at 0x7f0f0c7a4340>, 128, 1)
== CUDA [301] DEBUG -- call driver api: cuDevicePrimaryCtxRetain(<cparam 'P' (0x7f0f0c7a4390)>, 0)
== CUDA [403] DEBUG -- call driver api: cuCtxPushCurrent_v2(c_void_p(94725512477600))
== CUDA [403] DEBUG -- call driver api: cuMemGetInfo_v2(<cparam 'P' (0x7f0f0c7a4910)>, <cparam 'P' (0x7f0f0c7a4a90)>)
== CUDA [433] DEBUG -- call driver api: cuCtxGetCurrent(<cparam 'P' (0x7f0f04ad8e10)>)
== CUDA [433] DEBUG -- call driver api: cuCtxGetDevice(<cparam 'P' (0x7f0f04ad8f90)>)
== CUDA [433] DEBUG -- call driver api: cuCtxGetCurrent(<cparam 'P' (0x7f0f04ad8e10)>)
== CUDA [433] DEBUG -- call driver api: cuCtxGetDevice(<cparam 'P' (0x7f0f04ad8f90)>)
== CUDA [436] DEBUG -- call runtime api: cudaRuntimeGetVersion
== CUDA [477] DEBUG -- call driver api: cuLinkCreate_v2(6, <numba.cuda.cudadrv.driver.c_int_Array_6 object at 0x7f0f049f4ac0>, <numba.cuda.cudadrv.driver.c_void_p_Array_5 object at 0x7f0f049f44c0>, <cparam 'P' (0x7f0f049f4c10)>)
== CUDA [477] DEBUG -- call driver api: cuLinkAddData_v2(c_void_p(94725521483008), 1, c_char_p(94725522258640), 1471, c_char_p(139702479087040), 0, None, None)
== CUDA [477] DEBUG -- call driver api: cuLinkComplete(c_void_p(94725521483008), <cparam 'P' (0x7f0f0c7a4910)>, <cparam 'P' (0x7f0f0c7a4c90)>)
== CUDA [478] DEBUG -- call driver api: cuModuleLoadDataEx(<cparam 'P' (0x7f0f049f4210)>, c_void_p(94725521446744), 5, <numba.cuda.cudadrv.driver.c_int_Array_5 object at 0x7f0f049f44c0>, <numba.cuda.cudadrv.driver.c_void_p_Array_5 object at 0x7f0f049f4140>)
== CUDA [478] DEBUG -- call driver api: cuModuleGetFunction(<cparam 'P' (0x7f0f04ad8c10)>, c_void_p(94725521453504), b'_ZN6cudapy8__main__19GPU_entry_point$242E')
== CUDA [478] DEBUG -- call driver api: cuFuncGetAttribute(<cparam 'P' (0x7f0f0c7a4c90)>, 4, c_void_p(94725526521360))
== CUDA [478] DEBUG -- call driver api: cuFuncGetAttribute(<cparam 'P' (0x7f0f0c7a4c90)>, 2, c_void_p(94725526521360))
== CUDA [478] DEBUG -- call driver api: cuFuncGetAttribute(<cparam 'P' (0x7f0f0c7a4c90)>, 3, c_void_p(94725526521360))
== CUDA [478] DEBUG -- call driver api: cuFuncGetAttribute(<cparam 'P' (0x7f0f0c7a4c90)>, 1, c_void_p(94725526521360))
== CUDA [478] DEBUG -- call driver api: cuFuncGetAttribute(<cparam 'P' (0x7f0f0c7a4c90)>, 0, c_void_p(94725526521360))
== CUDA [478] DEBUG -- call driver api: cuLinkDestroy(c_void_p(94725521483008))
== CUDA [478] DEBUG -- call driver api: cuCtxPushCurrent_v2(c_void_p(94725512477600))
<CUDA device 0 'b'Quadro RTX 8000''>
== CUDA [478] DEBUG -- call driver api: cuCtxGetCurrent(<cparam 'P' (0x7f0f04ad8f90)>)
== CUDA [478] DEBUG -- call driver api: cuCtxGetDevice(<cparam 'P' (0x7f0f04ad8e10)>)

Initial memory info:
== CUDA [479] DEBUG -- call driver api: cuMemGetInfo_v2(<cparam 'P' (0x7f0f04ad8f90)>, <cparam 'P' (0x7f0f04ad8e10)>)
MemoryInfo(free=50777096192, total=50962169856)
== CUDA [479] DEBUG -- call driver api: cuCtxGetCurrent(<cparam 'P' (0x7f0f04ad8e10)>)
== CUDA [479] DEBUG -- call driver api: cuCtxGetDevice(<cparam 'P' (0x7f0f04ad8f90)>)
== CUDA [479] DEBUG -- call driver api: cuCtxGetCurrent(<cparam 'P' (0x7f0f04ad8e10)>)
== CUDA [479] DEBUG -- call driver api: cuCtxGetDevice(<cparam 'P' (0x7f0f04ad8f90)>)
== CUDA [479] DEBUG -- call driver api: cuLaunchKernel(c_void_p(94725526521360), 1, 1, 1, 1, 1, 1, 0, None, <numba.cuda.cudadrv.driver.c_void_p_Array_0 object at 0x7f0f04ad8f40>, None)

After kernel launch:
== CUDA [498] DEBUG -- call driver api: cuMemGetInfo_v2(<cparam 'P' (0x7f0f04ad8f90)>, <cparam 'P' (0x7f0f0c7a4790)>)
MemoryInfo(free=31525240832, total=50962169856)

After deleting function and clearing deallocations:
== CUDA [498] DEBUG -- call driver api: cuMemGetInfo_v2(<cparam 'P' (0x7f0f04ad8c10)>, <cparam 'P' (0x7f0f04ad8d10)>)
MemoryInfo(free=31525240832, total=50962169856)
== CUDA [498]  INFO -- reset context of device 0
== CUDA [498]  INFO -- add pending dealloc: module_unload ? bytes
== CUDA [498]  INFO -- dealloc: module_unload ? bytes
== CUDA [498] DEBUG -- call driver api: cuModuleUnload(c_void_p(94725521453504))

After resetting context:
== CUDA [501] DEBUG -- call driver api: cuMemGetInfo_v2(<cparam 'P' (0x7f0f04ad8d10)>, <cparam 'P' (0x7f0f04ad8c10)>)
MemoryInfo(free=31527337984, total=50962169856)
== CUDA [501]  INFO -- reset context of device 0
== CUDA [502] DEBUG -- call driver api: cuDevicePrimaryCtxRelease_v2(0)
== CUDA [592] DEBUG -- call driver api: cuDevicePrimaryCtxReset_v2(0)
== CUDA [592] DEBUG -- call driver api: cuDevicePrimaryCtxReset_v2(1)
== CUDA [592] DEBUG -- call driver api: cuCtxGetCurrent(<cparam 'P' (0x7f0f04ad8c10)>)
== CUDA [592] DEBUG -- call driver api: cuCtxGetDevice(<cparam 'P' (0x7f0f04ad8d10)>)
== CUDA [592] DEBUG -- call driver api: cuDevicePrimaryCtxRetain(<cparam 'P' (0x7f0f04ad8d10)>, 0)
== CUDA [715] DEBUG -- call driver api: cuMemGetInfo_v2(<cparam 'P' (0x7f0f04ad8c90)>, <cparam 'P' (0x7f0f04ad8f90)>)

After resetting driver:
== CUDA [715] DEBUG -- call driver api: cuMemGetInfo_v2(<cparam 'P' (0x7f0f04ad8c10)>, <cparam 'P' (0x7f0f04ad8f90)>)
MemoryInfo(free=50779193344, total=50962169856)
```
The PTX looks odd: it appears that all threads will write `0` to every element of the local array when executed:

```assembly
.version 7.0
.target sm_75
.address_size 64

	// .globl	_ZN6cudapy8__main__19GPU_entry_point$242E
.visible .global .align 4 .u32 _ZN6cudapy8__main__19GPU_entry_point$242E__errcode__;
.visible .global .align 4 .u32 _ZN6cudapy8__main__19GPU_entry_point$242E__tidx__;
.visible .global .align 4 .u32 _ZN6cudapy8__main__19GPU_entry_point$242E__ctaidx__;
.visible .global .align 4 .u32 _ZN6cudapy8__main__19GPU_entry_point$242E__tidy__;
.visible .global .align 4 .u32 _ZN6cudapy8__main__19GPU_entry_point$242E__ctaidy__;
.visible .global .align 4 .u32 _ZN6cudapy8__main__19GPU_entry_point$242E__tidz__;
.visible .global .align 4 .u32 _ZN6cudapy8__main__19GPU_entry_point$242E__ctaidz__;
.common .global .align 8 .u64 _ZN08NumbaEnv8__main__19GPU_entry_point$242E;
.common .global .align 8 .u64 _ZN08NumbaEnv8__main__23GPU_device_function$241E5ArrayIiLi1E1A7mutable7alignedE;

.visible .entry _ZN6cudapy8__main__19GPU_entry_point$242E(

)
{
	.local .align 16 .b8 	__local_depot0[262144];
	.reg .b64 	%SP;
	.reg .b64 	%SPL;
	.reg .pred 	%p<2>;
	.reg .b32 	%r<6>;
	.reg .b64 	%rd<6>;


	mov.u64 	%SPL, __local_depot0;
	add.u64 	%rd5, %SPL, 0;
	mov.u32 	%r3, 0;
	mov.u32 	%r5, %r3;

BB0_1:
	st.local.u32 	[%rd5], %r3;
	add.s64 	%rd5, %rd5, 4;
	add.s32 	%r5, %r5, 1;
	setp.lt.u32	%p1, %r5, 65536;
	@%p1 bra 	BB0_1;

	ret;
}
```
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_6347: state: open
title: numba causing periodic process stalls
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

## summary
I've been trying to diagnose periodic process stalls (~20ms stall every 5, 10, or 20 seconds) in my async, CPU-intensive, single-threaded app.  It seems to be induced simply by `import numba`, without any use of numba beyond that.  I also observed that this import creates several persistent child threads (even with `NUMBA_NUM_THREADS=1`, if that is relevant).

I observed that when the process CPU per `top` is < 50%, the stalls do not occur.  And when CPU is > 70%, the periodic stalls clearly occur.  Setting realtime SCHED_FIFO priority on all threads of the process (the app's lone main thread and all the numba child threads) has no effect.

## reproducing
I'm able to reproduce it with a simple async task loop, but so far with the lesser-known Trio async framework.  I haven't been successful  reproducing with asyncio, nor a non-async loop.

```python3
import numba
import trio

async def _run():
    T = .000015
    t_start = trio.current_time()

    while True:
        t0 = trio.current_time()
        await trio.sleep(T)
        delta = trio.current_time() - t0
        if delta > .005:
            elapsed = trio.current_time() - t_start
            print(f'{(elapsed) // 60:02.0f}:{elapsed % 60:02.0f}  {delta * 1000:5.1f}')

trio.run(_run)
```

On my machine, the small period used (15 usec) incurs 100% CPU use on the process, which is significant for inducing the problem.

output (timestamp, stall in ms):
```
00:00   14.8
00:10   20.0
00:19   17.8
00:29   17.0
00:38   17.8
00:48   18.2
00:57   22.1
```

## system info
python version: 3.7.2
numba version: 0.51.2
machine:  Linux / amd64, Intel i5
```
CPU(s):                8
Thread(s) per core:    2
Core(s) per socket:    4
```
user: belm0
labels: performance: performance related issue
issue_6344: state: open
title: literal_unroll doesn't seem to handle a list - yields unknown problem.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

With a constant list, I attempted to use literal_unroll, but got an 'unknown problem.' This looks pretty daggone close to the samples, not sure where it goes wrong.
```

import numba as nb
from numba import cuda, literal_unroll
import numpy as np

ret = np.ndarray(5)
ret[:] = 0

magic_numbers = list(range(5))

@cuda.jit
def f(result):
    for i in literal_unroll(magic_numbers):
        result[0] += i

f[1,1](ret)
print(ret)
```

user: c200chromebook
labels: CUDA: CUDA related issue/PR
bug - failure to compile: Bugs: failed to compile valid code
issue_6328: state: open
title: Support for Unified (Managed) Memory in the EMM Plugin interface
body: Support for Unified (managed) memory was added in #5900.

The EMM plugin interface presently makes no mention of managed memory, but the `HostOnlyCUDAMemoryManager` provides a `memallocmanaged` method, so anyone implementing an EMM plugin based on it will preserve the ability for managed memory to be allocated. For EMM plugins that manage host and device memory, the `memallocmanaged` method would need to be implemented by the plugin to enable the allocation of managed memory, but the interface doesn't currently enforce this.

The distinction between "host memory" and "device memory" is a little ambiguous with managed memory - changes to the design of the EMM plugin interface may require some thought taking this into account.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_6327: state: open
title: Provide method to attach managed memory to a stream
body: Unified (Managed) memory support was added in #5900.

On Windows systems, and Linux systems with pre-6.0 compute capability GPUs, managed memory allocated with `attach_global=False` can't easily be used from a GPU, because there is no interface for attaching it to particular streams (see [the cuMemallocManaged docs](https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__MEM.html#group__CUDA__MEM_1gb347ded34dc326af404aa02af5388a32) for details on the requirements). A Python-level wrapper for attaching managed memory to a given stream with [cuStreamAttachMemAsync](https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__STREAM.html#group__CUDA__STREAM_1g6e468d680e263e7eba02a56643c50533) is required for this.

It is expected that most users will use `attach_global=True` - this issue tracks the requirement in case it becomes a priority.

(cc @maxpkatz)
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_6320: state: open
title: Symbol not found: _do_scheduling_unsigned 
body: If I import the following, it compiles to the expected .so file on Mac OS X 10.15.5:

```
import numba as nb
from numba.pycc import CC

cc = CC('t1')


@nb.njit(parallel=True)
@cc.export('diff', '(f4[:], i8)')
def diff(buffer, half_buffer_size):
    for tau in nb.prange(half_buffer_size):
        buffer[tau] = 0


@nb.njit
@cc.export('test', '(f4[:], i8)')
def test(buffer, half_buffer_size):
    diff(buffer, half_buffer_size)

cc.compile()
```
Having compiled the file, if I then run the script which imports t1 again, I get the following error:

Traceback (most recent call last):
  File "/Users/me/PycharmProjects/t1/main.py", line 2, in <module>
    import t1
ImportError: dlopen(/Users/me/PycharmProjects/t1/t1.cpython-38-darwin.so, 2): Symbol not found: _do_scheduling_unsigned
  Referenced from: /Users/me/PycharmProjects/t1/t1.cpython-38-darwin.so
  Expected in: flat namespace
 in /Users/me/PycharmProjects/t1/t1.cpython-38-darwin.so
This seems to be a result of calling diff from within test. If I comment out this call and compile again, I can call diff directly from main.py without any issue. 

numba 51.2

user: barraog
labels: AOT: ahead of time compilation issue
bug - incorrect behavior: Bugs: incorrect behavior
issue_6314: state: open
title: functools.reduce doesn't work with numpy functions in parallel accelerator
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [*] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ *] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I am trying to run the below code which use reduce from functools (numba websites indicates it supports reduce from functools)

```python
import numpy as np
import functools as ft
from numba import jit, prange

@jit(nopython=True)
def list_gcd(L):
    return ft.reduce(np.gcd, L, 0)

A = np.array(list(range(0, 10, 2)))
list_gcd(A)
```


However, I get the error 

`No definition for lowering <built-in function reduce>(Function(<ufunc 'gcd'>), array(int64, 1d, C), Literal[int](0)) -> int64`



Below is the full error

<details>
```python
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
~/opt/anaconda3/lib/python3.8/site-packages/numba/core/errors.py in new_error_context(fmt_, *args, **kwargs)
    744     try:
--> 745         yield
    746     except NumbaError as e:

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_block(self, block)
    272                                    loc=self.loc, errcls_=defaulterrcls):
--> 273                 self.lower_inst(inst)
    274         self.post_block(block)

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_inst(self, inst)
    369             ty = self.typeof(inst.target.name)
--> 370             val = self.lower_assign(ty, inst)
    371             self.storevar(val, inst.target.name)

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_assign(self, ty, inst)
    543         elif isinstance(value, ir.Expr):
--> 544             return self.lower_expr(ty, value)
    545 

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_expr(self, resty, expr)
   1069         elif expr.op == 'call':
-> 1070             res = self.lower_call(resty, expr)
   1071             return res

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_call(self, resty, expr)
    805         else:
--> 806             res = self._lower_call_normal(fnty, expr, signature)
    807 

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in _lower_call_normal(self, fnty, expr, signature)
   1032             )
-> 1033         impl = self.context.get_function(fnty, signature)
   1034         if signature.recvr:

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/base.py in get_function(self, fn, sig, _firstcall)
    569             self.refresh()
--> 570             return self.get_function(fn, sig, _firstcall=False)
    571 

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/base.py in get_function(self, fn, sig, _firstcall)
    571 
--> 572         raise NotImplementedError("No definition for lowering %s%s" % (key, sig))
    573 

NotImplementedError: No definition for lowering <built-in function reduce>(Function(<ufunc 'gcd'>), array(int64, 1d, C), Literal[int](0)) -> int64

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-38-9cbfe228bf0e> in <module>
     23 
     24 A = np.array(list(range(0, 10, 2)))
---> 25 list_gcd(A)
     26 
     27 ft.reduce(np.gcd, A, 0)

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    432                     e.patch_message('\n'.join((str(e).rstrip(), help_msg)))
    433             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 434             raise e
    435 
    436     def inspect_llvm(self, signature=None):

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py in _compile_for_args(self, *args, **kws)
    365                 argtypes.append(self.typeof_pyval(a))
    366         try:
--> 367             return self.compile(tuple(argtypes))
    368         except errors.ForceLiteralArg as e:
    369             # Received request for compiler re-entry with the list of arguments

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py in compile(self, sig)
    806             self._cache_misses[sig] += 1
    807             try:
--> 808                 cres = self._compiler.compile(args, return_type)
    809             except errors.ForceLiteralArg as e:
    810                 def folded(args, kws):

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py in compile(self, args, return_type)
     76 
     77     def compile(self, args, return_type):
---> 78         status, retval = self._compile_cached(args, return_type)
     79         if status:
     80             return retval

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py in _compile_cached(self, args, return_type)
     90 
     91         try:
---> 92             retval = self._compile_core(args, return_type)
     93         except errors.TypingError as e:
     94             self._failed_cache[key] = e

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/dispatcher.py in _compile_core(self, args, return_type)
    103 
    104         impl = self._get_implementation(args, {})
--> 105         cres = compiler.compile_extra(self.targetdescr.typing_context,
    106                                       self.targetdescr.target_context,
    107                                       impl,

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    601     pipeline = pipeline_class(typingctx, targetctx, library,
    602                               args, return_type, flags, locals)
--> 603     return pipeline.compile_extra(func)
    604 
    605 

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler.py in compile_extra(self, func)
    337         self.state.lifted = ()
    338         self.state.lifted_from = None
--> 339         return self._compile_bytecode()
    340 
    341     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler.py in _compile_bytecode(self)
    399         """
    400         assert self.state.func_ir is None
--> 401         return self._compile_core()
    402 
    403     def _compile_ir(self):

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler.py in _compile_core(self)
    379                 self.state.status.fail_reason = e
    380                 if is_final_pipeline:
--> 381                     raise e
    382         else:
    383             raise CompilerError("All available pipelines exhausted")

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler.py in _compile_core(self)
    370             res = None
    371             try:
--> 372                 pm.run(self.state)
    373                 if self.state.cr is not None:
    374                     break

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py in run(self, state)
    339                     (self.pipeline_name, pass_desc)
    340                 patched_exception = self._patch_error(msg, e)
--> 341                 raise patched_exception
    342 
    343     def dependency_analysis(self):

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py in run(self, state)
    330                 pass_inst = _pass_registry.get(pss).pass_inst
    331                 if isinstance(pass_inst, CompilerPass):
--> 332                     self._runPass(idx, pass_inst, state)
    333                 else:
    334                     raise BaseException("Legacy pass in use")

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py in _runPass(self, index, pss, internal_state)
    289             mutated |= check(pss.run_initialization, internal_state)
    290         with SimpleTimer() as pass_time:
--> 291             mutated |= check(pss.run_pass, internal_state)
    292         with SimpleTimer() as finalize_time:
    293             mutated |= check(pss.run_finalizer, internal_state)

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/compiler_machinery.py in check(func, compiler_state)
    262 
    263         def check(func, compiler_state):
--> 264             mangled = func(compiler_state)
    265             if mangled not in (True, False):
    266                 msg = ("CompilerPass implementations should return True/False. "

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/typed_passes.py in run_pass(self, state)
    440 
    441         # TODO: Pull this out into the pipeline
--> 442         NativeLowering().run_pass(state)
    443         lowered = state['cr']
    444         signature = typing.signature(state.return_type, *state.args)

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/typed_passes.py in run_pass(self, state)
    368                 lower = lowering.Lower(targetctx, library, fndesc, interp,
    369                                        metadata=metadata)
--> 370                 lower.lower()
    371                 if not flags.no_cpython_wrapper:
    372                     lower.create_cpython_wrapper(flags.release_gil)

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower(self)
    177         if self.generator_info is None:
    178             self.genlower = None
--> 179             self.lower_normal_function(self.fndesc)
    180         else:
    181             self.genlower = self.GeneratorLower(self)

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_normal_function(self, fndesc)
    231         # Init argument values
    232         self.extract_function_arguments()
--> 233         entry_block_tail = self.lower_function_body()
    234 
    235         # Close tail of entry block

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_function_body(self)
    257             bb = self.blkmap[offset]
    258             self.builder.position_at_end(bb)
--> 259             self.lower_block(block)
    260         self.post_lower()
    261         return entry_block_tail

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/lowering.py in lower_block(self, block)
    271             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    272                                    loc=self.loc, errcls_=defaulterrcls):
--> 273                 self.lower_inst(inst)
    274         self.post_block(block)
    275 

~/opt/anaconda3/lib/python3.8/contextlib.py in __exit__(self, type, value, traceback)
    129                 value = type()
    130             try:
--> 131                 self.gen.throw(type, value, traceback)
    132             except StopIteration as exc:
    133                 # Suppress StopIteration *unless* it's the same exception that

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/errors.py in new_error_context(fmt_, *args, **kwargs)
    750         newerr = errcls(e).add_context(_format_msg(fmt_, args, kwargs))
    751         tb = sys.exc_info()[2] if numba.core.config.FULL_TRACEBACKS else None
--> 752         reraise(type(newerr), newerr, tb)
    753 
    754 

~/opt/anaconda3/lib/python3.8/site-packages/numba/core/utils.py in reraise(tp, value, tb)
     79     if value.__traceback__ is not tb:
     80         raise value.with_traceback(tb)
---> 81     raise value
     82 
     83 

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
No definition for lowering <built-in function reduce>(Function(<ufunc 'gcd'>), array(int64, 1d, C), Literal[int](0)) -> int64

File "<ipython-input-38-9cbfe228bf0e>", line 17:
def list_gcd(L):
    return ft.reduce(np.gcd, L, 0)
    ^

During: lowering "$14call_method.6 = call $4load_method.1($8load_attr.3, L, $const12.5, func=$4load_method.1, args=[Var($8load_attr.3, <ipython-input-38-9cbfe228bf0e>:17), Var(L, <ipython-input-38-9cbfe228bf0e>:17), Var($const12.5, <ipython-input-38-9cbfe228bf0e>:17)], kws=(), vararg=None)" at <ipython-input-38-9cbfe228bf0e> (17)
```

</details>
user: akaalharbi
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_6313: state: open
title: [Request] Implement numpy.ufunc.METHOD
body: ## Feature request

There are 5 method for ufuncs that allows in place operations, which could implement in lower level uniformly instead of overwriting one by one. `ufunc.at` and `ufunc.reduce` (https://github.com/numba/numba/issues/2751) are quite welcome.

1. [`ufunc.accumulate`](https://numpy.org/doc/stable/reference/generated/numpy.ufunc.accumulate.html)
2. [`ufunc.at`](https://numpy.org/doc/stable/reference/generated/numpy.ufunc.at.html)
3. [`ufunc.reduce`](https://numpy.org/doc/stable/reference/generated/numpy.ufunc.reduce.html)
4. [`ufunc.reduceat`](https://numpy.org/doc/stable/reference/generated/numpy.ufunc.reduceat.html)
5. [`ufunc.outer`](https://numpy.org/doc/stable/reference/generated/numpy.ufunc.outer.html)



user: holymonson
issue_6312: state: open
title: Equality check between numpy string array and string element fails
body: Hi. I encountered a situation where comparing a Numpy array of strings with a single string doesn't perform element wise comparison and doesn't match the Numpy results. Here is a reproducer:

```python
# Create the array in python 
a = np.array(["hello", "world"])

# Run in normal Numpy
print(a == "world")

# Run in numba nit
print(numba.njit(lambda a: a == "world")(a))
```

Running this example produces the output:

```python
[False  True]
False
```

It seems like numba is only performing the comparison between the entire array and the single element and is not doing an element wise comparison.
user: njriasan
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6311: state: open
title: Support subclass from a jitclass
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

Hi, is it possible to support inheritance between `jitclass` classes? Below is a simple example with current error output:
![IMG_20201007_023042_409](https://user-images.githubusercontent.com/5438682/95270870-21eedd00-0845-11eb-8593-af8b05d4b352.jpg)


user: mishana
issue_6288: state: open
title: Strange behavior with the mean() function
body: Below is a simple example function which uses np.mean()

@numba.njit
def frame_mean(frame):
    return frame.mean()

When I input float32 ndarray with a shape of (6000,8000), it always returns 44.739243 which is exactly 2147483664.0/6000/8000
The problem persists even with the proper type signature and I cannot fathom how this happens when everything is designated as floating point. Is there some hard coded integer summation? This function works correctly with float64. 
user: FakiZun
issue_6286: state: open
title: Add np.allclose and np.isclose support ref. issue #4074
body: Hi everyone,

As proposed in issue #4074, I added support for the np.allclose function.

I also wrote unit test. One of them could be enhanced (about checking data type) but support to numpy.issubdtype(a, b) should be first brought. Anyway, I think that the function works quite as expected.

If I made any mistake or forgot anything, don't hesitate :)

If you think the implementation is correct, I can easily implement the numpy.isclose function.

I timed the function and it seems to work pretty well:
```python
a = np.random.rand(100, 100)
np.allclose(a, a)
>>> True
allclose(a, a)
>>> True
%timeit allclose(a, a)
>>> 10.9 µs ± 31.4 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
%timeit np.allclose(a, a)
>>> 59.4 µs ± 221 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```

user: jeertmans
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_6284: state: open
title: Prevent cache busting by the UUID of Dispatcher
body: First steps towards fixing #6264.

This PR changes the cache key to explicitly include the bytecode of python functions captured in closures, and also their transitive dependencies. Before, the whole `Dispatcher` object was pickled and included in the key, which changes for each "run" (i.e. each time a new python interpreter is started) because of the UUID.

I'm not sure if this is enough, or if other attributes of the `Dispatcher` objects also need to be included in the key.

As @sklam noted in the issue, the referenced functions may also need to be cached (except if they are inlined?), but I'm not sure what the best approach would be, or if the user should be required to explicitly mark them to be cached.

Please let me know if this goes into the right direction, thanks!

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
mailing list https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: sk1p
issue_6273: state: open
title: Numba np.zeros giving incorrect result and wierd behavior
body: I am using numpy structured dtype for some tasks and came across this wierd bug:
```
import numpy as np
from numba import njit

custom_type = np.dtype([("a", np.int32),("b",np.int32)])
@njit
def get_zero():
    z = np.zeros(1, dtype=custom_type)[0]
    return z

print("output: {}".format(get_zero()))
```
this prints
`output: (-555819298, -555819298)`
expected output
`output: (0,0)`

On further playing with this, it seems like a early memory free type of bug. I think numba is somehow freeing up the memory allocated by `np.zeros` prematurely. This is an alternative code to show that:
```
import numpy as np
from numba import njit

custom_type = np.dtype([("a", np.int32),("b",np.int32)])
@njit
def get_zero_int():
    x = np.zeros(1, dtype=custom_type)
    y = x[0]["a"]
    z = x[0]["a"] # if you comment this line, then the output will magically become garbage
    return y

print("output: {}".format(get_zero_int()))
```
on running as it is, this prints
`output: 0`
but on commenting the said line and running, this prints:
`output: -555819298`

This leads me to believe that keeping the `z = x[0]["a"]` line somehow prevents numba from freeing the memory early, but I'm not sure.

Used versions:
python: 3.7.6
numpy: 1.18.1
numba: 0.48.0
user: ozym4nd145
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6270: state: open
title: `is_serialiable` raises `TypeError` on Python 3.8+
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

On Python 3.8+ (or when `pickle5` is installed) `core.serialize.FastNumbaPickler` is used. When encountering `_nrt_python._MemInfo` `FastNumbaPickler` raises `TypeError` while before Python 3.8 (using `core.serialize.SlowNumbaPickler`) a `PicklingError` was raised. Only `PicklingError` is handled in `core.serialize.is_serialiable` ([here](https://github.com/numba/numba/blob/3b3eab8922c9ca199fc3b2c758886628a2ab7494/numba/core/serialize.py#L268))
hence the code below raises `TypeError` on Python 3.8+ and returns `False` on Python<3.8:
```python
import numba
d = numba.typed.Dict()
d[1] = 1
assert not numba.core.serialize.is_serialiable(d)  # raises TypeError on Python>=3.8 or when pickle5 is installed
```
Not sure if the adequate fix is handling the `TypeError` in `is_serialiable` or making `FastNumbaPickler` raise `PicklingError`.

user: asodeur
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_6264: state: open
title: Caching: functions captured in closure
body: ## Feature request

I would like to capture functions in closures and be able to cache the compilation.  Currently, running the following code results in re-compilation on each run (that is, when starting in a new Python interpreter):

```python
import numpy as np
import numba


@numba.njit
def f1(in_arr):
    return in_arr * 2


def compose(fn):
    @numba.njit(cache=True)
    def _inner_fn(arr):
        return fn(arr)
    return _inner_fn


composed = compose(f1)
composed(np.ones((128, 128)))
```

Each time, a new version of `composed` is saved in `__pycache__`. This is caused by the UUID that is part of the `Dispatcher` - when looking at [`cvarbytes`](https://github.com/numba/numba/blob/3b3eab8922c9ca199fc3b2c758886628a2ab7494/numba/core/caching.py#L704), only the UUID differs between runs.

As a proof of concept, the following hack for `Cache._index_key` makes the `compose` consistently cache-able:

```diff
diff --git a/numba/core/caching.py b/numba/core/caching.py
index 45f82f314..f4f766790 100644
--- a/numba/core/caching.py
+++ b/numba/core/caching.py
@@ -701,11 +701,17 @@ class Cache(_Cache):
         codebytes = self._py_func.__code__.co_code
         if self._py_func.__closure__ is not None:
             cvars = tuple([x.cell_contents for x in self._py_func.__closure__])
+            cvars = tuple(var.__code__.co_code if hasattr(var, '__code__') else var
+                          for var in cvars)
             cvarbytes = dumps(cvars)
         else:
             cvarbytes = b''
 
         hasher = lambda x: hashlib.sha256(x).hexdigest()
         return (sig, codegen.magic_tuple(), (hasher(codebytes),
                                              hasher(cvarbytes),))
```

Implementing this as-is doesn't invalidate the cache in all cases, for example if there are multiple levels of closures. Maybe there is an easier and/or better way? Thanks!
user: sk1p
labels: caching: Issue involving caching
issue_6256: state: open
title: guvectorize in-place operations work only in some cases
body: The following works, which is good (numba 0.51.2, llvmlite 0.34.0):

`guvectorized` function writing to the output, on GPU
```python
@guvectorize(["(f8[:], f8[:])"], "() -> ()", target='cuda')
def test(inp, out):
    out[0] = inp[0]
```
feeding in device arrays: :heavy_check_mark:
```python
ones = np.ones(10, dtype=np.float64)
twos = np.ones_like(ones) * 2
ones_d = numba.cuda.to_device(ones)
twos_d = numba.cuda.to_device(twos)

test(ones_d, out=twos_d)
twos_d.copy_to_host()

>>> array([1., 1., 1., 1., 1., 1., 1., 1., 1., 1.])
```
feeding in host arrays: :heavy_check_mark:
```python
ones = np.ones(10, dtype=np.float64)
twos = np.ones_like(ones) * 2

test(ones, out=twos)
twos

>>> array([1., 1., 1., 1., 1., 1., 1., 1., 1., 1.])
```

`guvectorized` function modifying the output, on GPU
```python
@guvectorize(["(f8[:], f8[:])"], "() -> ()", target='cuda')
def inplace_test(inp, out):
    out[0] += inp[0]    
```
feeding in device arrays: :heavy_check_mark:
```python
ones = np.ones(10, dtype=np.float64)
twos = np.ones_like(ones) * 2
ones_d = numba.cuda.to_device(ones)
twos_d = numba.cuda.to_device(twos)

inplace_test(ones_d, out=twos_d)
twos_d.copy_to_host()

>>> array([3., 3., 3., 3., 3., 3., 3., 3., 3., 3.])
```

**But this does not work:**

feeding in host arrays: :x:
```python
ones = np.ones(10, dtype=np.float64)
twos = np.ones_like(ones) * 2

inplace_test(ones, out=twos)
twos

>>> array([2., 2., 2., 2., 2., 2., 2., 2., 2., 2.])
```

the output host array contains just something.... :man_shrugging:
user: philippeller
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_6253: state: open
title: Recompilation of bound methods templates due to omitted args in signature
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Hi, we recently found that compilation time of some SDC methods can be decreased by eliminating recompilation of function templates that have default arguments in signature. It seems that during the first compilation (which occurs during type-inference) the cache_key uses args that do not refer to default values (i.e. `args=(Dummy, int64, int64)`), and during the second compilation (which occurs during lowering of 'test_impl$1' func) args are different and include omitted types (i.e. `args=(Dummy, int64, int64, omitted(default=None))`) so cache miss occurs in 
https://github.com/numba/numba/blob/c448052c875d7a84e8d067f8483a1a1caa1dfe9b/numba/core/typing/templates.py#L675-L680

Here's the reproducer:
```
import numba
from numba.core import types, cgutils
from numba.extending import (
    models,
    lower_builtin,
    register_model,
    make_attribute_wrapper,
    type_callable,
    typeof_impl,
    overload_method
)

def make_dummy_type():
    class Dummy(object):
        def __init__(self, value):
            self.value = value

    class DummyType(types.Type):
        def __init__(self):
            super(DummyType, self).__init__(name="Dummy")

    dummy_type = DummyType()

    @register_model(DummyType)
    class DummyModel(models.StructModel):
        def __init__(self, dmm, fe_type):
            members = [("value", types.intp)]
            models.StructModel.__init__(self, dmm, fe_type, members)

    make_attribute_wrapper(DummyType, "value", "value")

    @type_callable(Dummy)
    def type_dummy(context):
        def typer(value):
            return dummy_type

        return typer

    @lower_builtin(Dummy, types.intp)
    def impl_dummy(context, builder, sig, args):
        typ = sig.return_type
        [value] = args
        dummy = cgutils.create_struct_proxy(typ)(context, builder)
        dummy.value = value
        return dummy._getvalue()

    @typeof_impl.register(Dummy)
    def typeof_dummy(val, c):
        return DummyType()

    # Store attributes
    return Dummy, DummyType


Dummy, DummyType = make_dummy_type()


@overload_method(DummyType, 'foo')
def dummy_foo_ovld(self, a, b, c=None):
    def dummy_foo_impl(self, a, b, c=None):
        if c is None:
            return 42
        else:
            return a + b

    return dummy_foo_impl

@numba.njit
def test_impl():
    d = Dummy(1)
    return d.foo(1, 2)

print(test_impl())
```

The issue can be verified by two entries in LLVM dump for dummy_foo:
> 	Line 7: @"_ZN08NumbaEnv8__main__14dummy_foo_ovld12$3clocals$3e18dummy_foo_impl$242E5Dummyxx27omitted$28default$3dNone$29" = common global i8* null
> 	Line 92: @"_ZN08NumbaEnv8__main__14dummy_foo_ovld12$3clocals$3e18dummy_foo_impl$243E5Dummyxx27omitted$28default$3dNone$29" = common global i8* null

or via following traces in `_get_impl()`:
> DEBUG: cache miss for <OverloadTemplate_dummy_foo_ovld test_issue.1.py:58>, args=(Dummy, int64, int64)
> DEBUG: cache miss for <OverloadTemplate_dummy_foo_ovld test_issue.1.py:58>, args=(Dummy, int64, int64, omitted(default=None))

Debugging that further I found that `_build_impl()` actually does not use the signature it got from the first compilation (and this signature contains proper folded args), here: 
https://github.com/numba/numba/blob/c448052c875d7a84e8d067f8483a1a1caa1dfe9b/numba/core/typing/templates.py#L740-L742

So while the new signature was returned by `get_call_type` the cache_key used to add a new dispatcher still refers to the old args. If new cache_key is defined and both entries are added to impl_cache, so that we have:
>>> self._impl_cache
> {(<numba.core.typing.context.Context object at 0x00000209A2ED3AF0>, (Dummy, int64, int64), ()): (CPUDispatcher(<function dummy_foo_ovld.<locals>.dummy_foo_impl at 0x00000209A4889670>), (Dummy, int64, int64)),
>  (<numba.core.typing.context.Context object at 0x00000209A2ED3AF0>, (Dummy, int64, int64, omitted(default=None)), ()): (CPUDispatcher(<function dummy_foo_ovld.<locals>.dummy_foo_impl at 0x00000209A4889670>), (Dummy, int64, int64))}
> 

the issue with recompilation seems to be solved, but I'm not sure that's a proper fix for it. Numba version: 0.52.0.dev0+132.g850a01561

BR,
Alexey.
user: kozlov-alexey
labels: performance - compile time: Performance issue occurring at compile time.
issue_6249: state: open
title: LoweringError assigning array to `.real` part of NumPy array
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

From: https://gitter.im/numba/numba?at=5f620a11ce5bbc7ffdcb4da9

This:
```python
from numba import njit
import numpy as np

@njit
def foo(input_tensor):
    complex_input = np.empty(input_tensor.shape[-1:], dtype=np.complex128)
    complex_input.real = input_tensor[0]
    complex_input.imag = input_tensor[1]

foo(np.empty((3, 2)))
```
does this:
```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
No definition for lowering array(complex128, 1d, C).real = array(float64, 1d, A)

File "gi286.py", line 7:
def foo(input_tensor):
    <source elided>
    complex_input = np.empty(input_tensor.shape[-1:], dtype=np.complex128)
    complex_input.real = input_tensor[0]
    ^
```
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6242: state: open
title: Invalid incref pruning when passing meminfo to C++
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
We have a wrapper intrinsic like below that wraps a `meminfo` to pass to C++. In increases the refcount since the C++ code keeps a reference. However, the refcount pruning pass removes this `incref`. We have a workaround for now (the output of the C++ call is used in other dummy calls) so it's not urgent, but the upcoming refcount pruning pass should consider cases like this. Maybe there should be a flag saying this `incref` shouldn't be removed?
```python
@intrinsic
def wrap_array_for_cpp(typingctx, arr_type_t):
    def codegen(context, builder, sig, args):
        (in_arr,) = args
        context.nrt.incref(builder, arr_type, in_arr)
        # pass meminfo to C++ extension which keeps a reference
...
```
user: ehsantn
issue_6237: state: open
title: allow numba cuda vectorize to transmit scalar arguments as scalars, rather than creating temporary array
body: Regarding a numba cuda vectorize function,  if I pass for arguments,  all arrays of the same size, then I can get expected behavior, but if I pass some arrays and some scalars, it appears that under the hood, numba is converting my scalars into arrays, for use by the vectorize function.  Is there any way to pass these scalars as scalars to the underlying kernel launch, eliminating the resultant CUDA memcpy HtoD operations?  Example:

```$ cat t38.py
import numpy as np
from numba import jit
from numba import vectorize
from numba import cuda
N=32
data = np.ones((N,N), dtype = np.int32)
@cuda.jit(device=True)
def dev_op(a,b,c):
    return a*b+c
@vectorize(['int32(int32,int32,int32)'], target='cuda')
def vec_op(a,b,c):
    return dev_op(a,b,c)
def method(a,b,c):
    out_a = cuda.device_array_like(a)
    dev_a = cuda.to_device(a)
    for i in range(2):
      vec_op(dev_a,b,c, out = out_a)
    return out_a.copy_to_host()
result = method(data, np.int32(1), np.int32(1))
$ nvprof --print-gpu-trace python t38.py
==13728== NVPROF is profiling process 13728, command: python t38.py
==13728== Profiling application: python t38.py
==13728== Profiling result:
   Start  Duration            Grid Size      Block Size     Regs*    SSMem*    DSMem*      Size  Throughput  SrcMemType  DstMemType           Device   Context    Stream  Name
313.81ms  1.6320us                    -               -         -         -         -  4.0000KB  2.3374GB/s    Pageable      Device  GeForce GTX 960         1         7  [CUDA memcpy HtoD]
315.07ms  1.4720us                    -               -         -         -         -  4.0000KB  2.5915GB/s    Pageable      Device  GeForce GTX 960         1         7  [CUDA memcpy HtoD]
315.59ms  1.4720us                    -               -         -         -         -  4.0000KB  2.5915GB/s    Pageable      Device  GeForce GTX 960         1         7  [CUDA memcpy HtoD]
433.71ms  3.3280us              (1 1 1)      (1024 1 1)        19        0B        0B         -           -           -           -  GeForce GTX 960         1         7  cudapy::__main__::__vectorized_vec_op$243(Array<int, int=1, A, mutable, aligned>, Array<int, int=1, A, mutable, aligned>, Array<int, int=1, A, mutable, aligned>, Array<int, int=1, A, mutable, aligned>) [44]
434.99ms  1.4720us                    -               -         -         -         -  4.0000KB  2.5915GB/s    Pageable      Device  GeForce GTX 960         1         7  [CUDA memcpy HtoD]
435.51ms  1.4720us                    -               -         -         -         -  4.0000KB  2.5915GB/s    Pageable      Device  GeForce GTX 960         1         7  [CUDA memcpy HtoD]
436.01ms  2.2720us              (1 1 1)      (1024 1 1)        19        0B        0B         -           -           -           -  GeForce GTX 960         1         7  cudapy::__main__::__vectorized_vec_op$243(Array<int, int=1, A, mutable, aligned>, Array<int, int=1, A, mutable, aligned>, Array<int, int=1, A, mutable, aligned>, Array<int, int=1, A, mutable, aligned>) [52]
436.26ms  1.6640us                    -               -         -         -         -  4.0000KB  2.2925GB/s      Device    Pageable  GeForce GTX 960         1         7  [CUDA memcpy DtoH]
Regs: Number of registers used per CUDA thread. This number includes registers used internally by the CUDA driver and/or tools and can be more than what the compiler shows.
SSMem: Static shared memory allocated per CUDA block.
DSMem: Dynamic shared memory allocated per CUDA block.
SrcMemType: The type of source memory accessed by memory operation/copy
DstMemType: The type of destination memory accessed by memory operation/copy
$
```

Studying the nvprof  output, we see that the first CUDA memcpy HtoD is expected, because this is my code transfer `a` to `dev_a` .  However, on each pass of the for loop, numba is also copying two additional arrays.  These can be shown to correspond to the `b` and `c` parameters, which I have passed as scalars.  I found a cryptic reference to this possibility [here](https://numba.pydata.org/numba-doc/dev/user/vectorize.html#overwriting-input-values), but nevertheless it surprises me, and hopefully it is evident this could be a significant performance issue, essentially cratering vectorize performance in a looped case.  I understand there are possible workarounds - for example I could create my own arrays that are all filled with the constant scalar value (essentially duplicating what numba appears to be doing?) which would eliminate the HtoD  transfers, I believe, and/or I could simply convert everything to @cuda.jit, but for expressive simplicity, it would be nice to be able to have a scalar transmitted as a scalar, directly to the underlying kernel launch.

user: rcrovella
labels: CUDA: CUDA related issue/PR
performance - run time: Performance issue occurring at run time.
issue_6236: state: open
title: memory leak when using map()
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug


<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).

- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->


## Environment

```
OS: 64bit Mac OS X 10.14.6 18G4032
Kernel: x86_64 Darwin 18.7.0
CPU: Intel Core i7-4750HQ @ 2.00GHz
```

```
$ python --version
Python 3.8.2
```

```
$ python -c 'import numba; print(numba.__version__)'
0.51.2
```

## List comprehension version

```python
import numpy as np
import numba


@numba.njit
def list_comp(arr):
    [np.log(x) for x in arr]


arr = np.arange(10)
for _ in range(10000):
    list_comp(arr)

stats = numba.core.runtime.rtsys.get_allocation_stats()
print("stats:", stats.alloc - stats.free)
```

```
stats: 0
```

## map() version

```python
import numpy as np
import numba


@numba.njit
def list_comp(arr):
    map(np.log, arr)


arr = np.arange(10)
for _ in range(10000):
    list_comp(arr)

stats = numba.core.runtime.rtsys.get_allocation_stats()
print("stats:", stats.alloc - stats.free)
```

```
stats: 10000
```


----

I really liked using numba, thanks for all the hard work building it.

This seems related to bugs with `yield`, but a `yield` isn't used here, which makes this bug really hard to find. 
I hope this gets taken care of.
user: devxpy
labels: bug - memory leak: Memory leak
issue_6235: state: open
title: ctypes.Structure support for carray dtype in npm
body: numba 0.51.2

```python
import numba
import ctypes

class A(ctypes.Structure):
    _fields_ = [("a", ctypes.c_int32)]

@numba.njit
def test(address):
    return numba.carray(ctypes.c_void_p(address), shape=1, dtype=A)



x = A(a=5)
x_ptr = ctypes.POINTER(A)(x)
x_address = ctypes.addressof(x)

numba.carray(x_ptr, shape=1) # TypeError: Unsupported ctypes type: <class '__main__.LP_A'>
numba.carray(ctypes.c_void_p(x_address), shape=1, dtype=A) # works
test(x_address) # compilation error



```
user: hn-sl
issue_6232: state: open
title: Incorrect behavior when mutating the captured variable in nopython mode
body: ## Reporting a bug

* Python Version: 3.8.0
* Numba Version: 0.51.2

A minimal snippet to reproduce the bug is as follows:

```python
import numba
def generateEmit(n, emit):
    for i in range(n):
        emit(i)

def test():
    sum = 0
    def acc(v):
        nonlocal sum
        sum += v
    generateEmit(13123, acc)
    return sum

@numba.njit
def generateEmitJit(n, emit):
    for i in range(n):
        emit(i)

@numba.njit
def testJit():
    sum = 0
    def acc(v):
        nonlocal sum
        sum += v
    generateEmitJit(13123, acc)
    return sum

print("test = ", test())
print("testJit = ", testJit())
```

* Expected behavior: both test and testJit should return 86100003.
* Actual behavior: test =  86100003, testJit =  0

user: stevenybw
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6228: state: open
title: Some numpy broadcasting operations fail in numba 0.51
body: Minimal code example:

```python
import numpy as np
from numba import njit

@njit(parallel=True)
def use_numba():
    temp = np.ones((3, 5))
    temp[1:] *= (2*np.ones(5))
    return temp                                                                                                                                                                                                                       print(use_numba())
```

(I'm using Python 3.8 but guess this is irrelevant) in `numba 0.49.1` this works fine and gives:

```
[[1. 1. 1. 1. 1.]
 [2. 2. 2. 2. 2.]
 [2. 2. 2. 2. 2.]]
```

but in `numba 0.51.2` it gives an error, I think it is a broadcasting issue between `temp` which is 2D and the other factor which is 1D:

```
TypingError: Failed in nopython mode pipeline (step: nopython mode backend) 
Failed in nopython mode pipeline (step: nopython frontend) 
No implementation of function Function(<built-in function getitem>) found for signature: 
  
 >>> getitem(array(float64, 1d, C), UniTuple(uint64 x 2)) 
  
There are 22 candidate implementations: 
  - Of which 20 did not match due to: 
  Overload of function 'getitem': File: <numerous>: Line N/A. 
    With argument(s): '(array(float64, 1d, C), UniTuple(uint64 x 2))': 
   No match. 
  - Of which 2 did not match due to: 
  Overload in function 'GetItemBuffer.generic': File: numba/core/typing/arraydecl.py: Line 162. 
    With argument(s): '(array(float64, 1d, C), UniTuple(uint64 x 2))': 
   Rejected as the implementation raised a specific error: 
     TypeError: cannot index array(float64, 1d, C) with 2 indices: UniTuple(uint64 x 2) 
  raised from /home/zonca/anaconda/envs/temp/lib/python3.8/site-packages/numba/core/typing/arraydecl.py:84 
 
During: typing of intrinsic-call at /extrahome/software/pysm/minimal.py (7) 
 
File "minimal.py", line 7: 
def use_numba(): 
    <source elided> 
    temp = np.ones((3, 5)) 
    temp[1:] *= (2*np.ones(5)) 
    ^ 
 
During: lowering "id=3[LoopNest(index_variable = parfor_index.29, range = (0, $22binary_subscr.11_size0.1, 1)), LoopNest(index_variable = parfor_index.30, range = (0, $const_5, 1))]{4: <ir.Block at /extrahome/software/pysm/minimal.py (7)>}Var($parfor_index_tuple_var.31, minimal.py:7)" at /extrahome/software/pysm/minimal.py (7) 
```


user: zonca
labels: bug - failure to compile: Bugs: failed to compile valid code
bug - regression: A regression against a previous version of Numba
issue_6222: state: open
title: Add type annotations to parts of numba/core
body: * Adds type annotations to `numba/core/types` (already mypy level 3) and `numba/core/typeconv` (added with mypy level 1)
* Adds `typing_extensions` as a dependency and updates the CI configs to include this
* Updates the pre-commit hooks to include `mypy`
* Removes several files from the flake8 ignore list
user: EPronovost
issue_6215: state: open
title: Make some IR nodes immutable
body: Inspired by https://github.com/numba/numba/pull/6212.

This PR looks at the mutable issue with the IR and makes more of the IR nodes immutable.

Main changes:
- Use `__slots__` in IR nodes. Ban dynamically adding attributes.
- Make `Var`, `Loc` immutable.
- Fix array-comprehension rewrite that violates the above.
- Flake8
user: sklam
issue_6199: state: open
title: @guvectorize(cache=True) calls obsolete version of DUFunc
body: numba 0.51

If a guvectorized function internally invokes a DUFunc and the DUFunc changes after the disk cache for the guvectorized function has been generated, numba won't notice.

t1.py:
```python
import numba

@numba.vectorize
def f(x):
    return x + 1
```
t2.py:
```python
import numba
from t1 import f


@numba.guvectorize(["f8,f8[:]"], "()->()", cache=True)
def g(x, out):
    out[0] = f(x)


print(g(2))
```
Run t2.py: ``3``
Modify t1.py to ``return x + 2`` and rerun t2.py: ``3``
Expected result: ``4``

user: crusaderky
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_6184: state: open
title: Improve error message for NumPy alias type used as dtype in ArrayNdCtors
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
As per #3993 This
```python
from numba import njit
import numpy as np

@njit
def foo():
    return np.zeros((2, 2), dtype=np.float)

foo()
```
produces:
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function zeros>) found for signature:
 
 >>> zeros(UniTuple(Literal[int](2) x 2), dtype=Function(<class 'float'>))
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload of function 'zeros': File: numba/core/typing/npydecl.py: Line 504.
    With argument(s): '(UniTuple(int64 x 2), dtype=Function(<class 'float'>))':
   No match.

During: resolving callee type: Function(<built-in function zeros>)
During: typing of call at issue3993.py (25)


File "issue3993.py", line 25:
def foo():
    return np.zeros((2, 2), dtype=np.float)
    ^


```
which provides correct information given what Numba can infer generically, but this is a common issue and so it'd probably be a good idea to provide a specific message.

Here's starter patch to provide a better error message:
```diff
diff --git a/numba/core/typing/npydecl.py b/numba/core/typing/npydecl.py
index 2dbbed39b..3483fced2 100644
--- a/numba/core/typing/npydecl.py
+++ b/numba/core/typing/npydecl.py
@@ -508,6 +508,25 @@ class NdConstructor(CallableTemplate):
             else:
                 nb_dtype = parse_dtype(dtype)
 
+            if nb_dtype is None:
+                if isinstance(dtype, types.Function):
+                    # user is probably doing `np.float` or `np.int` or similar.
+                    try:
+                        nm = dtype.key[0].__name__
+                        if hasattr(np, nm):
+                            # user probably ought to use a specific type or the
+                            # one with an underscore
+                            if hasattr(np, '%s_' % nm):
+                                msg = ("dtype 'np.%s' is not supported, "
+                                       "perhaps use 'np.%s_' or a more "
+                                       "specific dtype?" % (nm, nm))
+                            else:
+                                msg = "dtype 'np.%s' is not supported" % nm
+                            raise TypingError(msg)
+                    except AttributeError:
+                        pass
+                raise TypingError("dtype '%s' is unsupported." % dtype)
+
 ```
with such a patch, this appears:
```
No implementation of function Function(<built-in function zeros>) found for signature:
 
 >>> zeros(UniTuple(Literal[int](2) x 2), dtype=Function(<class 'float'>))
 
There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'zeros': File: numba/core/typing/npydecl.py: Line 504.
    With argument(s): '(UniTuple(int64 x 2), dtype=Function(<class 'float'>))':
   Rejected as the implementation raised a specific error:
     TypeError: dtype 'np.float' is not supported, perhaps use 'np.float_' or a more specific dtype?
```
user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_6173: state: open
title: After the first function with default arguments is compilled, all subsequent functions with default arguments that get compilled will be very slow to run
body: - [x] I have tried using the latest released version of Numba
- [x] I have included below a minimal working reproducer

This is a really weird bug that seems related to the closed #2029. I find that the fixes seem not to be working after the first function Numba compiles with default arguments.

The following code reproduces the issue:

```
import numba

@numba.njit
def func(x, y=1.0, z=1):
    return x+x + y + z
func(2.2)
%timeit func(2.2)

@numba.njit
def func2(x, y=1.0, z=1):
    return x+x + y + z
func2(2.2)
%timeit func2(2.2)
```

The output is something like  as follows, and the issue appears to subsequent functions that get compiled that have default arguments also.

```
294 ns ± 2.02 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
27.2 µs ± 106 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```

By the way, I have found several cases where using Numba results in SIMD optimizations being performed that make code much faster than a C++ compiler does. With enough coercing in this case MSVC will indeed do the optimizations, but it was very challenging to make something work that Numba did without even letting me know! 

On the other hand the MSVC experience involved compiler flags  to get debug messages that slowed compilation way down and MSVC still made me do things Numba/LLVM didn't need me to do at all. It is really feeling like a mediocre Python developer can surpass a pretty good C++ programmer these days thanks to all of your incredible work!

<details>
  <summary>Full output with NUMBA_DEBUG=1 (output for both function compilations):</summary>

```
================================================================================
--------------------------FUNCTION OPTIMIZED DUMP nrt---------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.140553090603008 = internal constant { i8*, i32, i8* } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.140553090603008, i32 0, i32 0), i32 102, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @.const.pickledata.140553090603008.sha1, i32 0, i32 0) }
@.const.pickledata.140553090603008 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."
@.const.pickledata.140553090603008.sha1 = internal constant [20 x i8] c"\97\BE\DC\DF\EC\8E\80\B7\09>P\CE%\EDV\F7r\0E\0C\9C"

define i64 @nrt_atomic_add(i64* %.1) {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

define i64 @nrt_atomic_sub(i64* %.1) {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = sub i64 %.4, 1
  ret i64 %.5
}

define i32 @nrt_atomic_cas(i64* %.1, i64 %.2, i64 %.3, i64* %.4) {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

define i8* @NRT_MemInfo_data_fast(i8* %.1) {
.3:
  %.4 = bitcast i8* %.1 to { i64, i8*, i8*, i8*, i64 }*
  %.5 = getelementptr { i64, i8*, i8*, i8*, i64 }, { i64, i8*, i8*, i8*, i64 }* %.4, i32 0, i32 3
  %.6 = load i8*, i8** %.5
  ret i8* %.6
}

; Function Attrs: noinline
define void @NRT_incref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.8 = call i64 @nrt_atomic_add(i64* %.7)
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif.if, %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.9 = call i64 @nrt_atomic_sub(i64* %.8)
  %.10 = icmp eq i64 %.9, 0
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  call void @NRT_MemInfo_call_dtor(i8* %.1)
  br label %.3.if
}

declare void @NRT_MemInfo_call_dtor(i8*)

define i32 @nrt_unresolved_abort(i8** %.1, { i8*, i32, i8* }** %.2) {
.4:
  store { i8*, i32, i8* }* @.const.picklebuf.140553090603008, { i8*, i32, i8* }** %.2
  ret i32 1
}

attributes #0 = { noinline }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
-------------------------------OPTIMIZED DUMP nrt-------------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.140553090603008 = internal constant { i8*, i32, i8* } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.140553090603008, i32 0, i32 0), i32 102, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @.const.pickledata.140553090603008.sha1, i32 0, i32 0) }
@.const.pickledata.140553090603008 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."
@.const.pickledata.140553090603008.sha1 = internal constant [20 x i8] c"\97\BE\DC\DF\EC\8E\80\B7\09>P\CE%\EDV\F7r\0E\0C\9C"

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_add(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_sub(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, -1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i32 @nrt_atomic_cas(i64* nocapture %.1, i64 %.2, i64 %.3, i64* nocapture %.4) local_unnamed_addr #0 {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4, align 8
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

; Function Attrs: norecurse nounwind readonly
define i8* @NRT_MemInfo_data_fast(i8* nocapture readonly %.1) local_unnamed_addr #1 {
.3:
  %.5 = getelementptr i8, i8* %.1, i64 24
  %0 = bitcast i8* %.5 to i8**
  %.6 = load i8*, i8** %0, align 8
  ret i8* %.6
}

; Function Attrs: nofree noinline norecurse nounwind
define void @NRT_incref(i8* %.1) local_unnamed_addr #2 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw add i64* %.7, i64 1 monotonic
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) local_unnamed_addr #3 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: nofree norecurse nounwind writeonly
define i32 @nrt_unresolved_abort(i8** nocapture readnone %.1, { i8*, i32, i8* }** nocapture %.2) local_unnamed_addr #4 {
.4:
  store { i8*, i32, i8* }* @.const.picklebuf.140553090603008, { i8*, i32, i8* }** %.2, align 8
  ret i32 1
}

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #5

attributes #0 = { nofree norecurse nounwind }
attributes #1 = { norecurse nounwind readonly }
attributes #2 = { nofree noinline norecurse nounwind }
attributes #3 = { noinline }
attributes #4 = { nofree norecurse nounwind writeonly }
attributes #5 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
----------------------------------ASSEMBLY nrt----------------------------------
	.text
	.file	"<string>"
	.globl	nrt_atomic_add
	.p2align	4, 0x90
	.type	nrt_atomic_add,@function
nrt_atomic_add:
	movl	$1, %eax
	lock		xaddq	%rax, (%rdi)
	incq	%rax
	retq
.Lfunc_end0:
	.size	nrt_atomic_add, .Lfunc_end0-nrt_atomic_add

	.globl	nrt_atomic_sub
	.p2align	4, 0x90
	.type	nrt_atomic_sub,@function
nrt_atomic_sub:
	movq	$-1, %rax
	lock		xaddq	%rax, (%rdi)
	decq	%rax
	retq
.Lfunc_end1:
	.size	nrt_atomic_sub, .Lfunc_end1-nrt_atomic_sub

	.globl	nrt_atomic_cas
	.p2align	4, 0x90
	.type	nrt_atomic_cas,@function
nrt_atomic_cas:
	movq	%rsi, %rax
	xorl	%esi, %esi
	lock		cmpxchgq	%rdx, (%rdi)
	sete	%sil
	movq	%rax, (%rcx)
	movl	%esi, %eax
	retq
.Lfunc_end2:
	.size	nrt_atomic_cas, .Lfunc_end2-nrt_atomic_cas

	.globl	NRT_MemInfo_data_fast
	.p2align	4, 0x90
	.type	NRT_MemInfo_data_fast,@function
NRT_MemInfo_data_fast:
	movq	24(%rdi), %rax
	retq
.Lfunc_end3:
	.size	NRT_MemInfo_data_fast, .Lfunc_end3-NRT_MemInfo_data_fast

	.globl	NRT_incref
	.p2align	4, 0x90
	.type	NRT_incref,@function
NRT_incref:
	testq	%rdi, %rdi
	je	.LBB4_1
	lock		incq	(%rdi)
	retq
.LBB4_1:
	retq
.Lfunc_end4:
	.size	NRT_incref, .Lfunc_end4-NRT_incref

	.globl	NRT_decref
	.p2align	4, 0x90
	.type	NRT_decref,@function
NRT_decref:
	.cfi_startproc
	testq	%rdi, %rdi
	je	.LBB5_2
	#MEMBARRIER
	lock		decq	(%rdi)
	je	.LBB5_3
.LBB5_2:
	retq
.LBB5_3:
	#MEMBARRIER
	movabsq	$NRT_MemInfo_call_dtor, %rax
	jmpq	*%rax
.Lfunc_end5:
	.size	NRT_decref, .Lfunc_end5-NRT_decref
	.cfi_endproc

	.globl	nrt_unresolved_abort
	.p2align	4, 0x90
	.type	nrt_unresolved_abort,@function
nrt_unresolved_abort:
	movabsq	$.const.picklebuf.140553090603008, %rax
	movq	%rax, (%rsi)
	movl	$1, %eax
	retq
.Lfunc_end6:
	.size	nrt_unresolved_abort, .Lfunc_end6-nrt_unresolved_abort

	.type	.const.picklebuf.140553090603008,@object
	.section	.rodata,"a",@progbits
	.p2align	4
.const.picklebuf.140553090603008:
	.quad	.const.pickledata.140553090603008
	.long	102
	.zero	4
	.quad	.const.pickledata.140553090603008.sha1
	.size	.const.picklebuf.140553090603008, 24

	.type	.const.pickledata.140553090603008,@object
	.p2align	4
.const.pickledata.140553090603008:
	.ascii	"\200\004\225[\000\000\000\000\000\000\000\214\bbuiltins\224\214\fRuntimeError\224\223\224\2146numba jitted function aborted due to unresolved symbol\224\205\224N\207\224."
	.size	.const.pickledata.140553090603008, 102

	.type	.const.pickledata.140553090603008.sha1,@object
	.p2align	4
.const.pickledata.140553090603008.sha1:
	.ascii	"\227\276\334\337\354\216\200\267\t>P\316%\355V\367r\016\f\234"
	.size	.const.pickledata.140553090603008.sha1, 20

	.section	".note.GNU-stack","",@progbits

================================================================================
---------------------------------IR DUMP: func----------------------------------
label 0:
    x = arg(0, name=x)                       ['x']
    y = arg(1, name=y)                       ['y']
    z = arg(2, name=z)                       ['z']
    $6binary_add.2 = x + x                   ['$6binary_add.2', 'x', 'x']
    $10binary_add.4 = $6binary_add.2 + y     ['$10binary_add.4', '$6binary_add.2', 'y']
    $14binary_add.6 = $10binary_add.4 + z    ['$10binary_add.4', '$14binary_add.6', 'z']
    $16return_value.7 = cast(value=$14binary_add.6) ['$14binary_add.6', '$16return_value.7']
    return $16return_value.7                 ['$16return_value.7']

---------------------------------IR DUMP: func----------------------------------
label 0:
    x = arg(0, name=x)                       ['x']
    y = arg(1, name=y)                       ['y']
    z = arg(2, name=z)                       ['z']
    $6binary_add.2 = x + x                   ['$6binary_add.2', 'x', 'x']
    $10binary_add.4 = $6binary_add.2 + y     ['$10binary_add.4', '$6binary_add.2', 'y']
    $14binary_add.6 = $10binary_add.4 + z    ['$10binary_add.4', '$14binary_add.6', 'z']
    $16return_value.7 = cast(value=$14binary_add.6) ['$14binary_add.6', '$16return_value.7']
    return $16return_value.7                 ['$16return_value.7']

-------------------------------SSA IR DUMP: func--------------------------------
label 0:
    x = arg(0, name=x)                       ['x']
    y = arg(1, name=y)                       ['y']
    z = arg(2, name=z)                       ['z']
    $6binary_add.2 = x + x                   ['$6binary_add.2', 'x', 'x']
    $10binary_add.4 = $6binary_add.2 + y     ['$10binary_add.4', '$6binary_add.2', 'y']
    $14binary_add.6 = $10binary_add.4 + z    ['$10binary_add.4', '$14binary_add.6', 'z']
    $16return_value.7 = cast(value=$14binary_add.6) ['$14binary_add.6', '$16return_value.7']
    return $16return_value.7                 ['$16return_value.7']

-----------------------------------propagate------------------------------------
---- type variables ----
[$10binary_add.4 := float64,
 $14binary_add.6 := float64,
 $16return_value.7 := float64,
 $6binary_add.2 := float64,
 arg.x := float64,
 arg.y := omitted(default=1.0),
 arg.z := omitted(default=1),
 x := float64,
 y := float64,
 z := Literal[int](1)]
-----------------------------------propagate------------------------------------
---- type variables ----
[$10binary_add.4 := float64,
 $14binary_add.6 := float64,
 $16return_value.7 := float64,
 $6binary_add.2 := float64,
 arg.x := float64,
 arg.y := omitted(default=1.0),
 arg.z := omitted(default=1),
 x := float64,
 y := float64,
 z := Literal[int](1)]
---------------------------------Variable types---------------------------------
{'$10binary_add.4': float64,
 '$14binary_add.6': float64,
 '$16return_value.7': float64,
 '$6binary_add.2': float64,
 'arg.x': float64,
 'arg.y': omitted(default=1.0),
 'arg.z': omitted(default=1),
 'x': float64,
 'y': float64,
 'z': Literal[int](1)}
----------------------------------Return type-----------------------------------
float64
-----------------------------------Call types-----------------------------------
{$10binary_add.4 + z: (float64, float64) -> float64,
 $6binary_add.2 + y: (float64, float64) -> float64,
 x + x: (float64, float64) -> float64}
--------------------LLVM DUMP <function descriptor 'func$1'>--------------------
; ModuleID = "func$1"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"

@"_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = common global i8* null
define i32 @"_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* noalias nocapture %"retptr", {i8*, i32, i8*}** noalias nocapture %"excinfo", double %"arg.x") 
{
entry:
  %"x" = alloca double
  store double 0.0, double* %"x"
  %"y" = alloca double
  store double 0.0, double* %"y"
  %"z" = alloca i64
  store i64 0, i64* %"z"
  %"$6binary_add.2" = alloca double
  store double 0.0, double* %"$6binary_add.2"
  %"$10binary_add.4" = alloca double
  store double 0.0, double* %"$10binary_add.4"
  %"$14binary_add.6" = alloca double
  store double 0.0, double* %"$14binary_add.6"
  %"$16return_value.7" = alloca double
  store double 0.0, double* %"$16return_value.7"
  br label %"B0"
B0:
  %".6" = load double, double* %"x"
  store double %"arg.x", double* %"x"
  %".9" = load double, double* %"y"
  store double 0x3ff0000000000000, double* %"y"
  %".12" = load i64, i64* %"z"
  store i64 1, i64* %"z"
  %".14" = load double, double* %"x"
  %".15" = load double, double* %"x"
  %".16" = fadd double %".14", %".15"
  %".18" = load double, double* %"$6binary_add.2"
  store double %".16", double* %"$6binary_add.2"
  %".20" = load double, double* %"x"
  store double 0.0, double* %"x"
  %".22" = load double, double* %"$6binary_add.2"
  %".23" = load double, double* %"y"
  %".24" = fadd double %".22", %".23"
  %".26" = load double, double* %"$10binary_add.4"
  store double %".24", double* %"$10binary_add.4"
  %".28" = load double, double* %"y"
  store double 0.0, double* %"y"
  %".30" = load double, double* %"$6binary_add.2"
  store double 0.0, double* %"$6binary_add.2"
  %".32" = load double, double* %"$10binary_add.4"
  %".33" = load i64, i64* %"z"
  %".34" = sitofp i64 1 to double
  %".35" = fadd double %".32", %".34"
  %".37" = load double, double* %"$14binary_add.6"
  store double %".35", double* %"$14binary_add.6"
  %".39" = load i64, i64* %"z"
  store i64 0, i64* %"z"
  %".41" = load double, double* %"$10binary_add.4"
  store double 0.0, double* %"$10binary_add.4"
  %".43" = load double, double* %"$14binary_add.6"
  %".45" = load double, double* %"$16return_value.7"
  store double %".43", double* %"$16return_value.7"
  %".47" = load double, double* %"$14binary_add.6"
  store double 0.0, double* %"$14binary_add.6"
  %".49" = load double, double* %"$16return_value.7"
  store double %".49", double* %"retptr"
  ret i32 0
}

================================================================================
================================================================================
--------------------------FUNCTION OPTIMIZED DUMP func--------------------------
; ModuleID = 'func'
source_filename = "<string>"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = common global i8* null
@.const.func = internal constant [5 x i8] c"func\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = internal constant [112 x i8] c"missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29\00"
@_Py_NoneStruct = external global i8
@PyExc_StopIteration = external global i8
@PyExc_SystemError = external global i8
@".const.unknown error when calling native function" = internal constant [43 x i8] c"unknown error when calling native function\00"

define i32 @"_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* noalias nocapture %retptr, { i8*, i32, i8* }** noalias nocapture %excinfo, double %arg.x) {
entry:
  %.16 = fadd double %arg.x, %arg.x
  %.24 = fadd double %.16, 1.000000e+00
  %.35 = fadd double %.24, 1.000000e+00
  store double %.35, double* %retptr
  ret i32 0
}

define i8* @"_ZN7cpython8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(i8* %py_closure, i8* %py_args, i8* %py_kws) {
entry:
  %.5 = alloca i8*
  %.6 = alloca i8*
  %.7 = alloca i8*
  %.8 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.const.func, i32 0, i32 0), i64 3, i64 3, i8** %.5, i8** %.6, i8** %.7)
  %.9 = icmp eq i32 %.8, 0
  %.31 = alloca double
  store double 0.000000e+00, double* %.31
  %excinfo = alloca { i8*, i32, i8* }*
  store { i8*, i32, i8* }* null, { i8*, i32, i8* }** %excinfo
  br i1 %.9, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif.if.if, %entry.endif.endif, %entry.endif.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif.endif.endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.13 = load i8*, i8** @"_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"
  %.14 = ptrtoint i8* %.13 to i64
  %.15 = add i64 %.14, 16
  %.16 = inttoptr i64 %.15 to i8*
  %.18 = icmp eq i8* null, %.13
  br i1 %.18, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* @PyExc_RuntimeError, i8* getelementptr inbounds ([112 x i8], [112 x i8]* @".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", i32 0, i32 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.22 = load i8*, i8** %.5
  %.23 = call i8* @PyNumber_Float(i8* %.22)
  %.24 = call double @PyFloat_AsDouble(i8* %.23)
  call void @Py_DecRef(i8* %.23)
  %.26 = call i8* @PyErr_Occurred()
  %.27 = icmp ne i8* null, %.26
  br i1 %.27, label %entry.if, label %entry.endif.endif.endif, !prof !0

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  store double 0.000000e+00, double* %.31
  %.35 = call i32 @"_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* %.31, { i8*, i32, i8* }** %excinfo, double %.24)
  %.36 = load { i8*, i32, i8* }*, { i8*, i32, i8* }** %excinfo
  %.37 = icmp eq i32 %.35, 0
  %.38 = icmp eq i32 %.35, -2
  %.41 = or i1 %.37, %.38
  %.43 = icmp sge i32 %.35, 1
  %.45 = load double, double* %.31
  switch i32 %.35, label %entry.endif.endif.endif.endif [
    i32 -2, label %entry.endif.endif.endif.if
    i32 0, label %entry.endif.endif.endif.if
  ]

entry.endif.endif.endif.if:                       ; preds = %entry.endif.endif.endif, %entry.endif.endif.endif
  br i1 %.38, label %entry.endif.endif.endif.if.if, label %entry.endif.endif.endif.if.endif

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  br i1 %.43, label %entry.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.if.if:                    ; preds = %entry.endif.endif.endif.if
  call void @Py_IncRef(i8* @_Py_NoneStruct)
  ret i8* @_Py_NoneStruct

entry.endif.endif.endif.if.endif:                 ; preds = %entry.endif.endif.endif.if
  %.50 = call i8* @PyFloat_FromDouble(double %.45)
  ret i8* %.50

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  call void @PyErr_Clear()
  %.55 = load { i8*, i32, i8* }, { i8*, i32, i8* }* %.36
  %.56 = extractvalue { i8*, i32, i8* } %.55, 0
  %.58 = extractvalue { i8*, i32, i8* } %.55, 1
  %.60 = extractvalue { i8*, i32, i8* } %.55, 2
  %.61 = call i8* @numba_unpickle(i8* %.56, i32 %.58, i8* %.60)
  %.62 = icmp ne i8* null, %.61
  br i1 %.62, label %entry.endif.endif.endif.endif.if.if, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif
  switch i32 %.35, label %entry.endif.endif.endif.endif.endif.endif.endif [
    i32 -3, label %entry.endif.endif.endif.endif.endif.if
    i32 -1, label %entry.if
  ]

entry.endif.endif.endif.endif.if.if:              ; preds = %entry.endif.endif.endif.endif.if
  call void @numba_do_raise(i8* %.61)
  br label %entry.if

entry.endif.endif.endif.endif.endif.if:           ; preds = %entry.endif.endif.endif.endif.endif
  call void @PyErr_SetNone(i8* @PyExc_StopIteration)
  br label %entry.if

entry.endif.endif.endif.endif.endif.endif.endif:  ; preds = %entry.endif.endif.endif.endif.endif
  call void @PyErr_SetString(i8* @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function", i32 0, i32 0))
  br label %entry.if
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...)

declare void @PyErr_SetString(i8*, i8*)

declare i8* @PyNumber_Float(i8*)

declare double @PyFloat_AsDouble(i8*)

declare void @Py_DecRef(i8*)

declare i8* @PyErr_Occurred()

declare void @Py_IncRef(i8*)

declare i8* @PyFloat_FromDouble(double)

declare void @PyErr_Clear()

declare i8* @numba_unpickle(i8*, i32, i8*)

declare void @numba_do_raise(i8*)

declare void @PyErr_SetNone(i8*)

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
------------------------------OPTIMIZED DUMP func-------------------------------
; ModuleID = 'func'
source_filename = "<string>"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = common local_unnamed_addr global i8* null
@.const.func = internal constant [5 x i8] c"func\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = internal constant [112 x i8] c"missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29\00"

; Function Attrs: nofree norecurse nounwind writeonly
define i32 @"_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* noalias nocapture %retptr, { i8*, i32, i8* }** noalias nocapture readnone %excinfo, double %arg.x) local_unnamed_addr #0 {
entry:
  %.16 = fadd double %arg.x, %arg.x
  %.24 = fadd double %.16, 1.000000e+00
  %.35 = fadd double %.24, 1.000000e+00
  store double %.35, double* %retptr, align 8
  ret i32 0
}

define i8* @"_ZN7cpython8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = alloca i8*, align 8
  %.8 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.const.func, i64 0, i64 0), i64 3, i64 3, i8** nonnull %.5, i8** nonnull %.6, i8** nonnull %.7)
  %.9 = icmp eq i32 %.8, 0
  br i1 %.9, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.13 = load i8*, i8** @"_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", align 8
  %.18 = icmp eq i8* %.13, null
  br i1 %.18, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([112 x i8], [112 x i8]* @".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.22 = load i8*, i8** %.5, align 8
  %.23 = call i8* @PyNumber_Float(i8* %.22)
  %.24 = call double @PyFloat_AsDouble(i8* %.23)
  call void @Py_DecRef(i8* %.23)
  %.26 = call i8* @PyErr_Occurred()
  %.27 = icmp eq i8* %.26, null
  br i1 %.27, label %entry.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  %.16.i = fadd double %.24, %.24
  %.24.i = fadd double %.16.i, 1.000000e+00
  %.35.i = fadd double %.24.i, 1.000000e+00
  %.50 = call i8* @PyFloat_FromDouble(double %.35.i)
  ret i8* %.50
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i8* @PyNumber_Float(i8*) local_unnamed_addr

declare double @PyFloat_AsDouble(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyFloat_FromDouble(double) local_unnamed_addr

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #1

attributes #0 = { nofree norecurse nounwind writeonly }
attributes #1 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
---------------------------------ASSEMBLY func----------------------------------
	.text
	.file	"<string>"
	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI0_0:
	.quad	4607182418800017408
	.text
	.globl	_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29
	.p2align	4, 0x90
	.type	_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,@function
_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29:
	vaddsd	%xmm0, %xmm0, %xmm0
	movabsq	$.LCPI0_0, %rax
	vmovsd	(%rax), %xmm1
	vaddsd	%xmm1, %xmm0, %xmm0
	vaddsd	%xmm1, %xmm0, %xmm0
	vmovsd	%xmm0, (%rdi)
	xorl	%eax, %eax
	retq
.Lfunc_end0:
	.size	_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29, .Lfunc_end0-_ZN8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29

	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI1_0:
	.quad	4607182418800017408
	.text
	.globl	_ZN7cpython8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29
	.p2align	4, 0x90
	.type	_ZN7cpython8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,@function
_ZN7cpython8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29:
	.cfi_startproc
	pushq	%rbx
	.cfi_def_cfa_offset 16
	subq	$48, %rsp
	.cfi_def_cfa_offset 64
	.cfi_offset %rbx, -16
	movq	%rsi, %rdi
	leaq	32(%rsp), %rax
	movq	%rax, (%rsp)
	movabsq	$.const.func, %rsi
	movabsq	$PyArg_UnpackTuple, %rbx
	leaq	24(%rsp), %r8
	leaq	40(%rsp), %r9
	movl	$3, %edx
	movl	$3, %ecx
	xorl	%eax, %eax
	callq	*%rbx
	testl	%eax, %eax
	je	.LBB1_1
	movabsq	$_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29, %rax
	cmpq	$0, (%rax)
	je	.LBB1_4
	movq	24(%rsp), %rdi
	movabsq	$PyNumber_Float, %rax
	callq	*%rax
	movq	%rax, %rbx
	movabsq	$PyFloat_AsDouble, %rax
	movq	%rbx, %rdi
	callq	*%rax
	vmovsd	%xmm0, 16(%rsp)
	movabsq	$Py_DecRef, %rax
	movq	%rbx, %rdi
	callq	*%rax
	movabsq	$PyErr_Occurred, %rax
	callq	*%rax
	testq	%rax, %rax
	jne	.LBB1_1
	vmovsd	16(%rsp), %xmm0
	vaddsd	%xmm0, %xmm0, %xmm0
	movabsq	$.LCPI1_0, %rax
	vmovsd	(%rax), %xmm1
	vaddsd	%xmm1, %xmm0, %xmm0
	vaddsd	%xmm1, %xmm0, %xmm0
	movabsq	$PyFloat_FromDouble, %rax
	callq	*%rax
	addq	$48, %rsp
	.cfi_def_cfa_offset 16
	popq	%rbx
	.cfi_def_cfa_offset 8
	retq
.LBB1_4:
	.cfi_def_cfa_offset 64
	movabsq	$PyExc_RuntimeError, %rdi
	movabsq	$".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", %rsi
	movabsq	$PyErr_SetString, %rax
	callq	*%rax
.LBB1_1:
	xorl	%eax, %eax
	addq	$48, %rsp
	.cfi_def_cfa_offset 16
	popq	%rbx
	.cfi_def_cfa_offset 8
	retq
.Lfunc_end1:
	.size	_ZN7cpython8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29, .Lfunc_end1-_ZN7cpython8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29
	.cfi_endproc

	.type	_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,@object
	.comm	_ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,8,8
	.type	.const.func,@object
	.section	.rodata,"a",@progbits
.const.func:
	.asciz	"func"
	.size	.const.func, 5

	.type	".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29",@object
	.p2align	4
".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29":
	.asciz	"missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"
	.size	".const.missing Environment: _ZN08NumbaEnv8__main__8func$241EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", 112

	.section	".note.GNU-stack","",@progbits

================================================================================
---------------------------------IR DUMP: func2---------------------------------
label 0:
    x = arg(0, name=x)                       ['x']
    y = arg(1, name=y)                       ['y']
    z = arg(2, name=z)                       ['z']
    $6binary_add.2 = x + x                   ['$6binary_add.2', 'x', 'x']
    $10binary_add.4 = $6binary_add.2 + y     ['$10binary_add.4', '$6binary_add.2', 'y']
    $14binary_add.6 = $10binary_add.4 + z    ['$10binary_add.4', '$14binary_add.6', 'z']
    $16return_value.7 = cast(value=$14binary_add.6) ['$14binary_add.6', '$16return_value.7']
    return $16return_value.7                 ['$16return_value.7']

---------------------------------IR DUMP: func2---------------------------------
label 0:
    x = arg(0, name=x)                       ['x']
    y = arg(1, name=y)                       ['y']
    z = arg(2, name=z)                       ['z']
    $6binary_add.2 = x + x                   ['$6binary_add.2', 'x', 'x']
    $10binary_add.4 = $6binary_add.2 + y     ['$10binary_add.4', '$6binary_add.2', 'y']
    $14binary_add.6 = $10binary_add.4 + z    ['$10binary_add.4', '$14binary_add.6', 'z']
    $16return_value.7 = cast(value=$14binary_add.6) ['$14binary_add.6', '$16return_value.7']
    return $16return_value.7                 ['$16return_value.7']

-------------------------------SSA IR DUMP: func2-------------------------------
label 0:
    x = arg(0, name=x)                       ['x']
    y = arg(1, name=y)                       ['y']
    z = arg(2, name=z)                       ['z']
    $6binary_add.2 = x + x                   ['$6binary_add.2', 'x', 'x']
    $10binary_add.4 = $6binary_add.2 + y     ['$10binary_add.4', '$6binary_add.2', 'y']
    $14binary_add.6 = $10binary_add.4 + z    ['$10binary_add.4', '$14binary_add.6', 'z']
    $16return_value.7 = cast(value=$14binary_add.6) ['$14binary_add.6', '$16return_value.7']
    return $16return_value.7                 ['$16return_value.7']

-----------------------------------propagate------------------------------------
---- type variables ----
[$10binary_add.4 := float64,
 $14binary_add.6 := float64,
 $16return_value.7 := float64,
 $6binary_add.2 := float64,
 arg.x := float64,
 arg.y := omitted(default=1.0),
 arg.z := omitted(default=1),
 x := float64,
 y := float64,
 z := Literal[int](1)]
-----------------------------------propagate------------------------------------
---- type variables ----
[$10binary_add.4 := float64,
 $14binary_add.6 := float64,
 $16return_value.7 := float64,
 $6binary_add.2 := float64,
 arg.x := float64,
 arg.y := omitted(default=1.0),
 arg.z := omitted(default=1),
 x := float64,
 y := float64,
 z := Literal[int](1)]
---------------------------------Variable types---------------------------------
{'$10binary_add.4': float64,
 '$14binary_add.6': float64,
 '$16return_value.7': float64,
 '$6binary_add.2': float64,
 'arg.x': float64,
 'arg.y': omitted(default=1.0),
 'arg.z': omitted(default=1),
 'x': float64,
 'y': float64,
 'z': Literal[int](1)}
----------------------------------Return type-----------------------------------
float64
-----------------------------------Call types-----------------------------------
{$10binary_add.4 + z: (float64, float64) -> float64,
 $6binary_add.2 + y: (float64, float64) -> float64,
 x + x: (float64, float64) -> float64}
-------------------LLVM DUMP <function descriptor 'func2$2'>--------------------
; ModuleID = "func2$2"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"

@"_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = common global i8* null
define i32 @"_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* noalias nocapture %"retptr", {i8*, i32, i8*}** noalias nocapture %"excinfo", double %"arg.x") 
{
entry:
  %"x" = alloca double
  store double 0.0, double* %"x"
  %"y" = alloca double
  store double 0.0, double* %"y"
  %"z" = alloca i64
  store i64 0, i64* %"z"
  %"$6binary_add.2" = alloca double
  store double 0.0, double* %"$6binary_add.2"
  %"$10binary_add.4" = alloca double
  store double 0.0, double* %"$10binary_add.4"
  %"$14binary_add.6" = alloca double
  store double 0.0, double* %"$14binary_add.6"
  %"$16return_value.7" = alloca double
  store double 0.0, double* %"$16return_value.7"
  br label %"B0"
B0:
  %".6" = load double, double* %"x"
  store double %"arg.x", double* %"x"
  %".9" = load double, double* %"y"
  store double 0x3ff0000000000000, double* %"y"
  %".12" = load i64, i64* %"z"
  store i64 1, i64* %"z"
  %".14" = load double, double* %"x"
  %".15" = load double, double* %"x"
  %".16" = fadd double %".14", %".15"
  %".18" = load double, double* %"$6binary_add.2"
  store double %".16", double* %"$6binary_add.2"
  %".20" = load double, double* %"x"
  store double 0.0, double* %"x"
  %".22" = load double, double* %"$6binary_add.2"
  %".23" = load double, double* %"y"
  %".24" = fadd double %".22", %".23"
  %".26" = load double, double* %"$10binary_add.4"
  store double %".24", double* %"$10binary_add.4"
  %".28" = load double, double* %"y"
  store double 0.0, double* %"y"
  %".30" = load double, double* %"$6binary_add.2"
  store double 0.0, double* %"$6binary_add.2"
  %".32" = load double, double* %"$10binary_add.4"
  %".33" = load i64, i64* %"z"
  %".34" = sitofp i64 1 to double
  %".35" = fadd double %".32", %".34"
  %".37" = load double, double* %"$14binary_add.6"
  store double %".35", double* %"$14binary_add.6"
  %".39" = load i64, i64* %"z"
  store i64 0, i64* %"z"
  %".41" = load double, double* %"$10binary_add.4"
  store double 0.0, double* %"$10binary_add.4"
  %".43" = load double, double* %"$14binary_add.6"
  %".45" = load double, double* %"$16return_value.7"
  store double %".43", double* %"$16return_value.7"
  %".47" = load double, double* %"$14binary_add.6"
  store double 0.0, double* %"$14binary_add.6"
  %".49" = load double, double* %"$16return_value.7"
  store double %".49", double* %"retptr"
  ret i32 0
}

================================================================================
================================================================================
-------------------------FUNCTION OPTIMIZED DUMP func2--------------------------
; ModuleID = 'func2'
source_filename = "<string>"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = common global i8* null
@.const.func2 = internal constant [6 x i8] c"func2\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = internal constant [113 x i8] c"missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29\00"
@_Py_NoneStruct = external global i8
@PyExc_StopIteration = external global i8
@PyExc_SystemError = external global i8
@".const.unknown error when calling native function" = internal constant [43 x i8] c"unknown error when calling native function\00"

define i32 @"_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* noalias nocapture %retptr, { i8*, i32, i8* }** noalias nocapture %excinfo, double %arg.x) {
entry:
  %.16 = fadd double %arg.x, %arg.x
  %.24 = fadd double %.16, 1.000000e+00
  %.35 = fadd double %.24, 1.000000e+00
  store double %.35, double* %retptr
  ret i32 0
}

define i8* @"_ZN7cpython8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(i8* %py_closure, i8* %py_args, i8* %py_kws) {
entry:
  %.5 = alloca i8*
  %.6 = alloca i8*
  %.7 = alloca i8*
  %.8 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.const.func2, i32 0, i32 0), i64 3, i64 3, i8** %.5, i8** %.6, i8** %.7)
  %.9 = icmp eq i32 %.8, 0
  %.31 = alloca double
  store double 0.000000e+00, double* %.31
  %excinfo = alloca { i8*, i32, i8* }*
  store { i8*, i32, i8* }* null, { i8*, i32, i8* }** %excinfo
  br i1 %.9, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif.if.if, %entry.endif.endif, %entry.endif.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif.endif.endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.13 = load i8*, i8** @"_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"
  %.14 = ptrtoint i8* %.13 to i64
  %.15 = add i64 %.14, 16
  %.16 = inttoptr i64 %.15 to i8*
  %.18 = icmp eq i8* null, %.13
  br i1 %.18, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* @PyExc_RuntimeError, i8* getelementptr inbounds ([113 x i8], [113 x i8]* @".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", i32 0, i32 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.22 = load i8*, i8** %.5
  %.23 = call i8* @PyNumber_Float(i8* %.22)
  %.24 = call double @PyFloat_AsDouble(i8* %.23)
  call void @Py_DecRef(i8* %.23)
  %.26 = call i8* @PyErr_Occurred()
  %.27 = icmp ne i8* null, %.26
  br i1 %.27, label %entry.if, label %entry.endif.endif.endif, !prof !0

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  store double 0.000000e+00, double* %.31
  %.35 = call i32 @"_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* %.31, { i8*, i32, i8* }** %excinfo, double %.24)
  %.36 = load { i8*, i32, i8* }*, { i8*, i32, i8* }** %excinfo
  %.37 = icmp eq i32 %.35, 0
  %.38 = icmp eq i32 %.35, -2
  %.41 = or i1 %.37, %.38
  %.43 = icmp sge i32 %.35, 1
  %.45 = load double, double* %.31
  switch i32 %.35, label %entry.endif.endif.endif.endif [
    i32 -2, label %entry.endif.endif.endif.if
    i32 0, label %entry.endif.endif.endif.if
  ]

entry.endif.endif.endif.if:                       ; preds = %entry.endif.endif.endif, %entry.endif.endif.endif
  br i1 %.38, label %entry.endif.endif.endif.if.if, label %entry.endif.endif.endif.if.endif

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  br i1 %.43, label %entry.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.if.if:                    ; preds = %entry.endif.endif.endif.if
  call void @Py_IncRef(i8* @_Py_NoneStruct)
  ret i8* @_Py_NoneStruct

entry.endif.endif.endif.if.endif:                 ; preds = %entry.endif.endif.endif.if
  %.50 = call i8* @PyFloat_FromDouble(double %.45)
  ret i8* %.50

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  call void @PyErr_Clear()
  %.55 = load { i8*, i32, i8* }, { i8*, i32, i8* }* %.36
  %.56 = extractvalue { i8*, i32, i8* } %.55, 0
  %.58 = extractvalue { i8*, i32, i8* } %.55, 1
  %.60 = extractvalue { i8*, i32, i8* } %.55, 2
  %.61 = call i8* @numba_unpickle(i8* %.56, i32 %.58, i8* %.60)
  %.62 = icmp ne i8* null, %.61
  br i1 %.62, label %entry.endif.endif.endif.endif.if.if, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif
  switch i32 %.35, label %entry.endif.endif.endif.endif.endif.endif.endif [
    i32 -3, label %entry.endif.endif.endif.endif.endif.if
    i32 -1, label %entry.if
  ]

entry.endif.endif.endif.endif.if.if:              ; preds = %entry.endif.endif.endif.endif.if
  call void @numba_do_raise(i8* %.61)
  br label %entry.if

entry.endif.endif.endif.endif.endif.if:           ; preds = %entry.endif.endif.endif.endif.endif
  call void @PyErr_SetNone(i8* @PyExc_StopIteration)
  br label %entry.if

entry.endif.endif.endif.endif.endif.endif.endif:  ; preds = %entry.endif.endif.endif.endif.endif
  call void @PyErr_SetString(i8* @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function", i32 0, i32 0))
  br label %entry.if
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...)

declare void @PyErr_SetString(i8*, i8*)

declare i8* @PyNumber_Float(i8*)

declare double @PyFloat_AsDouble(i8*)

declare void @Py_DecRef(i8*)

declare i8* @PyErr_Occurred()

declare void @Py_IncRef(i8*)

declare i8* @PyFloat_FromDouble(double)

declare void @PyErr_Clear()

declare i8* @numba_unpickle(i8*, i32, i8*)

declare void @numba_do_raise(i8*)

declare void @PyErr_SetNone(i8*)

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
------------------------------OPTIMIZED DUMP func2------------------------------
; ModuleID = 'func2'
source_filename = "<string>"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = common local_unnamed_addr global i8* null
@.const.func2 = internal constant [6 x i8] c"func2\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29" = internal constant [113 x i8] c"missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29\00"

; Function Attrs: nofree norecurse nounwind writeonly
define i32 @"_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(double* noalias nocapture %retptr, { i8*, i32, i8* }** noalias nocapture readnone %excinfo, double %arg.x) local_unnamed_addr #0 {
entry:
  %.16 = fadd double %arg.x, %arg.x
  %.24 = fadd double %.16, 1.000000e+00
  %.35 = fadd double %.24, 1.000000e+00
  store double %.35, double* %retptr, align 8
  ret i32 0
}

define i8* @"_ZN7cpython8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = alloca i8*, align 8
  %.8 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.const.func2, i64 0, i64 0), i64 3, i64 3, i8** nonnull %.5, i8** nonnull %.6, i8** nonnull %.7)
  %.9 = icmp eq i32 %.8, 0
  br i1 %.9, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.13 = load i8*, i8** @"_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", align 8
  %.18 = icmp eq i8* %.13, null
  br i1 %.18, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([113 x i8], [113 x i8]* @".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.22 = load i8*, i8** %.5, align 8
  %.23 = call i8* @PyNumber_Float(i8* %.22)
  %.24 = call double @PyFloat_AsDouble(i8* %.23)
  call void @Py_DecRef(i8* %.23)
  %.26 = call i8* @PyErr_Occurred()
  %.27 = icmp eq i8* %.26, null
  br i1 %.27, label %entry.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  %.16.i = fadd double %.24, %.24
  %.24.i = fadd double %.16.i, 1.000000e+00
  %.35.i = fadd double %.24.i, 1.000000e+00
  %.50 = call i8* @PyFloat_FromDouble(double %.35.i)
  ret i8* %.50
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i8* @PyNumber_Float(i8*) local_unnamed_addr

declare double @PyFloat_AsDouble(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyFloat_FromDouble(double) local_unnamed_addr

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #1

attributes #0 = { nofree norecurse nounwind writeonly }
attributes #1 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
---------------------------------ASSEMBLY func2---------------------------------
	.text
	.file	"<string>"
	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI0_0:
	.quad	4607182418800017408
	.text
	.globl	_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29
	.p2align	4, 0x90
	.type	_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,@function
_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29:
	vaddsd	%xmm0, %xmm0, %xmm0
	movabsq	$.LCPI0_0, %rax
	vmovsd	(%rax), %xmm1
	vaddsd	%xmm1, %xmm0, %xmm0
	vaddsd	%xmm1, %xmm0, %xmm0
	vmovsd	%xmm0, (%rdi)
	xorl	%eax, %eax
	retq
.Lfunc_end0:
	.size	_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29, .Lfunc_end0-_ZN8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29

	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI1_0:
	.quad	4607182418800017408
	.text
	.globl	_ZN7cpython8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29
	.p2align	4, 0x90
	.type	_ZN7cpython8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,@function
_ZN7cpython8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29:
	.cfi_startproc
	pushq	%rbx
	.cfi_def_cfa_offset 16
	subq	$48, %rsp
	.cfi_def_cfa_offset 64
	.cfi_offset %rbx, -16
	movq	%rsi, %rdi
	leaq	32(%rsp), %rax
	movq	%rax, (%rsp)
	movabsq	$.const.func2, %rsi
	movabsq	$PyArg_UnpackTuple, %rbx
	leaq	24(%rsp), %r8
	leaq	40(%rsp), %r9
	movl	$3, %edx
	movl	$3, %ecx
	xorl	%eax, %eax
	callq	*%rbx
	testl	%eax, %eax
	je	.LBB1_1
	movabsq	$_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29, %rax
	cmpq	$0, (%rax)
	je	.LBB1_4
	movq	24(%rsp), %rdi
	movabsq	$PyNumber_Float, %rax
	callq	*%rax
	movq	%rax, %rbx
	movabsq	$PyFloat_AsDouble, %rax
	movq	%rbx, %rdi
	callq	*%rax
	vmovsd	%xmm0, 16(%rsp)
	movabsq	$Py_DecRef, %rax
	movq	%rbx, %rdi
	callq	*%rax
	movabsq	$PyErr_Occurred, %rax
	callq	*%rax
	testq	%rax, %rax
	jne	.LBB1_1
	vmovsd	16(%rsp), %xmm0
	vaddsd	%xmm0, %xmm0, %xmm0
	movabsq	$.LCPI1_0, %rax
	vmovsd	(%rax), %xmm1
	vaddsd	%xmm1, %xmm0, %xmm0
	vaddsd	%xmm1, %xmm0, %xmm0
	movabsq	$PyFloat_FromDouble, %rax
	callq	*%rax
	addq	$48, %rsp
	.cfi_def_cfa_offset 16
	popq	%rbx
	.cfi_def_cfa_offset 8
	retq
.LBB1_4:
	.cfi_def_cfa_offset 64
	movabsq	$PyExc_RuntimeError, %rdi
	movabsq	$".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", %rsi
	movabsq	$PyErr_SetString, %rax
	callq	*%rax
.LBB1_1:
	xorl	%eax, %eax
	addq	$48, %rsp
	.cfi_def_cfa_offset 16
	popq	%rbx
	.cfi_def_cfa_offset 8
	retq
.Lfunc_end1:
	.size	_ZN7cpython8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29, .Lfunc_end1-_ZN7cpython8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29
	.cfi_endproc

	.type	_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,@object
	.comm	_ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29,8,8
	.type	.const.func2,@object
	.section	.rodata,"a",@progbits
.const.func2:
	.asciz	"func2"
	.size	.const.func2, 6

	.type	".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29",@object
	.p2align	4
".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29":
	.asciz	"missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29"
	.size	".const.missing Environment: _ZN08NumbaEnv8__main__9func2$242EdN21omitted$28default$3d15_0$29E24omitted$28default$3d1$29", 113

	.section	".note.GNU-stack","",@progbits

================================================================================

```
</details>
user: CalebBell
labels: performance: performance related issue
issue_6169: state: open
title: Compilation is slower with overload_method than jitclasses for similar functionality
body: Performance issue added per @sklam suggestion

jicclass code faster than overload_method example bellow:

```
from numba import typed, typeof, njit, int64, types, optional, deferred_type
from numba.experimental import jitclass
from numba.extending import overload_method, overload

BagType = deferred_type()

spec = [
    ('max_length', int64),
    ('data', types.ListType(int64)),
    ('child', optional(BagType))
]

@jitclass(spec)
class Bag(object):
    def __init__(self, max_length):
        
        self.max_length = max_length
        self.data = typed.List.empty_list(int64)
        self.child = None
        
    def child_insert(self, value):
        if len(self.data) < self.max_length:
            self.data.append(value)        

    def insert(self, value):
        if len(self.data) < self.max_length:
            self.data.append(value)
        else:
            # self.get_child(self.child, value)
            if self.child is not None:
                # self.child.insert(value) 
                self.child.child_insert(value) # eliminate recursion
            else:
                self.child = Bag(self.max_length) #self.add_child()  
        
    def add_child(self):
        return Bag(self.max_length)

BagType.define(Bag.class_type.instance_type)

@njit
def test():
    mybag = Bag(5)

    print(mybag.data)
    print(mybag.child)

    for i in range(10):
        mybag.insert(i)

    print(mybag.data)
    print(mybag.child)
    print(mybag.child.data)
    
test()
```

slower than similar code implemented with jitclass:

```
from numba import typed, typeof, njit, int64, types, optional, deferred_type
from numba.experimental import jitclass
from numba.extending import overload_method, overload

BagType = deferred_type()

spec = [
    ('max_length', int64),
    ('data', types.ListType(int64)),
    ('child', optional(BagType))
]

@jitclass(spec)
class Bag(object):
    def __init__(self, max_length):
        
        self.max_length = max_length
        self.data = typed.List.empty_list(int64)
        self.child = None

BagType.define(Bag.class_type.instance_type)

@overload_method(types.misc.ClassInstanceType, 'child_insert')
def ol_bag_add_child_insert(inst, value):
    if inst is Bag.class_type.instance_type:
        def impl(inst, value):
            if len(inst.data) < inst.max_length:
                inst.data.append(value)
            
        return impl

@overload_method(types.misc.ClassInstanceType, 'insert')
def ol_bag_insert(self, value):
    if self is Bag.class_type.instance_type:
        def impl(self, value):
            print('insert ' + str(value))

            # eliminate recursion here by implementing a fake stack
            stack = typed.List()
            stack.append((self, value))

            while len(stack):
                node = stack[0][0]
                value = stack[0][1]
                stack.pop(0)

                if len(node.data) < node.max_length:
                    node.data.append(value)
                else:
                    if node.child is None:
                        node.child = Bag(node.max_length - 1) #self.add_child() # this works too
                    else:
                        print('child insert')
                        stack.append((node.child, value))
                        # self.child.child_insert(value) # this will work as well because we eliminated the recursion

        return impl

@overload_method(types.misc.ClassInstanceType, 'add_child')
def ol_bag_add_child(inst,):
    if inst is Bag.class_type.instance_type:
        def impl(inst,):
            print('add_child')
            return Bag(inst.max_length - 1)
            
        return impl

@njit
def test():
    mybag = Bag(5)

    print(mybag.data)
    print(mybag.child)

    for i in range(10):
        mybag.insert(i)

    print(mybag.data)
    print(mybag.child)
    print(mybag.child.data)
    
test()
```

user: rpopovici
labels: performance: performance related issue
issue_6160: state: open
title: Equivalent page to "Numba Performance Tips" but for GPU targets.
body: ## Feature request

A page like https://numba.readthedocs.io/en/stable/user/performance-tips.html but with GPUs in mind. To consider basics like copying data, device arrays, synchronisation, measurement, float32 vs float64 etc. Also what happens in `guvectorize` and` vectorize` cases.

CC @gmarkall 
user: stuartarchibald
labels: CUDA: CUDA related issue/PR
ROC: ROC related issue/PR
issue_6159: state: open
title: guvectorize with cuda target is extremely slow
body: I am trying to use guvectorize with cuda target. The result is not what I expected. Processig 100Mb of data takes 8s. 
I have a GTX 1070 with 8Gb of RAM. Cuda toolkit installed is 10.2 on windows 10. I tried the official build 0.51 and latest master as well with the same outcome. 

nb.cuda.detect() result
```
Found 1 CUDA devices
id 0     b'GeForce GTX 1070'                              [SUPPORTED]
                      compute capability: 6.1
                           pci device id: 0
                              pci bus id: 1
Summary:
	1/1 devices are supported
```

Example code:
```
import numpy as np
import numba as nb
from numba import jit, njit, vectorize, guvectorize, typeof, prange
from numba.types import float32
from numba import cuda

a = np.random.rand(1024 * 1024 * 32).astype('float32')
b = np.random.rand(1024 * 1024 * 32).astype('float32')
dist = np.zeros(a.shape[0]).astype('float32')

@guvectorize(['void(float32[:], float32[:], float32[:])'], '(n),(n)->(n)', nopython=True, target='cuda')
def numba_dist_cuda(a, b, dist):
    len = a.shape[0]
    for i in range(len):
        dist[i] = a[i] * b[i]

nb.cuda.detect()
print(nb.cuda.is_available())

import time
t = time.time()

numba_dist_cuda(a, b, dist)

elapsed = time.time() - t
print(elapsed)
```

user: rpopovici
labels: CUDA: CUDA related issue/PR
performance: performance related issue
issue_6158: state: open
title: np.arange seems to not support dtype='datetime64[M]'
body: I encountered a error when translating numpy code to numba. The issue seems to be in np.arange with  dtype='datetime64[M]'

```
import calendar
import numpy as np
from numba import njit

@njit
def payment_dates(start=None, end=None):
    
    month_range = np.arange(start, end, 1, dtype='datetime64[M]')
    start_day = 15
    year = month_range.astype('datetime64[Y]').astype(np.int64) + 1970
    month = month_range.astype('datetime64[M]').astype(np.int64) % 12 + 1
    month_day = np.array([calendar.monthrange(year[i],month[i])[1] for i in range(len(year))],dtype=np.int64)
    month_day[start_day < month_day] = start_day
    
    return month_day
    

start = np.datetime64('2019-12-31')
end = np.datetime64('2032-12-31')

payment_dates(start,end)

```

```
TypingError: No implementation of function Function(<built-in function arange>) found for signature:
 
arange(unicode_type, unicode_type, Literal[int](1), Literal[str](datetime64[M]))
 
There are 2 candidate implementations:
      - Of which 2 did not match due to:
      Overload of function 'arange': File: numba\np\arrayobj.py: Line 3842.
        With argument(s): '(unicode_type, unicode_type, int64, unicode_type)':
       No match.

During: resolving callee type: Function(<built-in function arange>)
During: typing of call at <ipython-input-580-e7c9c1caf3df> (4)
```
user: zacqed
issue_6118: state: open
title: support `np.expand_dims` second tuple argument 
body: ## Feature request

At the moment `expand_dims` supports only an int as second argument. The numpy implementation also supports a tuple of ints. 

Currently, in order to expand by multiple new axes (as `np.newaxis` and `None` are not supported) one needs to nest several calls to `expand_dims`.
user: ziofil
issue_6113: state: open
title: Fine-tuning of calling external function pointer
body: From conversation at: https://gitter.im/numba/numba-dev?at=5f31aaced4bc1a71bc90ba0c

Calling external function pointer like below:

```python
import ctypes
from numba import njit


@ctypes.CFUNCTYPE(None)
def foo():
    pass


@njit
def example():
    foo()


example()
print(example.inspect_asm(example.signatures[0]))
```
emits assembly like this:
```asm
    movabsq    $_numba.dynamic.globals.10dfd0f60, %rax
    callq    *(%rax)


_numba.dynamic.globals.10dfd0f60:
    .quad    4529655648
```
There are two instructions for the call. However, clang can do it in one instruction: https://godbolt.org/z/ofPP4o.

There maybe a potential 10% performance gain if we optimize this.


user: sklam
labels: performance: performance related issue
good second issue: A good issue for second time contributors
issue_6112: state: open
title: CUDA: Make block, thread, and warp indices unsigned.
body: **EDIT**: All the changes in this PR excepting actually making indices unsigned are in PR #6127 for a separate, simpler review.

**Original comments:**

The main purpose of this PR is to make thread, block, and warp indices unsigned, in line with CUDA C / C++. This results in slightly
more efficient code using fewer instructions in some cases due to the reduction in operations relating to signedness.

There are several other required changes to support this bundled into this PR:

- Synchronization of warps in reductions. The reduction kernels make an assumption that writes to shared memory by threads in a warp are automatically visible to other threads in the warp. On Volta and beyond, this is no longer true. This is fixed by adding `syncwarp()` at appropriate points in the reduction kernel. Originally I used a partial mask containing only the threads currently participating in the reduction, but this is only supported on CC 7.0 and above, so I've left it as a potential future optimization to be applied only on CC >= 7.0 devices.
- Addition of the `syncwarp()` function with no arguments, which assumes a full mask. This was not essential, but provides a nicer interface than always having to write `syncwarp(0xFFFFFFFF)`. Some tests for `syncwarp()` are also added.
- Require CUDA 9.0. `syncwarp()` etc. were only introduced in CUDA 9.0, and dropping CUDA 8.0 seems reasonable at this point in time.
- Small fixes to the code in `nvvm.py` that checks the supported compute capabilities, and addition of an error when one attempts to use an unspported NVVM version, alongside a warning at import time for `numba.cuda` that fires if an unsupported version is detected.

For more detailed comments, see individual commit messages.
user: gmarkall
labels: 4 - Waiting on author: Waiting for author to respond to review
CUDA: CUDA related issue/PR
issue_6108: state: open
title: TBB can't be loaded
body: ## Reporting a bug

- [x] I have tried using the latest released version of Numba (most recent is visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG). **The changelog refers to a 0.51 release, but the release date is tomorrow so I assume it is still being prepared).**
- [x] I have included below a minimal working reproducer (if you are unsure how to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I am still experiencing the problem I first described in #5371. I have installed `numba` and `tbb` via pip. Numba reports that TBB is available:
```
$ numba -s | grep TBBBB
TBB Threading Layer Available                 : True
+-->TBB imported successfully.
```

However, when trying to run this code:
```python
#!/usr/bin/env python
import numpy as np
import numba
numba.config.THREADING_LAYER = 'safe'

@numba.jit(nopython=True, parallel=True)
def add(a, b):
    for i in numba.prange(len(a)):
        a[i] += b[i]


a = np.ones(4)
b = np.ones(4)
add(a, b)
print(a)
```

I get this error:
```
Traceback (most recent call last):
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/errors.py", line 745, in new_error_context
    yield
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/lowering.py", line 273, in lower_block
    self.lower_inst(inst)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/lowering.py", line 486, in lower_inst
    func(self, inst)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/parfors/parfor_lowering.py", line 271, in _lower_parfor_parallel
    call_parallel_gufunc(
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/parfors/parfor_lowering.py", line 1398, in call_parallel_gufunc
    _launch_threads()
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/np/ufunc/parallel.py", line 486, in _launch_threads
    raise_with_hint(requirements)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/np/ufunc/parallel.py", line 431, in raise_with_hint
    raise ValueError(errmsg % hint)
ValueError: No threading layer could be loaded.
HINT:
Intel TBB is required, try:
$ conda/pip install tbb

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "tbbtest.py", line 14, in <module>
    add(a, b)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 434, in _compile_for_args
    raise e
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 367, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 808, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 78, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 92, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/dispatcher.py", line 105, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler.py", line 603, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler.py", line 339, in compile_extra
    return self._compile_bytecode()
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler.py", line 401, in _compile_bytecode
    return self._compile_core()
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler.py", line 381, in _compile_core
    raise e
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler.py", line 372, in _compile_core
    pm.run(self.state)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 341, in run
    raise patched_exception
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 332, in run
    self._runPass(idx, pass_inst, state)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 291, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 264, in check
    mangled = func(compiler_state)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/typed_passes.py", line 442, in run_pass
    NativeLowering().run_pass(state)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/typed_passes.py", line 370, in run_pass
    lower.lower()
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/lowering.py", line 179, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/lowering.py", line 233, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/lowering.py", line 259, in lower_function_body
    self.lower_block(block)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/lowering.py", line 273, in lower_block
    self.lower_inst(inst)
  File "/usr/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/errors.py", line 752, in new_error_context
    reraise(type(newerr), newerr, tb)
  File "/home/bmerry/work/sdp/env3/lib/python3.8/site-packages/numba/core/utils.py", line 81, in reraise
    raise value
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
No threading layer could be loaded.
HINT:
Intel TBB is required, try:
$ conda/pip install tbb

File "tbbtest.py", line 8:
def add(a, b):
    for i in numba.prange(len(a)):
    ^

During: lowering "id=0[LoopNest(index_variable = parfor_index.4, range = (0, a_size0.1, 1))]{18: <ir.Block at tbbtest.py (8)>}Var(parfor_index.4, tbbtest.py:8)" at tbbtest.py (8)
```

Full output of `numba -s`:
```
__Time Stamp__
Report started (local time)                   : 2020-08-11 09:53:47.260933
UTC start time                                : 2020-08-11 07:53:47.261020
Running time (s)                              : 0.497355

__Hardware Information__
Machine                                       : x86_64
CPU Name                                      : skylake
CPU Count                                     : 8
Number of accessible CPUs                     : 8
List of accessible CPUs cores                 : 0 1 2 3 4 5 6 7
CFS Restrictions (CPUs worth of runtime)      : None

CPU Features                                  : 64bit adx aes avx avx2 bmi bmi2
                                                clflushopt cmov cx16 cx8 f16c fma
                                                fsgsbase fxsr invpcid lzcnt mmx
                                                movbe mpx pclmul popcnt prfchw
                                                rdrnd rdseed sahf sgx sse sse2
                                                sse3 sse4.1 sse4.2 ssse3 xsave
                                                xsavec xsaveopt xsaves

Memory Total (MB)                             : 32065
Memory Available (MB)                         : 27934

__OS Information__
Platform Name                                 : Linux-5.4.0-42-generic-x86_64-with-glibc2.29
Platform Release                              : 5.4.0-42-generic
OS Name                                       : Linux
OS Version                                    : #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020
OS Specific Version                           : ?
Libc Version                                  : glibc 2.31

__Python Information__
Python Compiler                               : GCC 9.3.0
Python Implementation                         : CPython
Python Version                                : 3.8.2
Python Locale                                 : en_GB.UTF-8

__LLVM Information__
LLVM Version                                  : 9.0.1

__CUDA Information__
CUDA Device Initialized                       : True
CUDA Driver Version                           : 11000
CUDA Detect Output:
Found 1 CUDA devices
id 0     b'GeForce GTX 1070'                              [SUPPORTED]
                      compute capability: 6.1
                           pci device id: 0
                              pci bus id: 1
Summary:
	1/1 devices are supported

CUDA Librairies Test Output:
Finding cublas from System
	named  libcublas.so.11.1.0.229
	trying to open library...	ok
Finding cusparse from System
	named  libcusparse.so.11.1.0.218
	trying to open library...	ok
Finding cufft from System
	named  libcufft.so.10.2.0.218
	trying to open library...	ok
Finding curand from System
	named  libcurand.so.10.2.1.218
	trying to open library...	ok
Finding nvvm from System
	named  libnvvm.so.3.3.0
	trying to open library...	ok
Finding libdevice from System
	searching for compute_20...	ok
	searching for compute_30...	ok
	searching for compute_35...	ok
	searching for compute_50...	ok


__ROC information__
ROC Available                                 : False
ROC Toolchains                                : None
HSA Agents Count                              : 0
HSA Agents:
None
HSA Discrete GPUs Count                       : 0
HSA Discrete GPUs                             : None

__SVML Information__
SVML State, config.USING_SVML                 : False
SVML Library Loaded                           : False
llvmlite Using SVML Patched LLVM              : True
SVML Operational                              : False

__Threading Layer Information__
TBB Threading Layer Available                 : True
+-->TBB imported successfully.
OpenMP Threading Layer Available              : False
+--> Disabled due to Unknown import problem.
Workqueue Threading Layer Available           : True
+-->Workqueue imported successfully.

__Numba Environment Variable Information__
None found.

__Conda Information__
Conda not available.

__Installed Packages__
Package                         Version                                      Location
------------------------------- -------------------------------------------- ----------------------------------------------
addict                          2.2.1
aioconsole                      0.2.1
aiohttp                         3.6.2
aiohttp-jinja2                  1.2.0
aiokatcp                        0.8.1.dev265+master.ebd139e                  /home/bmerry/work/sdp/git/aiokatcp
aiomonitor                      0.4.5
aioredis                        1.3.1
aioresponses                    0.6.4
aiozk                           0.26.0
alabaster                       0.7.12
ansible                         2.9.11
ansicolors                      1.1.8
APLpy                           2.0.3
appdirs                         1.4.3
argon2-cffi                     20.1.0
astLib                          0.11.4
astro-kittens                   1.4.3
astro-tigger                    1.5.0
astro-tigger-lsm                1.6.0
astroid                         2.4.2
astropy                         4.0.1.post1
astropy-healpix                 0.5
async-timeout                   3.0.1
asynctest                       0.13.0
attrs                           19.3.0
Babel                           2.8.0
backcall                        0.2.0
bcrypt                          3.1.7
bleach                          3.1.5
bokeh                           2.1.1
boto                            2.49.0
botocore                        1.17.38
breathe                         4.19.2
Brotli                          1.0.7
CacheControl                    0.12.6
cached-property                 1.5.1
certifi                         2019.11.28
cffi                            1.14.1
cfgv                            3.2.0
chardet                         3.0.4
cityhash                        0.2.3.post9
click                           7.1.2
cloudpickle                     1.5.0
colorama                        0.4.3
configparser                    5.0.0
contextlib2                     0.6.0
coverage                        5.2.1
cryptography                    3.0
cycler                          0.10.0
Cython                          0.29.21
dash                            1.14.0
dash-core-components            1.10.2
dash-dangerously-set-inner-html 0.0.2
dash-html-components            1.0.3
dash-renderer                   1.6.0
dash-table                      4.9.0
dask                            2.22.0
decorator                       4.4.2
defusedxml                      0.6.0
distlib                         0.3.1
distributed                     2.22.0
distro                          1.5.0
docker                          4.2.2
docker-compose                  1.26.2
dockerpty                       0.4.1
docopt                          0.6.2
docutils                        0.15.2
entrypoints                     0.3
ephem                           3.7.7.0
fakeredis                       1.4.2
filelock                        3.0.12
flake8                          3.8.3
Flask                           1.1.2
Flask-Compress                  1.5.0
future                          0.18.2
graphviz                        0.14.1
h5py                            2.10.0
HeapDict                        1.0.1
hiredis                         1.1.0
html5lib                        1.0.1
http-parser                     0.9.0
humanfriendly                   8.2
identify                        1.4.25
idna                            2.8
imageio                         2.9.0
imagesize                       1.2.0
iniconfig                       1.0.1
ipaddr                          2.2.0
ipdb                            0.13.3
ipdbplugin                      1.5.0
ipykernel                       5.3.4
ipython                         7.17.0
ipython-genutils                0.2.0
ipywidgets                      7.5.1
isort                           4.3.21
itsdangerous                    1.1.0
jedi                            0.17.2
jeepney                         0.4.3
Jinja2                          2.11.2
jmespath                        0.10.0
joblib                          0.16.0
jsonschema                      3.2.0
jupyter                         1.0.0
jupyter-client                  6.1.6
jupyter-console                 6.1.0
jupyter-core                    4.6.3
katcbfsim                       0.1.dev372+master.139cf02                    /home/bmerry/work/sdp/git/katcbfsim
katdal                          0.16.dev1411+master.4898eaf                  /home/bmerry/work/sdp/git/katdal
katpoint                        0.10.dev454+master.65f7a18                   /home/bmerry/work/sdp/git/katpoint
katportalclient                 0.2.2
katsdpcal                       0.1.dev1625+master.72cd55c                   /home/bmerry/work/sdp/git/katsdpcal
katsdpcontroller                0.1.dev2163+master.57f0782                   /home/bmerry/work/sdp/git/katsdpcontroller
katsdpdatawriter                0.1.dev246+master.f4bc4ff                    /home/bmerry/work/sdp/git/katsdpdatawriter
katsdpimager                    1.4.dev881+profiling.ffa79ba8                /home/bmerry/work/sdp/git/katsdpimager
katsdpingest                    0.1.dev1722+no.telstate.delays.9d84381.dirty /home/bmerry/work/sdp/git/katsdpingest
katsdpmetawriter                0.1.dev91+master.b2e5d22                     /home/bmerry/work/sdp/git/katsdpmetawriter/src
katsdpmodels                    0.1.dev122+master.0431f9b                    /home/bmerry/work/sdp/git/katsdpmodels/src
katsdpservices                  1.1.dev106+telstate.endpoint.55198aa         /home/bmerry/work/sdp/git/katsdpservices
katsdpsigproc                   1.2.dev724+master.e55b1b0                    /home/bmerry/work/sdp/git/katsdpsigproc
katsdptelstate                  0.11.dev519+memory.monitor.93dc68d           /home/bmerry/work/sdp/git/katsdptelstate
katversion                      1.1
kazoo                           2.8.0
keyring                         21.3.0
kiwisolver                      1.2.0
lazy-object-proxy               1.4.3
linecache2                      1.0.0
llvmlite                        0.33.0
lockfile                        0.12.2
lupa                            1.9
Mako                            1.1.3
manhole                         1.6.0
MarkupSafe                      1.1.1
matplotlib                      3.3.0
mccabe                          0.6.1
mistune                         0.8.4
mock                            4.0.2
more-itertools                  8.4.0
msgpack                         0.6.2
multidict                       4.7.6
mypy                            0.782
mypy-extensions                 0.4.3
nbconvert                       5.6.1
nbformat                        5.0.7
netifaces                       0.10.9
networkx                        2.4
nodeenv                         1.4.0
nose                            1.3.7
nose-ignore-docstring           0.2
notebook                        6.1.1
ntsh                            1.1
numba                           0.50.1
numpy                           1.19.1
omnijson                        0.1.2
open-mock-file                  1.0.2
packaging                       20.3
pandas                          1.1.0
pandocfilters                   1.4.2
paramiko                        2.7.1
parso                           0.7.1
pep517                          0.8.2
pexpect                         4.8.0
pickleshare                     0.7.5
Pillow                          7.2.0
pip                             20.2.1
pkg-resources                   0.0.0
pkgconfig                       1.5.1
pkginfo                         1.5.0.1
plotly                          4.9.0
pluggy                          0.13.1
pre-commit                      2.6.0
progress                        1.5
prometheus-async                19.2.0
prometheus-client               0.3.1
prompt-toolkit                  3.0.5
psutil                          5.7.2
ptyprocess                      0.6.0
py                              1.9.0
py3nvml                         0.2.6
PyAVM                           0.9.5
pybind11                        2.5.0
pycodestyle                     2.6.0
pycparser                       2.20
pycuda                          2019.1.2
pydotplus                       2.0.2
pyephem                         3.7.7.0
pyflakes                        2.2.0
pygelf                          0.3.6
Pygments                        2.6.1
PyJWT                           1.7.1
pylint                          2.5.3
pymesos                         0.3.15
PyNaCl                          1.4.0
pyopencl                        2020.2
pyparsing                       2.4.6
pyregion                        2.0
pyrsistent                      0.16.0
pytest                          6.0.1
pytest-asyncio                  0.14.0
pytest-cov                      2.10.0
pytest-forked                   1.3.0
pytest-mock                     3.2.0
python-casacore                 3.3.1
python-dateutil                 2.8.1
python-dotenv                   0.14.0
python-lzf                      0.2.4
pytoml                          0.1.21
pytools                         2020.3.1
pytz                            2020.1
PyWavelets                      1.1.1
PyYAML                          5.3.1
pyzmq                           19.0.2
qtconsole                       4.7.5
QtPy                            1.9.0
rdbtools                        0.1.15
readme-renderer                 26.0
redis                           3.5.3
reproject                       0.7.1
requests                        2.22.0
requests-toolbelt               0.9.1
responses                       0.10.16
retrying                        1.3.3
rfc3986                         1.4.0
rfc3987                         1.3.8
scikit-cuda                     0.5.3
scikit-image                    0.17.2
scikits.fitting                 0.7
scipy                           1.5.2
SecretStorage                   3.1.2
Send2Trash                      1.5.0
setuptools                      49.2.1
setuptools-git                  1.2
Shapely                         1.7.0
six                             1.14.0
snowballstemmer                 2.0.0
sortedcontainers                2.2.2
spead2                          2.1.1                                        /home/bmerry/work/sdp/git/spead2
Sphinx                          3.1.2
sphinx-rtd-theme                0.5.0
sphinxcontrib-applehelp         1.0.2
sphinxcontrib-devhelp           1.0.2
sphinxcontrib-htmlhelp          1.0.3
sphinxcontrib-jsmath            1.0.1
sphinxcontrib-qthelp            1.0.3
sphinxcontrib-serializinghtml   1.1.4
SQLAlchemy                      1.3.18
strict-rfc3339                  0.7
tbb                             2020.0.133
tblib                           1.7.0
terminado                       0.8.3
terminaltables                  3.1.0
testpath                        0.4.4
texttable                       1.6.2
tifffile                        2020.7.24
toml                            0.10.1
toolz                           0.10.0
tornado                         6.0.4
tqdm                            4.48.2
traceback2                      1.4.0
traitlets                       4.3.3
twine                           3.2.0
typed-ast                       1.4.1
typing-extensions               3.7.4.2
ujson                           3.1.0
unittest2                       1.1.0
urllib3                         1.25.10
virtualenv                      20.0.30
wcwidth                         0.2.5
webencodings                    0.5.1
websocket-client                0.57.0
Werkzeug                        1.0.1
wheel                           0.34.2
widgetsnbextension              3.5.1
wrapt                           1.12.1
xmltodict                       0.12.0
yarl                            1.5.1
zict                            2.0.0

No errors reported.


__Warning log__
Warning (roc): Error initialising ROC: No ROC toolchains found.
Warning (roc): No HSA Agents found, encountered exception when searching: Error at driver init: 
NUMBA_HSA_DRIVER /opt/rocm/lib/libhsa-runtime64.so is not a valid file path.  Note it must be a filepath of the .so/.dll/.dylib or the driver:
Warning: Conda not available.
 Error was [Errno 2] No such file or directory: 'conda'
```
user: bmerry
labels: wheels: Issue with wheels
issue_6104: state: open
title: Numba can't properly match ListType of Arrays in function signature 
body: Let's start right away with a reproducer, because i'm not sure of how to properly describe this kind of behavior. Let's say I want a function that takes a list of arrays as an input (because these arrays might have varying lengths):

```python
@nb.njit(nb.float32[:](nb.types.ListType(nb.float32[:])))
def f(list_of_arrays: List[np.ndarray]):
    return list_of_arrays[0]

r = np.random.random(10).astype(np.float32)
f(nb.typed.List([r, r, r]))
```

If we actually display the function's signature before running, we get 
```
(ListType[array(float32, 1d, A)],) -> array(float32, 1d, A)
```

So far, so good. However, this code raises a `TypeError: No matching definition for argument type(s) ListType[array(float32, 1d, C)]`. Yet,  you can obviously see that the argument types listed in the error are a subtype of the function's argument signature (the `array(float32, 1d, A)` type should match both `array(float32, 1d, C)` and `array(float32, 1d, F)` array types).

To try and have this working again, the "trick" is to force the layout of the array inside of the `ListType` to contiguous (C): 

```python
@nb.njit(nb.float32[:](nb.types.ListType(nb.float32[::1]))) # <--- array is now of type array(float32, 1d, C)
def f(list_of_arrays: List[np.ndarray]):
    return list_of_arrays[0]

r = np.random.random(10).astype(np.float32)
f(nb.typed.List([r, r, r]))
```

This works fine, but this is an unexpected (and very confusing) behavior.

I'm using numba 0.50.1 on Ubuntu 18.04, in a regular python 3.6 venv.
user: hadware
issue_6091: state: open
title: Applying numba.typed.List to a nested Python list doesn't result in a nested typed-list
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

Instead, it turns into a reflected list.

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I'm copy-pasting the example reported by @esc in https://github.com/numba/numba/pull/6090#discussion_r466328283:
```
In [4]: List([[1, 2, 3], [4, 5, 6]])
Out[4]: ListType[reflected list(int64)<iv=None>]([[4892186944], [<IPython.lib.pretty.Group object at 0x124ad7040>, <IPython.lib.pretty.Group object at 0x124934cd0>]])
```

Additionally, there is a segmentation fault when the reflected list is assigned to a Python variable.
```
In [6]: l = List([[1, 2, 3], [4, 5, 6]])
/Users/vhaenel/git/numba/numba/typed/typedlist.py:66: NumbaPendingDeprecationWarning:
Encountered the use of a type that is scheduled for deprecation: type 'reflected list' found for argument 'item' of function 'impl_append.<locals>.impl'.

For more information visit https://numba.pydata.org/numba-doc/latest/reference/deprecation.html#deprecation-of-reflection-for-list-and-set-types

File "numba/typed/listobject.py", line 596:

    def impl(l, item):
    ^

  l.append(item)
/Users/vhaenel/git/numba/numba/core/ir_utils.py:2031: NumbaPendingDeprecationWarning:
Encountered the use of a type that is scheduled for deprecation: type 'reflected list' found for argument 'item' of function '_append'.

For more information visit https://numba.pydata.org/numba-doc/latest/reference/deprecation.html#deprecation-of-reflection-for-list-and-set-types

File "numba/typed/typedlist.py", line 65:
@njit
def _append(l, item):
^

  warnings.warn(NumbaPendingDeprecationWarning(msg, loc=loc))

In [7]: l
Out[7]: [1]    46853 segmentation fault (core dumped)  ipython
```
user: rht
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_6077: state: open
title: StructRef initialization SIGABRT while using types.deferred_type
body: While I was trying to use the deferred_type with StructRefs the execution gets stuck, infinite loop or something


```
import numba as nb
from numba import njit, types, typed, float64, int64
from numba.core import types
from numba.experimental import structref
from numba.core.extending import overload_method

@structref.register
class VectorStructType(types.StructRef):
    def preprocess_fields(self, fields):
        return tuple((name, types.unliteral(typ)) for name, typ in fields)

class VectorStruct(structref.StructRefProxy):
    def __new__(cls, x, y, z):
        return structref.StructRefProxy.__new__(cls, x, y, z)

    @property
    def x(self):
        return VectorStruct_get_x(self)

    @property
    def y(self):
        return VectorStruct_get_y(self)

    @property
    def z(self):
        return VectorStruct_get_z(self)

@njit
def VectorStruct_get_x(self):
    return self.x

@njit
def VectorStruct_get_y(self):
    return self.y

@njit
def VectorStruct_get_z(self):
    return self.z

structref.define_proxy(VectorStruct, VectorStructType, ["x", "y", "z"])

vector_struct_type = VectorStructType(fields=(('x', float64), ('y', float64),
                                              ('z', float64)))

PolygonTypeDeferred = types.deferred_type()
@structref.register
class PolygonStructType(types.StructRef):
    def preprocess_fields(self, fields):
        return tuple([
            ('vertices', types.Optional(types.ListType(vector_struct_type))),
            ('parent', types.Optional(PolygonTypeDeferred)),
            ])

class PolygonStruct(structref.StructRefProxy):
    def __new__(cls, vertices, parent):
        return structref.StructRefProxy.__new__(cls, vertices, parent)

    @property
    def vertices(self):
        return PolygonStruct_get_vertices(self)

    @property
    def parent(self):
        return PolygonStruct_get_parent(self)

@njit
def PolygonStruct_get_vertices(self):
    return self.vertices

@njit
def PolygonStruct_get_parent(self):
    return self.parent

structref.define_proxy(PolygonStruct, PolygonStructType, ["vertices", "parent"])

PolygonType_inst = PolygonStructType(fields=(('vertices', types.Optional(types.ListType(vector_struct_type))), ('parent', types.Optional(PolygonTypeDeferred))))
PolygonTypeDeferred.define(PolygonType_inst)

@overload_method(PolygonStructType, "flip")
def PolygonStruct_flip(self):
    def impl(self):
        if self.vertices is not None:
            ref = self.vertices[0]
            ref.x = -ref.x
    return impl

@njit
def test():
    lst = typed.List.empty_list(vector_struct_type)
    lst.append(VectorStruct(1.0, 2.0, 3.0))
    lst[0].x = 5.0

    print('before')
    p = PolygonStruct(None, None)
    p.flip()
    p.vertices = lst
    p.flip()
    print('after')
    return p

print('start')
y = test()
print(y.vertices[0].x)
print('end')
```
user: rpopovici
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_6067: state: open
title: Failure to spot runaway recursion
body: - [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).
```python
from numba import njit

@njit
def foo(pred=False):
    if pred:
        return foo(7.)
    return 8.

print(foo(True))
```
segfaults, likely stack overflow.
user: stuartarchibald
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_6065: state: open
title: Size Match AssertionError in Numba parallelization 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I have a code in which I try to get the embeddings of a bag of tokens given the embeddings of tokens:
```
@nb.njit(nb.float32[:,:](nb.int32[:],nb.float32[:],nb.int32[:],nb.float32[:,:]), parallel=True)
def _compute_doc_embeddings2(indices, data, indptr, vocab_embeddings):
    m = len(indptr) - 1
    
    embs = np.zeros((m, vocab_embeddings.shape[1]), dtype=np.float32)
    for i in nb.prange(m):
        _indices = indices[indptr[i]: indptr[i + 1]]
        _data = data[indptr[i]: indptr[i + 1]].copy()  # copy as nb requires contiguous

        embs[i, :] = np.sum(vocab_embeddings[_indices] * _data.reshape((-1, 1)), axis=0)
    
    return embs
```

This works fine if I don't do it in parallel mode. But when trying to do with the above code(in `parallel=True` and using `prange`), like below:
```
i = np.array([0,1,2,3], dtype=np.int32)
d = np.array([0.5,0.5,0.5,0.5], dtype=np.float32)
p = np.array([0,2,4], dtype=np.int32)
ve = np.array([[0.4,-0.4,0.5], [-0.4,0.4,-0.5], [0.6,-0.6,0.7], [-0.6,0.6,-0.7]], dtype=np.float32)

embs = _compute_doc_embeddings2(i, d, p, ve)
```
I get this error:
```
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-17-62efe4922c46> in <module>
      5 
      6 # embs = np.zeros((2, 3), dtype=np.float32)
----> 7 embs = _compute_doc_embeddings2(i, d, p, ve)

AssertionError: Sizes of $116binary_subscr.32, $124call_method.36 do not match on <ipython-input-16-bb6227693479> (10)
```

I am not able to decipher the error. I would appreciate any help. TIA.
user: DeepakSaini119
issue_6061: state: open
title: Setting cache=True with a recursive function results in Segmentation fault
body: 
- [x] I have tried using the latest released version of Numba
- [x] I have included below a minimal working reproducer

When using numba with a function that calls itself and caching is set to True, numba crashes hard when the cache is not empty (i.e. if the same file is ran twice).
In the minimal example below, the recursion can only ever happen to a depth of 1. I am happy with the workaround of disabling caching on functions with this issue, but I hope this is a bug report that the numba project finds useful.

```
import numba

@numba.njit(cache=True)
def temperature_effectiveness_plate(R1, NTU1, Np1, Np2, reverse=False):
    if Np1 == 1 and Np2 == 1:
        return 1.1
    if not reverse:
        R2 = 1./R1
        NTU2 = NTU1*R1
        P2 = temperature_effectiveness_plate(R1=R2, NTU1=NTU2, Np1=Np2, Np2=Np1,
                                             reverse=True)
        return 1.3
    raise ValueError('Supported number of passes does not have a formula available')

print(temperature_effectiveness_plate(R1=1/3., NTU1=1., Np1=1, Np2=1))
```

<details>
  <summary>Full output with NUMBA_DEBUG=1 on the second run (with the crash):</summary>

```
/home/caleb/.local/lib/python3.7/site-packages/numba/__init__.py:188: UserWarning: SVML was not found/could not be loaded.
  warnings.warn("SVML was not found/could not be loaded.")
================================================================================
--------------------------FUNCTION OPTIMIZED DUMP nrt---------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.139700511148704 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.139700511148704, i32 0, i32 0), i32 102 }
@.const.pickledata.139700511148704 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

define i64 @nrt_atomic_add(i64* %.1) {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

define i64 @nrt_atomic_sub(i64* %.1) {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = sub i64 %.4, 1
  ret i64 %.5
}

define i32 @nrt_atomic_cas(i64* %.1, i64 %.2, i64 %.3, i64* %.4) {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

define i8* @NRT_MemInfo_data_fast(i8* %.1) {
.3:
  %.4 = bitcast i8* %.1 to { i64, i8*, i8*, i8*, i64 }*
  %.5 = getelementptr { i64, i8*, i8*, i8*, i64 }, { i64, i8*, i8*, i8*, i64 }* %.4, i32 0, i32 3
  %.6 = load i8*, i8** %.5
  ret i8* %.6
}

; Function Attrs: noinline
define void @NRT_incref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.8 = call i64 @nrt_atomic_add(i64* %.7)
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif.if, %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.9 = call i64 @nrt_atomic_sub(i64* %.8)
  %.10 = icmp eq i64 %.9, 0
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  call void @NRT_MemInfo_call_dtor(i8* %.1)
  br label %.3.if
}

declare void @NRT_MemInfo_call_dtor(i8*)

define i32 @nrt_unresolved_abort(i8** %.1, { i8*, i32 }** %.2) {
.4:
  store { i8*, i32 }* @.const.picklebuf.139700511148704, { i8*, i32 }** %.2
  ret i32 1
}

attributes #0 = { noinline }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
-------------------------------OPTIMIZED DUMP nrt-------------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.139700511148704 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.139700511148704, i32 0, i32 0), i32 102 }
@.const.pickledata.139700511148704 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_add(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_sub(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, -1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i32 @nrt_atomic_cas(i64* nocapture %.1, i64 %.2, i64 %.3, i64* nocapture %.4) local_unnamed_addr #0 {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4, align 8
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

; Function Attrs: norecurse nounwind readonly
define i8* @NRT_MemInfo_data_fast(i8* nocapture readonly %.1) local_unnamed_addr #1 {
.3:
  %.5 = getelementptr i8, i8* %.1, i64 24
  %0 = bitcast i8* %.5 to i8**
  %.6 = load i8*, i8** %0, align 8
  ret i8* %.6
}

; Function Attrs: nofree noinline norecurse nounwind
define void @NRT_incref(i8* %.1) local_unnamed_addr #2 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw add i64* %.7, i64 1 monotonic
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) local_unnamed_addr #3 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: nofree norecurse nounwind writeonly
define i32 @nrt_unresolved_abort(i8** nocapture readnone %.1, { i8*, i32 }** nocapture %.2) local_unnamed_addr #4 {
.4:
  store { i8*, i32 }* @.const.picklebuf.139700511148704, { i8*, i32 }** %.2, align 8
  ret i32 1
}

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #5

attributes #0 = { nofree norecurse nounwind }
attributes #1 = { norecurse nounwind readonly }
attributes #2 = { nofree noinline norecurse nounwind }
attributes #3 = { noinline }
attributes #4 = { nofree norecurse nounwind writeonly }
attributes #5 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
----------------------------------ASSEMBLY nrt----------------------------------
	.text
	.file	"<string>"
	.globl	nrt_atomic_add
	.p2align	4, 0x90
	.type	nrt_atomic_add,@function
nrt_atomic_add:
	movl	$1, %eax
	lock		xaddq	%rax, (%rdi)
	incq	%rax
	retq
.Lfunc_end0:
	.size	nrt_atomic_add, .Lfunc_end0-nrt_atomic_add

	.globl	nrt_atomic_sub
	.p2align	4, 0x90
	.type	nrt_atomic_sub,@function
nrt_atomic_sub:
	movq	$-1, %rax
	lock		xaddq	%rax, (%rdi)
	decq	%rax
	retq
.Lfunc_end1:
	.size	nrt_atomic_sub, .Lfunc_end1-nrt_atomic_sub

	.globl	nrt_atomic_cas
	.p2align	4, 0x90
	.type	nrt_atomic_cas,@function
nrt_atomic_cas:
	movq	%rsi, %rax
	xorl	%esi, %esi
	lock		cmpxchgq	%rdx, (%rdi)
	sete	%sil
	movq	%rax, (%rcx)
	movl	%esi, %eax
	retq
.Lfunc_end2:
	.size	nrt_atomic_cas, .Lfunc_end2-nrt_atomic_cas

	.globl	NRT_MemInfo_data_fast
	.p2align	4, 0x90
	.type	NRT_MemInfo_data_fast,@function
NRT_MemInfo_data_fast:
	movq	24(%rdi), %rax
	retq
.Lfunc_end3:
	.size	NRT_MemInfo_data_fast, .Lfunc_end3-NRT_MemInfo_data_fast

	.globl	NRT_incref
	.p2align	4, 0x90
	.type	NRT_incref,@function
NRT_incref:
	testq	%rdi, %rdi
	je	.LBB4_1
	lock		incq	(%rdi)
	retq
.LBB4_1:
	retq
.Lfunc_end4:
	.size	NRT_incref, .Lfunc_end4-NRT_incref

	.globl	NRT_decref
	.p2align	4, 0x90
	.type	NRT_decref,@function
NRT_decref:
	.cfi_startproc
	testq	%rdi, %rdi
	je	.LBB5_2
	#MEMBARRIER
	lock		decq	(%rdi)
	je	.LBB5_3
.LBB5_2:
	retq
.LBB5_3:
	#MEMBARRIER
	movabsq	$NRT_MemInfo_call_dtor, %rax
	jmpq	*%rax
.Lfunc_end5:
	.size	NRT_decref, .Lfunc_end5-NRT_decref
	.cfi_endproc

	.globl	nrt_unresolved_abort
	.p2align	4, 0x90
	.type	nrt_unresolved_abort,@function
nrt_unresolved_abort:
	movabsq	$.const.picklebuf.139700511148704, %rax
	movq	%rax, (%rsi)
	movl	$1, %eax
	retq
.Lfunc_end6:
	.size	nrt_unresolved_abort, .Lfunc_end6-nrt_unresolved_abort

	.type	.const.picklebuf.139700511148704,@object
	.section	.rodata,"a",@progbits
	.p2align	3
.const.picklebuf.139700511148704:
	.quad	.const.pickledata.139700511148704
	.long	102
	.zero	4
	.size	.const.picklebuf.139700511148704, 16

	.type	.const.pickledata.139700511148704,@object
	.p2align	4
.const.pickledata.139700511148704:
	.ascii	"\200\004\225[\000\000\000\000\000\000\000\214\bbuiltins\224\214\fRuntimeError\224\223\224\2146numba jitted function aborted due to unresolved symbol\224\205\224N\207\224."
	.size	.const.pickledata.139700511148704, 102


	.section	".note.GNU-stack","",@progbits

================================================================================
[cache] index loaded from '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.nbi'
[cache] data loaded from '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.2.nbc'
/home/caleb/.local/lib/python3.7/site-packages/numba/core/codegen.py:309: UserWarning: Inspection disabled for cached code. Invalid result is returned.
  warnings.warn('Inspection disabled for cached code. '
================================================================================
-----------------OPTIMIZED DUMP temperature_effectiveness_plate-----------------
; ModuleID = 'temperature_effectiveness_plate'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

================================================================================
================================================================================
--------------------ASSEMBLY temperature_effectiveness_plate--------------------
	.text
	.file	"<string>"

	.section	".note.GNU-stack","",@progbits

================================================================================
Segmentation fault
```

</details>


<details>
  <summary>Full output with NUMBA_DEBUG=1 on the first run (without the crash):</summary>

```
/home/caleb/.local/lib/python3.7/site-packages/numba/__init__.py:188: UserWarning: SVML was not found/could not be loaded.
  warnings.warn("SVML was not found/could not be loaded.")
================================================================================
--------------------------FUNCTION OPTIMIZED DUMP nrt---------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.140612176063216 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.140612176063216, i32 0, i32 0), i32 102 }
@.const.pickledata.140612176063216 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

define i64 @nrt_atomic_add(i64* %.1) {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

define i64 @nrt_atomic_sub(i64* %.1) {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = sub i64 %.4, 1
  ret i64 %.5
}

define i32 @nrt_atomic_cas(i64* %.1, i64 %.2, i64 %.3, i64* %.4) {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

define i8* @NRT_MemInfo_data_fast(i8* %.1) {
.3:
  %.4 = bitcast i8* %.1 to { i64, i8*, i8*, i8*, i64 }*
  %.5 = getelementptr { i64, i8*, i8*, i8*, i64 }, { i64, i8*, i8*, i8*, i64 }* %.4, i32 0, i32 3
  %.6 = load i8*, i8** %.5
  ret i8* %.6
}

; Function Attrs: noinline
define void @NRT_incref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.8 = call i64 @nrt_atomic_add(i64* %.7)
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif.if, %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.9 = call i64 @nrt_atomic_sub(i64* %.8)
  %.10 = icmp eq i64 %.9, 0
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  call void @NRT_MemInfo_call_dtor(i8* %.1)
  br label %.3.if
}

declare void @NRT_MemInfo_call_dtor(i8*)

define i32 @nrt_unresolved_abort(i8** %.1, { i8*, i32 }** %.2) {
.4:
  store { i8*, i32 }* @.const.picklebuf.140612176063216, { i8*, i32 }** %.2
  ret i32 1
}

attributes #0 = { noinline }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
-------------------------------OPTIMIZED DUMP nrt-------------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.140612176063216 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.140612176063216, i32 0, i32 0), i32 102 }
@.const.pickledata.140612176063216 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_add(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_sub(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, -1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i32 @nrt_atomic_cas(i64* nocapture %.1, i64 %.2, i64 %.3, i64* nocapture %.4) local_unnamed_addr #0 {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4, align 8
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

; Function Attrs: norecurse nounwind readonly
define i8* @NRT_MemInfo_data_fast(i8* nocapture readonly %.1) local_unnamed_addr #1 {
.3:
  %.5 = getelementptr i8, i8* %.1, i64 24
  %0 = bitcast i8* %.5 to i8**
  %.6 = load i8*, i8** %0, align 8
  ret i8* %.6
}

; Function Attrs: nofree noinline norecurse nounwind
define void @NRT_incref(i8* %.1) local_unnamed_addr #2 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw add i64* %.7, i64 1 monotonic
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) local_unnamed_addr #3 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: nofree norecurse nounwind writeonly
define i32 @nrt_unresolved_abort(i8** nocapture readnone %.1, { i8*, i32 }** nocapture %.2) local_unnamed_addr #4 {
.4:
  store { i8*, i32 }* @.const.picklebuf.140612176063216, { i8*, i32 }** %.2, align 8
  ret i32 1
}

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #5

attributes #0 = { nofree norecurse nounwind }
attributes #1 = { norecurse nounwind readonly }
attributes #2 = { nofree noinline norecurse nounwind }
attributes #3 = { noinline }
attributes #4 = { nofree norecurse nounwind writeonly }
attributes #5 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
----------------------------------ASSEMBLY nrt----------------------------------
	.text
	.file	"<string>"
	.globl	nrt_atomic_add
	.p2align	4, 0x90
	.type	nrt_atomic_add,@function
nrt_atomic_add:
	movl	$1, %eax
	lock		xaddq	%rax, (%rdi)
	incq	%rax
	retq
.Lfunc_end0:
	.size	nrt_atomic_add, .Lfunc_end0-nrt_atomic_add

	.globl	nrt_atomic_sub
	.p2align	4, 0x90
	.type	nrt_atomic_sub,@function
nrt_atomic_sub:
	movq	$-1, %rax
	lock		xaddq	%rax, (%rdi)
	decq	%rax
	retq
.Lfunc_end1:
	.size	nrt_atomic_sub, .Lfunc_end1-nrt_atomic_sub

	.globl	nrt_atomic_cas
	.p2align	4, 0x90
	.type	nrt_atomic_cas,@function
nrt_atomic_cas:
	movq	%rsi, %rax
	xorl	%esi, %esi
	lock		cmpxchgq	%rdx, (%rdi)
	sete	%sil
	movq	%rax, (%rcx)
	movl	%esi, %eax
	retq
.Lfunc_end2:
	.size	nrt_atomic_cas, .Lfunc_end2-nrt_atomic_cas

	.globl	NRT_MemInfo_data_fast
	.p2align	4, 0x90
	.type	NRT_MemInfo_data_fast,@function
NRT_MemInfo_data_fast:
	movq	24(%rdi), %rax
	retq
.Lfunc_end3:
	.size	NRT_MemInfo_data_fast, .Lfunc_end3-NRT_MemInfo_data_fast

	.globl	NRT_incref
	.p2align	4, 0x90
	.type	NRT_incref,@function
NRT_incref:
	testq	%rdi, %rdi
	je	.LBB4_1
	lock		incq	(%rdi)
	retq
.LBB4_1:
	retq
.Lfunc_end4:
	.size	NRT_incref, .Lfunc_end4-NRT_incref

	.globl	NRT_decref
	.p2align	4, 0x90
	.type	NRT_decref,@function
NRT_decref:
	.cfi_startproc
	testq	%rdi, %rdi
	je	.LBB5_2
	#MEMBARRIER
	lock		decq	(%rdi)
	je	.LBB5_3
.LBB5_2:
	retq
.LBB5_3:
	#MEMBARRIER
	movabsq	$NRT_MemInfo_call_dtor, %rax
	jmpq	*%rax
.Lfunc_end5:
	.size	NRT_decref, .Lfunc_end5-NRT_decref
	.cfi_endproc

	.globl	nrt_unresolved_abort
	.p2align	4, 0x90
	.type	nrt_unresolved_abort,@function
nrt_unresolved_abort:
	movabsq	$.const.picklebuf.140612176063216, %rax
	movq	%rax, (%rsi)
	movl	$1, %eax
	retq
.Lfunc_end6:
	.size	nrt_unresolved_abort, .Lfunc_end6-nrt_unresolved_abort

	.type	.const.picklebuf.140612176063216,@object
	.section	.rodata,"a",@progbits
	.p2align	3
.const.picklebuf.140612176063216:
	.quad	.const.pickledata.140612176063216
	.long	102
	.zero	4
	.size	.const.picklebuf.140612176063216, 16

	.type	.const.pickledata.140612176063216,@object
	.p2align	4
.const.pickledata.140612176063216:
	.ascii	"\200\004\225[\000\000\000\000\000\000\000\214\bbuiltins\224\214\fRuntimeError\224\223\224\2146numba jitted function aborted due to unresolved symbol\224\205\224N\207\224."
	.size	.const.pickledata.140612176063216, 102


	.section	".note.GNU-stack","",@progbits

================================================================================
[cache] index loaded from '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.nbi'
--------------------IR DUMP: temperature_effectiveness_plate--------------------
label 0:
    R1 = arg(0, name=R1)                     ['R1']
    NTU1 = arg(1, name=NTU1)                 ['NTU1']
    Np1 = arg(2, name=Np1)                   ['Np1']
    Np2 = arg(3, name=Np2)                   ['Np2']
    reverse = arg(4, name=reverse)           ['reverse']
    $const4.1 = const(int, 1)                ['$const4.1']
    $6compare_op.2 = Np1 == $const4.1        ['$6compare_op.2', '$const4.1', 'Np1']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 22                    ['$8pred']
label 10:
    $const12.1 = const(int, 1)               ['$const12.1']
    $14compare_op.2 = Np2 == $const12.1      ['$14compare_op.2', '$const12.1', 'Np2']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 22                   ['$16pred']
label 18:
    $const18.0 = const(float, 1.1)           ['$const18.0']
    $20return_value.1 = cast(value=$const18.0) ['$20return_value.1', '$const18.0']
    return $20return_value.1                 ['$20return_value.1']
label 22:
    bool24 = global(bool: <class 'bool'>)    ['bool24']
    $24pred = call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None) ['$24pred', 'bool24', 'reverse']
    branch $24pred, 64, 26                   ['$24pred']
label 26:
    $const26.0 = const(float, 1.0)           ['$const26.0']
    $30binary_true_divide.2 = $const26.0 / R1 ['$30binary_true_divide.2', '$const26.0', 'R1']
    R2 = $30binary_true_divide.2             ['$30binary_true_divide.2', 'R2']
    $38binary_multiply.5 = NTU1 * R1         ['$38binary_multiply.5', 'NTU1', 'R1']
    NTU2 = $38binary_multiply.5              ['$38binary_multiply.5', 'NTU2']
    $42load_global.6 = global(temperature_effectiveness_plate: CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>)) ['$42load_global.6']
    $const52.11 = const(bool, True)          ['$const52.11']
    $56call_function_kw.13 = call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None) ['$42load_global.6', '$56call_function_kw.13', '$const52.11', 'NTU2', 'Np1', 'Np2', 'R2']
    P2 = $56call_function_kw.13              ['$56call_function_kw.13', 'P2']
    $const60.14 = const(float, 1.3)          ['$const60.14']
    $62return_value.15 = cast(value=$const60.14) ['$62return_value.15', '$const60.14']
    return $62return_value.15                ['$62return_value.15']
label 64:
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    raise $68call_function.2                 ['$68call_function.2']

______________________________________________________________________
REWRITING (RewriteConstRaises):
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    raise $68call_function.2                 ['$68call_function.2']
____________________________________________________________
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    <static> raise <class 'ValueError'>('Supported number of passes does not have a formula available') []
______________________________________________________________________
--------------------IR DUMP: temperature_effectiveness_plate--------------------
label 0:
    R1 = arg(0, name=R1)                     ['R1']
    NTU1 = arg(1, name=NTU1)                 ['NTU1']
    Np1 = arg(2, name=Np1)                   ['Np1']
    Np2 = arg(3, name=Np2)                   ['Np2']
    reverse = arg(4, name=reverse)           ['reverse']
    $const4.1 = const(int, 1)                ['$const4.1']
    $6compare_op.2 = Np1 == $const4.1        ['$6compare_op.2', '$const4.1', 'Np1']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 22                    ['$8pred']
label 10:
    $const12.1 = const(int, 1)               ['$const12.1']
    $14compare_op.2 = Np2 == $const12.1      ['$14compare_op.2', '$const12.1', 'Np2']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 22                   ['$16pred']
label 18:
    $const18.0 = const(float, 1.1)           ['$const18.0']
    $20return_value.1 = cast(value=$const18.0) ['$20return_value.1', '$const18.0']
    return $20return_value.1                 ['$20return_value.1']
label 22:
    bool24 = global(bool: <class 'bool'>)    ['bool24']
    $24pred = call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None) ['$24pred', 'bool24', 'reverse']
    branch $24pred, 64, 26                   ['$24pred']
label 26:
    $const26.0 = const(float, 1.0)           ['$const26.0']
    $30binary_true_divide.2 = $const26.0 / R1 ['$30binary_true_divide.2', '$const26.0', 'R1']
    R2 = $30binary_true_divide.2             ['$30binary_true_divide.2', 'R2']
    $38binary_multiply.5 = NTU1 * R1         ['$38binary_multiply.5', 'NTU1', 'R1']
    NTU2 = $38binary_multiply.5              ['$38binary_multiply.5', 'NTU2']
    $42load_global.6 = global(temperature_effectiveness_plate: CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>)) ['$42load_global.6']
    $const52.11 = const(bool, True)          ['$const52.11']
    $56call_function_kw.13 = call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None) ['$42load_global.6', '$56call_function_kw.13', '$const52.11', 'NTU2', 'Np1', 'Np2', 'R2']
    P2 = $56call_function_kw.13              ['$56call_function_kw.13', 'P2']
    $const60.14 = const(float, 1.3)          ['$const60.14']
    $62return_value.15 = cast(value=$const60.14) ['$62return_value.15', '$const60.14']
    return $62return_value.15                ['$62return_value.15']
label 64:
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    <static> raise <class 'ValueError'>('Supported number of passes does not have a formula available') []

------------------SSA IR DUMP: temperature_effectiveness_plate------------------
label 0:
    R1 = arg(0, name=R1)                     ['R1']
    NTU1 = arg(1, name=NTU1)                 ['NTU1']
    Np1 = arg(2, name=Np1)                   ['Np1']
    Np2 = arg(3, name=Np2)                   ['Np2']
    reverse = arg(4, name=reverse)           ['reverse']
    $const4.1 = const(int, 1)                ['$const4.1']
    $6compare_op.2 = Np1 == $const4.1        ['$6compare_op.2', '$const4.1', 'Np1']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 22                    ['$8pred']
label 10:
    $const12.1 = const(int, 1)               ['$const12.1']
    $14compare_op.2 = Np2 == $const12.1      ['$14compare_op.2', '$const12.1', 'Np2']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 22                   ['$16pred']
label 18:
    $const18.0 = const(float, 1.1)           ['$const18.0']
    $20return_value.1 = cast(value=$const18.0) ['$20return_value.1', '$const18.0']
    return $20return_value.1                 ['$20return_value.1']
label 22:
    bool24 = global(bool: <class 'bool'>)    ['bool24']
    $24pred = call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None) ['$24pred', 'bool24', 'reverse']
    branch $24pred, 64, 26                   ['$24pred']
label 26:
    $const26.0 = const(float, 1.0)           ['$const26.0']
    $30binary_true_divide.2 = $const26.0 / R1 ['$30binary_true_divide.2', '$const26.0', 'R1']
    R2 = $30binary_true_divide.2             ['$30binary_true_divide.2', 'R2']
    $38binary_multiply.5 = NTU1 * R1         ['$38binary_multiply.5', 'NTU1', 'R1']
    NTU2 = $38binary_multiply.5              ['$38binary_multiply.5', 'NTU2']
    $42load_global.6 = global(temperature_effectiveness_plate: CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>)) ['$42load_global.6']
    $const52.11 = const(bool, True)          ['$const52.11']
    $56call_function_kw.13 = call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None) ['$42load_global.6', '$56call_function_kw.13', '$const52.11', 'NTU2', 'Np1', 'Np2', 'R2']
    P2 = $56call_function_kw.13              ['$56call_function_kw.13', 'P2']
    $const60.14 = const(float, 1.3)          ['$const60.14']
    $62return_value.15 = cast(value=$const60.14) ['$62return_value.15', '$const60.14']
    return $62return_value.15                ['$62return_value.15']
label 64:
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    <static> raise <class 'ValueError'>('Supported number of passes does not have a formula available') []

-----------------------------------propagate------------------------------------
[cache] index loaded from '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.nbi'
--------------------IR DUMP: temperature_effectiveness_plate--------------------
label 0:
    R1 = arg(0, name=R1)                     ['R1']
    NTU1 = arg(1, name=NTU1)                 ['NTU1']
    Np1 = arg(2, name=Np1)                   ['Np1']
    Np2 = arg(3, name=Np2)                   ['Np2']
    reverse = arg(4, name=reverse)           ['reverse']
    $const4.1 = const(int, 1)                ['$const4.1']
    $6compare_op.2 = Np1 == $const4.1        ['$6compare_op.2', '$const4.1', 'Np1']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 22                    ['$8pred']
label 10:
    $const12.1 = const(int, 1)               ['$const12.1']
    $14compare_op.2 = Np2 == $const12.1      ['$14compare_op.2', '$const12.1', 'Np2']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 22                   ['$16pred']
label 18:
    $const18.0 = const(float, 1.1)           ['$const18.0']
    $20return_value.1 = cast(value=$const18.0) ['$20return_value.1', '$const18.0']
    return $20return_value.1                 ['$20return_value.1']
label 22:
    bool24 = global(bool: <class 'bool'>)    ['bool24']
    $24pred = call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None) ['$24pred', 'bool24', 'reverse']
    branch $24pred, 64, 26                   ['$24pred']
label 26:
    $const26.0 = const(float, 1.0)           ['$const26.0']
    $30binary_true_divide.2 = $const26.0 / R1 ['$30binary_true_divide.2', '$const26.0', 'R1']
    R2 = $30binary_true_divide.2             ['$30binary_true_divide.2', 'R2']
    $38binary_multiply.5 = NTU1 * R1         ['$38binary_multiply.5', 'NTU1', 'R1']
    NTU2 = $38binary_multiply.5              ['$38binary_multiply.5', 'NTU2']
    $42load_global.6 = global(temperature_effectiveness_plate: CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>)) ['$42load_global.6']
    $const52.11 = const(bool, True)          ['$const52.11']
    $56call_function_kw.13 = call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None) ['$42load_global.6', '$56call_function_kw.13', '$const52.11', 'NTU2', 'Np1', 'Np2', 'R2']
    P2 = $56call_function_kw.13              ['$56call_function_kw.13', 'P2']
    $const60.14 = const(float, 1.3)          ['$const60.14']
    $62return_value.15 = cast(value=$const60.14) ['$62return_value.15', '$const60.14']
    return $62return_value.15                ['$62return_value.15']
label 64:
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    raise $68call_function.2                 ['$68call_function.2']

______________________________________________________________________
REWRITING (RewriteConstRaises):
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    raise $68call_function.2                 ['$68call_function.2']
____________________________________________________________
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    <static> raise <class 'ValueError'>('Supported number of passes does not have a formula available') []
______________________________________________________________________
--------------------IR DUMP: temperature_effectiveness_plate--------------------
label 0:
    R1 = arg(0, name=R1)                     ['R1']
    NTU1 = arg(1, name=NTU1)                 ['NTU1']
    Np1 = arg(2, name=Np1)                   ['Np1']
    Np2 = arg(3, name=Np2)                   ['Np2']
    reverse = arg(4, name=reverse)           ['reverse']
    $const4.1 = const(int, 1)                ['$const4.1']
    $6compare_op.2 = Np1 == $const4.1        ['$6compare_op.2', '$const4.1', 'Np1']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 22                    ['$8pred']
label 10:
    $const12.1 = const(int, 1)               ['$const12.1']
    $14compare_op.2 = Np2 == $const12.1      ['$14compare_op.2', '$const12.1', 'Np2']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 22                   ['$16pred']
label 18:
    $const18.0 = const(float, 1.1)           ['$const18.0']
    $20return_value.1 = cast(value=$const18.0) ['$20return_value.1', '$const18.0']
    return $20return_value.1                 ['$20return_value.1']
label 22:
    bool24 = global(bool: <class 'bool'>)    ['bool24']
    $24pred = call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None) ['$24pred', 'bool24', 'reverse']
    branch $24pred, 64, 26                   ['$24pred']
label 26:
    $const26.0 = const(float, 1.0)           ['$const26.0']
    $30binary_true_divide.2 = $const26.0 / R1 ['$30binary_true_divide.2', '$const26.0', 'R1']
    R2 = $30binary_true_divide.2             ['$30binary_true_divide.2', 'R2']
    $38binary_multiply.5 = NTU1 * R1         ['$38binary_multiply.5', 'NTU1', 'R1']
    NTU2 = $38binary_multiply.5              ['$38binary_multiply.5', 'NTU2']
    $42load_global.6 = global(temperature_effectiveness_plate: CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>)) ['$42load_global.6']
    $const52.11 = const(bool, True)          ['$const52.11']
    $56call_function_kw.13 = call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None) ['$42load_global.6', '$56call_function_kw.13', '$const52.11', 'NTU2', 'Np1', 'Np2', 'R2']
    P2 = $56call_function_kw.13              ['$56call_function_kw.13', 'P2']
    $const60.14 = const(float, 1.3)          ['$const60.14']
    $62return_value.15 = cast(value=$const60.14) ['$62return_value.15', '$const60.14']
    return $62return_value.15                ['$62return_value.15']
label 64:
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    <static> raise <class 'ValueError'>('Supported number of passes does not have a formula available') []

------------------SSA IR DUMP: temperature_effectiveness_plate------------------
label 0:
    R1 = arg(0, name=R1)                     ['R1']
    NTU1 = arg(1, name=NTU1)                 ['NTU1']
    Np1 = arg(2, name=Np1)                   ['Np1']
    Np2 = arg(3, name=Np2)                   ['Np2']
    reverse = arg(4, name=reverse)           ['reverse']
    $const4.1 = const(int, 1)                ['$const4.1']
    $6compare_op.2 = Np1 == $const4.1        ['$6compare_op.2', '$const4.1', 'Np1']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 22                    ['$8pred']
label 10:
    $const12.1 = const(int, 1)               ['$const12.1']
    $14compare_op.2 = Np2 == $const12.1      ['$14compare_op.2', '$const12.1', 'Np2']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 22                   ['$16pred']
label 18:
    $const18.0 = const(float, 1.1)           ['$const18.0']
    $20return_value.1 = cast(value=$const18.0) ['$20return_value.1', '$const18.0']
    return $20return_value.1                 ['$20return_value.1']
label 22:
    bool24 = global(bool: <class 'bool'>)    ['bool24']
    $24pred = call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None) ['$24pred', 'bool24', 'reverse']
    branch $24pred, 64, 26                   ['$24pred']
label 26:
    $const26.0 = const(float, 1.0)           ['$const26.0']
    $30binary_true_divide.2 = $const26.0 / R1 ['$30binary_true_divide.2', '$const26.0', 'R1']
    R2 = $30binary_true_divide.2             ['$30binary_true_divide.2', 'R2']
    $38binary_multiply.5 = NTU1 * R1         ['$38binary_multiply.5', 'NTU1', 'R1']
    NTU2 = $38binary_multiply.5              ['$38binary_multiply.5', 'NTU2']
    $42load_global.6 = global(temperature_effectiveness_plate: CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>)) ['$42load_global.6']
    $const52.11 = const(bool, True)          ['$const52.11']
    $56call_function_kw.13 = call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None) ['$42load_global.6', '$56call_function_kw.13', '$const52.11', 'NTU2', 'Np1', 'Np2', 'R2']
    P2 = $56call_function_kw.13              ['$56call_function_kw.13', 'P2']
    $const60.14 = const(float, 1.3)          ['$const60.14']
    $62return_value.15 = cast(value=$const60.14) ['$62return_value.15', '$const60.14']
    return $62return_value.15                ['$62return_value.15']
label 64:
    $64load_global.0 = global(ValueError: <class 'ValueError'>) ['$64load_global.0']
    $const66.1 = const(str, Supported number of passes does not have a formula available) ['$const66.1']
    $68call_function.2 = call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None) ['$64load_global.0', '$68call_function.2', '$const66.1']
    <static> raise <class 'ValueError'>('Supported number of passes does not have a formula available') []

-----------------------------------propagate------------------------------------
-----------------------------------propagate------------------------------------
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := <undecided>,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := <undecided>,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := <undecided>,
 arg.Np1 := <undecided>,
 arg.Np2 := <undecided>,
 arg.R1 := <undecided>,
 arg.reverse := <undecided>,
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
-----------------------------------propagate------------------------------------
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := <undecided>,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := <undecided>,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := <undecided>,
 arg.Np1 := <undecided>,
 arg.Np2 := <undecided>,
 arg.R1 := <undecided>,
 arg.reverse := <undecided>,
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := float64,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := float64,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := float64,
 arg.Np1 := int64,
 arg.Np2 := int64,
 arg.R1 := float64,
 arg.reverse := bool,
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
-----------------------------------propagate------------------------------------
-----------------------------------propagate------------------------------------
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := float64,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := float64,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := <undecided>,
 arg.Np1 := <undecided>,
 arg.Np2 := <undecided>,
 arg.R1 := <undecided>,
 arg.reverse := <undecided>,
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
-----------------------------------propagate------------------------------------
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := float64,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := float64,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := <undecided>,
 arg.Np1 := <undecided>,
 arg.Np2 := <undecided>,
 arg.R1 := <undecided>,
 arg.reverse := <undecided>,
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := float64,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := float64,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := float64,
 arg.Np1 := int64,
 arg.Np2 := int64,
 arg.R1 := float64,
 arg.reverse := bool,
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
---------------------------------Variable types---------------------------------
{'$14compare_op.2': bool,
 '$16pred': bool,
 '$20return_value.1': float64,
 '$24pred': bool,
 '$30binary_true_divide.2': float64,
 '$38binary_multiply.5': float64,
 '$42load_global.6': recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 '$56call_function_kw.13': float64,
 '$62return_value.15': float64,
 '$64load_global.0': ValueError,
 '$68call_function.2': ValueError(...),
 '$6compare_op.2': bool,
 '$8pred': bool,
 '$const12.1': Literal[int](1),
 '$const18.0': float64,
 '$const26.0': float64,
 '$const4.1': Literal[int](1),
 '$const52.11': bool,
 '$const60.14': float64,
 '$const66.1': Literal[str](Supported number of passes does not have a formula available),
 'NTU1': float64,
 'NTU2': float64,
 'Np1': int64,
 'Np2': int64,
 'P2': float64,
 'R1': float64,
 'R2': float64,
 'arg.NTU1': float64,
 'arg.Np1': int64,
 'arg.Np2': int64,
 'arg.R1': float64,
 'arg.reverse': bool,
 'bool16': Function(<class 'bool'>),
 'bool24': Function(<class 'bool'>),
 'bool8': Function(<class 'bool'>),
 'reverse': bool}
----------------------------------Return type-----------------------------------
float64
-----------------------------------Call types-----------------------------------
{$const26.0 / R1: (float64, float64) -> float64,
 NTU1 * R1: (float64, float64) -> float64,
 Np1 == $const4.1: (int64, int64) -> bool,
 Np2 == $const12.1: (int64, int64) -> bool,
 call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None): (float64, float64, int64, int64, bool) -> float64,
 call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None): () -> ValueError(...),
 call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None): (bool,) -> bool,
 call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None): (bool,) -> bool,
 call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None): (bool,) -> bool}
------LLVM DUMP <function descriptor 'temperature_effectiveness_plate$2'>-------
; ModuleID = "temperature_effectiveness_plate$2"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"

@"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb" = common global i8* null
define i32 @"_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double* noalias nocapture %"retptr.1", {i8*, i32}** noalias nocapture %"excinfo.1", double %"arg.R1.1", double %"arg.NTU1.1", i64 %"arg.Np1.1", i64 %"arg.Np2.1", i8 %"arg.reverse.1") 
{
entry:
  %".9" = alloca i1
  store i1 0, i1* %".9"
  %".11" = icmp eq i8 %"arg.reverse.1", 0
  %"R1" = alloca double
  store double 0.0, double* %"R1"
  %"NTU1" = alloca double
  store double 0.0, double* %"NTU1"
  %"Np1" = alloca i64
  store i64 0, i64* %"Np1"
  %"Np2" = alloca i64
  store i64 0, i64* %"Np2"
  %"reverse" = alloca i1
  store i1 0, i1* %"reverse"
  %"$const4.1" = alloca i64
  store i64 0, i64* %"$const4.1"
  %"$6compare_op.2" = alloca i1
  store i1 0, i1* %"$6compare_op.2"
  %"bool8" = alloca i8*
  store i8* null, i8** %"bool8"
  %"$8pred" = alloca i1
  store i1 0, i1* %"$8pred"
  %"$const12.1" = alloca i64
  store i64 0, i64* %"$const12.1"
  %"$14compare_op.2" = alloca i1
  store i1 0, i1* %"$14compare_op.2"
  %"bool16" = alloca i8*
  store i8* null, i8** %"bool16"
  %"$16pred" = alloca i1
  store i1 0, i1* %"$16pred"
  %"$const18.0" = alloca double
  store double 0.0, double* %"$const18.0"
  %"$20return_value.1" = alloca double
  store double 0.0, double* %"$20return_value.1"
  %"bool24" = alloca i8*
  store i8* null, i8** %"bool24"
  %"$24pred" = alloca i1
  store i1 0, i1* %"$24pred"
  %"$const26.0" = alloca double
  store double 0.0, double* %"$const26.0"
  %"try_state" = alloca i64
  store i64 0, i64* %"try_state"
  %"$30binary_true_divide.2" = alloca double
  store double 0.0, double* %"$30binary_true_divide.2"
  %"R2" = alloca double
  store double 0.0, double* %"R2"
  %"$38binary_multiply.5" = alloca double
  store double 0.0, double* %"$38binary_multiply.5"
  %"NTU2" = alloca double
  store double 0.0, double* %"NTU2"
  %"$42load_global.6" = alloca i8*
  store i8* null, i8** %"$42load_global.6"
  %"$const52.11" = alloca i1
  store i1 0, i1* %"$const52.11"
  %".179" = alloca double
  store double 0.0, double* %".179"
  %"excinfo.2" = alloca {i8*, i32}*
  store {i8*, i32}* null, {i8*, i32}** %"excinfo.2"
  %"$56call_function_kw.13" = alloca double
  store double 0.0, double* %"$56call_function_kw.13"
  %"P2" = alloca double
  store double 0.0, double* %"P2"
  %"$const60.14" = alloca double
  store double 0.0, double* %"$const60.14"
  %"$62return_value.15" = alloca double
  store double 0.0, double* %"$62return_value.15"
  %"$64load_global.0" = alloca i8*
  store i8* null, i8** %"$64load_global.0"
  %"$const66.1" = alloca i8*
  store i8* null, i8** %"$const66.1"
  %"$68call_function.2" = alloca i8*
  store i8* null, i8** %"$68call_function.2"
  br i1 %".11", label %"entry.if", label %"entry.else"
entry.if:
  store i1 0, i1* %".9"
  br label %"entry.endif"
entry.else:
  store i1 1, i1* %".9"
  br label %"entry.endif"
entry.endif:
  %".17" = load i1, i1* %".9"
  br label %"B0"
B0:
  %".19" = load double, double* %"R1"
  store double %"arg.R1.1", double* %"R1"
  %".22" = load double, double* %"NTU1"
  store double %"arg.NTU1.1", double* %"NTU1"
  %".25" = load i64, i64* %"Np1"
  store i64 %"arg.Np1.1", i64* %"Np1"
  %".28" = load i64, i64* %"Np2"
  store i64 %"arg.Np2.1", i64* %"Np2"
  %".31" = load i1, i1* %"reverse"
  store i1 %".17", i1* %"reverse"
  %".34" = load i64, i64* %"$const4.1"
  store i64 1, i64* %"$const4.1"
  %".36" = load i64, i64* %"Np1"
  %".37" = load i64, i64* %"$const4.1"
  %".38" = icmp eq i64 %".36", 1
  %".40" = load i1, i1* %"$6compare_op.2"
  store i1 %".38", i1* %"$6compare_op.2"
  %".42" = load i64, i64* %"$const4.1"
  store i64 0, i64* %"$const4.1"
  %".45" = load i8*, i8** %"bool8"
  store i8* null, i8** %"bool8"
  %".47" = load i1, i1* %"$6compare_op.2"
  %".49" = load i1, i1* %"$8pred"
  store i1 %".47", i1* %"$8pred"
  %".51" = load i8*, i8** %"bool8"
  store i8* null, i8** %"bool8"
  %".53" = load i1, i1* %"$6compare_op.2"
  store i1 0, i1* %"$6compare_op.2"
  %".55" = load i1, i1* %"$8pred"
  br i1 %".55", label %"B10", label %"B22"
B10:
  %".57" = load i1, i1* %"$8pred"
  store i1 0, i1* %"$8pred"
  %".60" = load i64, i64* %"$const12.1"
  store i64 1, i64* %"$const12.1"
  %".62" = load i64, i64* %"Np2"
  %".63" = load i64, i64* %"$const12.1"
  %".64" = icmp eq i64 %".62", 1
  %".66" = load i1, i1* %"$14compare_op.2"
  store i1 %".64", i1* %"$14compare_op.2"
  %".68" = load i64, i64* %"$const12.1"
  store i64 0, i64* %"$const12.1"
  %".71" = load i8*, i8** %"bool16"
  store i8* null, i8** %"bool16"
  %".73" = load i1, i1* %"$14compare_op.2"
  %".75" = load i1, i1* %"$16pred"
  store i1 %".73", i1* %"$16pred"
  %".77" = load i8*, i8** %"bool16"
  store i8* null, i8** %"bool16"
  %".79" = load i1, i1* %"$14compare_op.2"
  store i1 0, i1* %"$14compare_op.2"
  %".81" = load i1, i1* %"$16pred"
  br i1 %".81", label %"B18", label %"B22"
B18:
  %".83" = load i1, i1* %"reverse"
  store i1 0, i1* %"reverse"
  %".85" = load double, double* %"R1"
  store double 0.0, double* %"R1"
  %".87" = load i64, i64* %"Np2"
  store i64 0, i64* %"Np2"
  %".89" = load i64, i64* %"Np1"
  store i64 0, i64* %"Np1"
  %".91" = load double, double* %"NTU1"
  store double 0.0, double* %"NTU1"
  %".93" = load i1, i1* %"$16pred"
  store i1 0, i1* %"$16pred"
  %".96" = load double, double* %"$const18.0"
  store double 0x3ff199999999999a, double* %"$const18.0"
  %".98" = load double, double* %"$const18.0"
  %".100" = load double, double* %"$20return_value.1"
  store double %".98", double* %"$20return_value.1"
  %".102" = load double, double* %"$const18.0"
  store double 0.0, double* %"$const18.0"
  %".104" = load double, double* %"$20return_value.1"
  store double %".104", double* %"retptr.1"
  ret i32 0
B22:
  %".107" = load i1, i1* %"$8pred"
  store i1 0, i1* %"$8pred"
  %".109" = load i1, i1* %"$16pred"
  store i1 0, i1* %"$16pred"
  %".112" = load i8*, i8** %"bool24"
  store i8* null, i8** %"bool24"
  %".114" = load i1, i1* %"reverse"
  %".116" = load i1, i1* %"$24pred"
  store i1 %".114", i1* %"$24pred"
  %".118" = load i1, i1* %"reverse"
  store i1 0, i1* %"reverse"
  %".120" = load i8*, i8** %"bool24"
  store i8* null, i8** %"bool24"
  %".122" = load i1, i1* %"$24pred"
  br i1 %".122", label %"B64", label %"B26"
B26:
  %".124" = load i1, i1* %"$24pred"
  store i1 0, i1* %"$24pred"
  %".127" = load double, double* %"$const26.0"
  store double 0x3ff0000000000000, double* %"$const26.0"
  %".129" = load double, double* %"$const26.0"
  %".130" = load double, double* %"R1"
  %".131" = fcmp oeq double %".130",              0x0
  br i1 %".131", label %"B26.if", label %"B26.endif", !prof !0
B64:
  %".239" = load double, double* %"R1"
  store double 0.0, double* %"R1"
  %".241" = load i64, i64* %"Np2"
  store i64 0, i64* %"Np2"
  %".243" = load i64, i64* %"Np1"
  store i64 0, i64* %"Np1"
  %".245" = load double, double* %"NTU1"
  store double 0.0, double* %"NTU1"
  %".247" = load i1, i1* %"$24pred"
  store i1 0, i1* %"$24pred"
  %".250" = load i8*, i8** %"$64load_global.0"
  store i8* null, i8** %"$64load_global.0"
  %".253" = load i8*, i8** %"$const66.1"
  store i8* null, i8** %"$const66.1"
  %".256" = load i8*, i8** %"$68call_function.2"
  store i8* null, i8** %"$68call_function.2"
  %".258" = load i8*, i8** %"$const66.1"
  store i8* null, i8** %"$const66.1"
  %".260" = load i8*, i8** %"$68call_function.2"
  store i8* null, i8** %"$68call_function.2"
  %".262" = load i8*, i8** %"$64load_global.0"
  store i8* null, i8** %"$64load_global.0"
  store {i8*, i32}* @".const.picklebuf.140612147179104", {i8*, i32}** %"excinfo.1"
  %".265" = load i64, i64* %"try_state"
  %".266" = icmp ugt i64 %".265", 0
  %".267" = load {i8*, i32}*, {i8*, i32}** %"excinfo.1"
  ret i32 1
B26.if:
  store {i8*, i32}* @".const.picklebuf.140612147179184", {i8*, i32}** %"excinfo.1"
  store i64 0, i64* %"try_state"
  %".136" = load i64, i64* %"try_state"
  %".137" = icmp ugt i64 %".136", 0
  %".138" = load {i8*, i32}*, {i8*, i32}** %"excinfo.1"
  ret i32 1
B26.endif:
  %".140" = fdiv double %".129", %".130"
  %".142" = load double, double* %"$30binary_true_divide.2"
  store double %".140", double* %"$30binary_true_divide.2"
  %".144" = load double, double* %"$const26.0"
  store double 0.0, double* %"$const26.0"
  %".146" = load double, double* %"$30binary_true_divide.2"
  %".148" = load double, double* %"R2"
  store double %".146", double* %"R2"
  %".150" = load double, double* %"$30binary_true_divide.2"
  store double 0.0, double* %"$30binary_true_divide.2"
  %".152" = load double, double* %"NTU1"
  %".153" = load double, double* %"R1"
  %".154" = fmul double %".152", %".153"
  %".156" = load double, double* %"$38binary_multiply.5"
  store double %".154", double* %"$38binary_multiply.5"
  %".158" = load double, double* %"R1"
  store double 0.0, double* %"R1"
  %".160" = load double, double* %"NTU1"
  store double 0.0, double* %"NTU1"
  %".162" = load double, double* %"$38binary_multiply.5"
  %".164" = load double, double* %"NTU2"
  store double %".162", double* %"NTU2"
  %".166" = load double, double* %"$38binary_multiply.5"
  store double 0.0, double* %"$38binary_multiply.5"
  %".169" = load i8*, i8** %"$42load_global.6"
  store i8* null, i8** %"$42load_global.6"
  %".172" = load i1, i1* %"$const52.11"
  store i1 true, i1* %"$const52.11"
  %".174" = load double, double* %"R2"
  %".175" = load double, double* %"NTU2"
  %".176" = load i64, i64* %"Np2"
  %".177" = load i64, i64* %"Np1"
  %".178" = load i1, i1* %"$const52.11"
  store double 0.0, double* %".179"
  %".183" = zext i1 %".178" to i8
  %".184" = call i32 @"_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double* %".179", {i8*, i32}** %"excinfo.2", double %".174", double %".175", i64 %".176", i64 %".177", i8 %".183")
  %".185" = load {i8*, i32}*, {i8*, i32}** %"excinfo.2"
  %".186" = icmp eq i32 %".184", 0
  %".187" = icmp eq i32 %".184", -2
  %".188" = icmp eq i32 %".184", -1
  %".189" = icmp eq i32 %".184", -3
  %".190" = or i1 %".186", %".187"
  %".191" = xor i1 %".190", -1
  %".192" = icmp sge i32 %".184", 1
  %".193" = select i1 %".192", {i8*, i32}* %".185", {i8*, i32}* undef
  %".194" = load double, double* %".179"
  br i1 %".191", label %"B26.endif.if", label %"B26.endif.endif", !prof !0
B26.endif.if:
  %".196" = load i64, i64* %"try_state"
  %".197" = icmp ugt i64 %".196", 0
  %".198" = load {i8*, i32}*, {i8*, i32}** %"excinfo.1"
  store {i8*, i32}* %".193", {i8*, i32}** %"excinfo.1"
  %".200" = xor i1 %".197", -1
  br i1 %".200", label %"B26.endif.if.if", label %"B26.endif.if.endif"
B26.endif.endif:
  %".205" = load double, double* %"$56call_function_kw.13"
  store double %".194", double* %"$56call_function_kw.13"
  %".207" = load double, double* %"R2"
  store double 0.0, double* %"R2"
  %".209" = load i64, i64* %"Np2"
  store i64 0, i64* %"Np2"
  %".211" = load i64, i64* %"Np1"
  store i64 0, i64* %"Np1"
  %".213" = load double, double* %"NTU2"
  store double 0.0, double* %"NTU2"
  %".215" = load i1, i1* %"$const52.11"
  store i1 0, i1* %"$const52.11"
  %".217" = load i8*, i8** %"$42load_global.6"
  store i8* null, i8** %"$42load_global.6"
  %".219" = load double, double* %"$56call_function_kw.13"
  %".221" = load double, double* %"P2"
  store double %".219", double* %"P2"
  %".223" = load double, double* %"P2"
  store double 0.0, double* %"P2"
  %".225" = load double, double* %"$56call_function_kw.13"
  store double 0.0, double* %"$56call_function_kw.13"
  %".228" = load double, double* %"$const60.14"
  store double 0x3ff4cccccccccccd, double* %"$const60.14"
  %".230" = load double, double* %"$const60.14"
  %".232" = load double, double* %"$62return_value.15"
  store double %".230", double* %"$62return_value.15"
  %".234" = load double, double* %"$const60.14"
  store double 0.0, double* %"$const60.14"
  %".236" = load double, double* %"$62return_value.15"
  store double %".236", double* %"retptr.1"
  ret i32 0
B26.endif.if.if:
  ret i32 %".184"
B26.endif.if.endif:
  br label %"B26.endif.endif"
}

@".const.pickledata.140612147179184" = internal constant [69 x i8] c"\80\04\95:\00\00\00\00\00\00\00\8c\08builtins\94\8c\11ZeroDivisionError\94\93\94\8c\10division by zero\94\85\94N\87\94."
@".const.picklebuf.140612147179184" = internal constant {i8*, i32} {i8* bitcast ([69 x i8]* @".const.pickledata.140612147179184" to i8*), i32 69}
@".const.pickledata.140612147179104" = internal constant [163 x i8] c"\80\04\95\98\00\00\00\00\00\00\00\8c\08builtins\94\8c\0aValueError\94\93\94\8c<Supported number of passes does not have a formula available\94\85\94\8c\1ftemperature_effectiveness_plate\94\8c\11issue2_minimal.py\94K\0d\87\94\87\94."
@".const.picklebuf.140612147179104" = internal constant {i8*, i32} {i8* bitcast ([163 x i8]* @".const.pickledata.140612147179104" to i8*), i32 163}
!0 = !{ !"branch_weights", i32 1, i32 99 }
================================================================================
================================================================================
------------FUNCTION OPTIMIZED DUMP temperature_effectiveness_plate-------------
; ModuleID = 'temperature_effectiveness_plate'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb" = common global i8* null
@.const.picklebuf.140612147179104 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([163 x i8], [163 x i8]* @.const.pickledata.140612147179104, i32 0, i32 0), i32 163 }
@.const.picklebuf.140612147179184 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([69 x i8], [69 x i8]* @.const.pickledata.140612147179184, i32 0, i32 0), i32 69 }
@.const.pickledata.140612147179184 = internal constant [69 x i8] c"\80\04\95:\00\00\00\00\00\00\00\8C\08builtins\94\8C\11ZeroDivisionError\94\93\94\8C\10division by zero\94\85\94N\87\94."
@.const.pickledata.140612147179104 = internal constant [163 x i8] c"\80\04\95\98\00\00\00\00\00\00\00\8C\08builtins\94\8C\0AValueError\94\93\94\8C<Supported number of passes does not have a formula available\94\85\94\8C\1Ftemperature_effectiveness_plate\94\8C\11issue2_minimal.py\94K\0D\87\94\87\94."
@.const.temperature_effectiveness_plate = internal constant [32 x i8] c"temperature_effectiveness_plate\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@_Py_NoneStruct = external global i8
@PyExc_StopIteration = external global i8
@PyExc_SystemError = external global i8
@".const.unknown error when calling native function" = internal constant [43 x i8] c"unknown error when calling native function\00"
@".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>" = internal constant [53 x i8] c"<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>\00"
@".const.unknown error when calling native function.1" = internal constant [43 x i8] c"unknown error when calling native function\00"

define i32 @"_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double* noalias nocapture %retptr.1, { i8*, i32 }** noalias nocapture %excinfo.1, double %arg.R1.1, double %arg.NTU1.1, i64 %arg.Np1.1, i64 %arg.Np2.1, i8 %arg.reverse.1) {
entry:
  %.11 = icmp eq i8 %arg.reverse.1, 0
  %.179 = alloca double
  store double 0.000000e+00, double* %.179
  %excinfo.2 = alloca { i8*, i32 }*
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo.2
  br i1 %.11, label %entry.if, label %entry.else

entry.if:                                         ; preds = %entry
  br label %entry.endif

entry.else:                                       ; preds = %entry
  br label %entry.endif

entry.endif:                                      ; preds = %entry.else, %entry.if
  %.9.0 = phi i1 [ false, %entry.if ], [ true, %entry.else ]
  %.38 = icmp eq i64 %arg.Np1.1, 1
  br i1 %.38, label %B10, label %B22

B10:                                              ; preds = %entry.endif
  %.64 = icmp eq i64 %arg.Np2.1, 1
  br i1 %.64, label %B18, label %B22

B18:                                              ; preds = %B10
  store double 1.100000e+00, double* %retptr.1
  ret i32 0

B22:                                              ; preds = %B10, %entry.endif
  br i1 %.9.0, label %B64, label %B26

B26:                                              ; preds = %B22
  %.131 = fcmp oeq double %arg.R1.1, 0.000000e+00
  br i1 %.131, label %B26.if, label %B26.endif, !prof !0

B64:                                              ; preds = %B22
  store { i8*, i32 }* @.const.picklebuf.140612147179104, { i8*, i32 }** %excinfo.1
  ret i32 1

B26.if:                                           ; preds = %B26
  store { i8*, i32 }* @.const.picklebuf.140612147179184, { i8*, i32 }** %excinfo.1
  ret i32 1

B26.endif:                                        ; preds = %B26
  %.140 = fdiv double 1.000000e+00, %arg.R1.1
  %.154 = fmul double %arg.NTU1.1, %arg.R1.1
  store double 0.000000e+00, double* %.179
  %.184 = call i32 @"_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double* %.179, { i8*, i32 }** %excinfo.2, double %.140, double %.154, i64 %arg.Np2.1, i64 %arg.Np1.1, i8 1)
  %.185 = load { i8*, i32 }*, { i8*, i32 }** %excinfo.2
  %.186 = icmp eq i32 %.184, 0
  %.187 = icmp eq i32 %.184, -2
  %.190 = or i1 %.186, %.187
  %.191 = xor i1 %.190, true
  %.192 = icmp sge i32 %.184, 1
  br i1 %.191, label %B26.endif.if, label %B26.endif.endif, !prof !0

B26.endif.if:                                     ; preds = %B26.endif
  store { i8*, i32 }* %.185, { i8*, i32 }** %excinfo.1
  br i1 true, label %B26.endif.if.if, label %B26.endif.endif

B26.endif.endif:                                  ; preds = %B26.endif.if, %B26.endif
  store double 1.300000e+00, double* %retptr.1
  ret i32 0

B26.endif.if.if:                                  ; preds = %B26.endif.if
  ret i32 %.184
}

define i8* @"_ZN7cpython8__main__35temperature_effectiveness_plate$242Eddxxb"(i8* %py_closure, i8* %py_args, i8* %py_kws) {
entry:
  %.5 = alloca i8*
  %.6 = alloca i8*
  %.7 = alloca i8*
  %.8 = alloca i8*
  %.9 = alloca i8*
  %.10 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([32 x i8], [32 x i8]* @.const.temperature_effectiveness_plate, i32 0, i32 0), i64 5, i64 5, i8** %.5, i8** %.6, i8** %.7, i8** %.8, i8** %.9)
  %.11 = icmp eq i32 %.10, 0
  %.82 = alloca double
  store double 0.000000e+00, double* %.82
  %excinfo = alloca { i8*, i32 }*
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo
  br i1 %.11, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.e...endif.endif.endif, %entry.endif.endif.endif.e...endif.endif.if, %entry.endif.endif.endif.e...endif.endif.if.if, %entry.endif.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif, %entry.endif.endif, %entry.endif.endif.endif.e...endif.endif.endif.if, %entry.endif.endif.endif.e...endif.1, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.15 = load i8*, i8** @"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb"
  %.16 = ptrtoint i8* %.15 to i64
  %.17 = add i64 %.16, 16
  %.18 = inttoptr i64 %.17 to i8*
  %.20 = icmp eq i8* null, %.15
  br i1 %.20, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i32 0, i32 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.24 = load i8*, i8** %.5
  %.25 = call i8* @PyNumber_Float(i8* %.24)
  %.26 = call double @PyFloat_AsDouble(i8* %.25)
  call void @Py_DecRef(i8* %.25)
  %.28 = call i8* @PyErr_Occurred()
  %.29 = icmp ne i8* null, %.28
  br i1 %.29, label %entry.if, label %entry.endif.endif.endif, !prof !0

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  %.33 = load i8*, i8** %.6
  %.34 = call i8* @PyNumber_Float(i8* %.33)
  %.35 = call double @PyFloat_AsDouble(i8* %.34)
  call void @Py_DecRef(i8* %.34)
  %.37 = call i8* @PyErr_Occurred()
  %.38 = icmp ne i8* null, %.37
  br i1 %.38, label %entry.if, label %entry.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  %.42 = load i8*, i8** %.7
  %.45 = call i8* @PyNumber_Long(i8* %.42)
  %.46 = icmp ne i8* null, %.45
  br i1 %.46, label %entry.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif, !prof !1

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.48 = call i64 @PyLong_AsLongLong(i8* %.45)
  call void @Py_DecRef(i8* %.45)
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif
  %.43.0 = phi i64 [ %.48, %entry.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif ]
  %.53 = call i8* @PyErr_Occurred()
  %.54 = icmp ne i8* null, %.53
  br i1 %.54, label %entry.if, label %entry.endif.endif.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.58 = load i8*, i8** %.8
  %.61 = call i8* @PyNumber_Long(i8* %.58)
  %.62 = icmp ne i8* null, %.61
  br i1 %.62, label %entry.endif.endif.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif.endif.endif, !prof !1

entry.endif.endif.endif.endif.endif.endif.if:     ; preds = %entry.endif.endif.endif.endif.endif.endif
  %.64 = call i64 @PyLong_AsLongLong(i8* %.61)
  call void @Py_DecRef(i8* %.61)
  br label %entry.endif.endif.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif.endif.endif:  ; preds = %entry.endif.endif.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif.endif.endif
  %.59.0 = phi i64 [ %.64, %entry.endif.endif.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif.endif.endif ]
  %.69 = call i8* @PyErr_Occurred()
  %.70 = icmp ne i8* null, %.69
  br i1 %.70, label %entry.if, label %entry.endif.endif.endif.endif.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif.endif.endif.endif.endif: ; preds = %entry.endif.endif.endif.endif.endif.endif.endif
  %.74 = load i8*, i8** %.9
  %.75 = call i32 @PyObject_IsTrue(i8* %.74)
  %.76 = icmp ne i32 %.75, 0
  %.77 = call i8* @PyErr_Occurred()
  %.78 = icmp ne i8* null, %.77
  br i1 %.78, label %entry.if, label %entry.endif.endif.endif.e...endif, !prof !0

entry.endif.endif.endif.e...endif:                ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif
  store double 0.000000e+00, double* %.82
  %.86 = zext i1 %.76 to i8
  %.87 = call i32 @"_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double* %.82, { i8*, i32 }** %excinfo, double %.26, double %.35, i64 %.43.0, i64 %.59.0, i8 %.86)
  %.88 = load { i8*, i32 }*, { i8*, i32 }** %excinfo
  %.89 = icmp eq i32 %.87, 0
  %.90 = icmp eq i32 %.87, -2
  %.93 = or i1 %.89, %.90
  %.95 = icmp sge i32 %.87, 1
  %.97 = load double, double* %.82
  switch i32 %.87, label %entry.endif.endif.endif.e...endif.endif [
    i32 -2, label %entry.endif.endif.endif.e...endif.if
    i32 0, label %entry.endif.endif.endif.e...endif.if
  ]

entry.endif.endif.endif.e...endif.if:             ; preds = %entry.endif.endif.endif.e...endif, %entry.endif.endif.endif.e...endif
  br i1 %.90, label %entry.endif.endif.endif.e...endif.if.if, label %entry.endif.endif.endif.e...endif.if.endif

entry.endif.endif.endif.e...endif.endif:          ; preds = %entry.endif.endif.endif.e...endif
  br i1 %.95, label %entry.endif.endif.endif.e...endif.endif.if, label %entry.endif.endif.endif.e...endif.endif.endif

entry.endif.endif.endif.e...endif.if.if:          ; preds = %entry.endif.endif.endif.e...endif.if
  call void @Py_IncRef(i8* @_Py_NoneStruct)
  ret i8* @_Py_NoneStruct

entry.endif.endif.endif.e...endif.if.endif:       ; preds = %entry.endif.endif.endif.e...endif.if
  %.102 = call i8* @PyFloat_FromDouble(double %.97)
  ret i8* %.102

entry.endif.endif.endif.e...endif.endif.if:       ; preds = %entry.endif.endif.endif.e...endif.endif
  call void @PyErr_Clear()
  %.107 = load { i8*, i32 }, { i8*, i32 }* %.88
  %.108 = extractvalue { i8*, i32 } %.107, 0
  %.110 = extractvalue { i8*, i32 } %.107, 1
  %.111 = call i8* @numba_unpickle(i8* %.108, i32 %.110)
  %.112 = icmp ne i8* null, %.111
  br i1 %.112, label %entry.endif.endif.endif.e...endif.endif.if.if, label %entry.if, !prof !1

entry.endif.endif.endif.e...endif.endif.endif:    ; preds = %entry.endif.endif.endif.e...endif.endif
  switch i32 %.87, label %entry.endif.endif.endif.e...endif.1 [
    i32 -3, label %entry.endif.endif.endif.e...endif.endif.endif.if
    i32 -1, label %entry.if
  ]

entry.endif.endif.endif.e...endif.endif.if.if:    ; preds = %entry.endif.endif.endif.e...endif.endif.if
  call void @numba_do_raise(i8* %.111)
  br label %entry.if

entry.endif.endif.endif.e...endif.endif.endif.if: ; preds = %entry.endif.endif.endif.e...endif.endif.endif
  call void @PyErr_SetNone(i8* @PyExc_StopIteration)
  br label %entry.if

entry.endif.endif.endif.e...endif.1:              ; preds = %entry.endif.endif.endif.e...endif.endif.endif
  call void @PyErr_SetString(i8* @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function", i32 0, i32 0))
  br label %entry.if
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...)

declare void @PyErr_SetString(i8*, i8*)

declare i8* @PyNumber_Float(i8*)

declare double @PyFloat_AsDouble(i8*)

declare void @Py_DecRef(i8*)

declare i8* @PyErr_Occurred()

declare i8* @PyNumber_Long(i8*)

declare i64 @PyLong_AsLongLong(i8*)

declare i32 @PyObject_IsTrue(i8*)

declare void @Py_IncRef(i8*)

declare i8* @PyFloat_FromDouble(double)

declare void @PyErr_Clear()

declare i8* @numba_unpickle(i8*, i32)

declare void @numba_do_raise(i8*)

declare void @PyErr_SetNone(i8*)

define double @"cfunc._ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double %.1, double %.2, i64 %.3, i64 %.4, i1 %.5) {
entry:
  %.7 = alloca double
  store double 0.000000e+00, double* %.7
  %excinfo = alloca { i8*, i32 }*
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo
  %.11 = zext i1 %.5 to i8
  %.12 = call i32 @"_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double* %.7, { i8*, i32 }** %excinfo, double %.1, double %.2, i64 %.3, i64 %.4, i8 %.11)
  %.13 = load { i8*, i32 }*, { i8*, i32 }** %excinfo
  %.14 = icmp eq i32 %.12, 0
  %.15 = icmp eq i32 %.12, -2
  %.18 = or i1 %.14, %.15
  %.19 = xor i1 %.18, true
  %.20 = icmp sge i32 %.12, 1
  %.22 = load double, double* %.7
  %.24 = alloca i32
  store i32 0, i32* %.24
  br i1 %.19, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry
  call void @numba_gil_ensure(i32* %.24)
  br i1 %.20, label %entry.if.if, label %entry.if.endif

entry.endif:                                      ; preds = %.27, %entry
  ret double %.22

.27:                                              ; preds = %entry.if.endif, %entry.if.if, %entry.if.if.if, %entry.if.endif.endif.endif, %entry.if.endif.if
  %.47 = call i8* @PyUnicode_FromString(i8* getelementptr inbounds ([53 x i8], [53 x i8]* @".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>", i32 0, i32 0))
  call void @PyErr_WriteUnraisable(i8* %.47)
  call void @Py_DecRef(i8* %.47)
  call void @numba_gil_release(i32* %.24)
  br label %entry.endif

entry.if.if:                                      ; preds = %entry.if
  call void @PyErr_Clear()
  %.30 = load { i8*, i32 }, { i8*, i32 }* %.13
  %.31 = extractvalue { i8*, i32 } %.30, 0
  %.33 = extractvalue { i8*, i32 } %.30, 1
  %.34 = call i8* @numba_unpickle(i8* %.31, i32 %.33)
  %.35 = icmp ne i8* null, %.34
  br i1 %.35, label %entry.if.if.if, label %.27, !prof !1

entry.if.endif:                                   ; preds = %entry.if
  switch i32 %.12, label %entry.if.endif.endif.endif [
    i32 -3, label %entry.if.endif.if
    i32 -1, label %.27
  ]

entry.if.if.if:                                   ; preds = %entry.if.if
  call void @numba_do_raise(i8* %.34)
  br label %.27

entry.if.endif.if:                                ; preds = %entry.if.endif
  call void @PyErr_SetNone(i8* @PyExc_StopIteration)
  br label %.27

entry.if.endif.endif.endif:                       ; preds = %entry.if.endif
  call void @PyErr_SetString(i8* @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function.1", i32 0, i32 0))
  br label %.27
}

declare void @numba_gil_ensure(i32*)

declare i8* @PyUnicode_FromString(i8*)

declare void @PyErr_WriteUnraisable(i8*)

declare void @numba_gil_release(i32*)

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
-----------------OPTIMIZED DUMP temperature_effectiveness_plate-----------------
; ModuleID = 'temperature_effectiveness_plate'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb" = common local_unnamed_addr global i8* null
@.const.picklebuf.140612147179104 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([163 x i8], [163 x i8]* @.const.pickledata.140612147179104, i32 0, i32 0), i32 163 }
@.const.picklebuf.140612147179184 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([69 x i8], [69 x i8]* @.const.pickledata.140612147179184, i32 0, i32 0), i32 69 }
@.const.pickledata.140612147179184 = internal constant [69 x i8] c"\80\04\95:\00\00\00\00\00\00\00\8C\08builtins\94\8C\11ZeroDivisionError\94\93\94\8C\10division by zero\94\85\94N\87\94."
@.const.pickledata.140612147179104 = internal constant [163 x i8] c"\80\04\95\98\00\00\00\00\00\00\00\8C\08builtins\94\8C\0AValueError\94\93\94\8C<Supported number of passes does not have a formula available\94\85\94\8C\1Ftemperature_effectiveness_plate\94\8C\11issue2_minimal.py\94K\0D\87\94\87\94."
@.const.temperature_effectiveness_plate = internal constant [32 x i8] c"temperature_effectiveness_plate\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>" = internal constant [53 x i8] c"<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>\00"

; Function Attrs: nounwind writeonly
define i32 @"_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double* noalias nocapture %retptr.1, { i8*, i32 }** noalias nocapture %excinfo.1, double %arg.R1.1, double %arg.NTU1.1, i64 %arg.Np1.1, i64 %arg.Np2.1, i8 %arg.reverse.1) local_unnamed_addr #0 {
entry:
  %.38 = icmp eq i64 %arg.Np1.1, 1
  %.64 = icmp eq i64 %arg.Np2.1, 1
  %or.cond = and i1 %.38, %.64
  br i1 %or.cond, label %B18, label %B22

B18:                                              ; preds = %entry
  store double 1.100000e+00, double* %retptr.1, align 8
  ret i32 0

B22:                                              ; preds = %entry
  %.11 = icmp eq i8 %arg.reverse.1, 0
  br i1 %.11, label %B26, label %B64

B26:                                              ; preds = %B22
  %.131 = fcmp oeq double %arg.R1.1, 0.000000e+00
  br i1 %.131, label %B26.if, label %B26.endif.if, !prof !0

B64:                                              ; preds = %B22
  store { i8*, i32 }* @.const.picklebuf.140612147179104, { i8*, i32 }** %excinfo.1, align 8
  ret i32 1

B26.if:                                           ; preds = %B26
  store { i8*, i32 }* @.const.picklebuf.140612147179184, { i8*, i32 }** %excinfo.1, align 8
  ret i32 1

B26.endif.if:                                     ; preds = %B26
  %0 = bitcast { i8*, i32 }** %excinfo.1 to i64*
  store i64 ptrtoint ({ i8*, i32 }* @.const.picklebuf.140612147179104 to i64), i64* %0, align 8
  ret i32 1
}

define i8* @"_ZN7cpython8__main__35temperature_effectiveness_plate$242Eddxxb"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = alloca i8*, align 8
  %.8 = alloca i8*, align 8
  %.9 = alloca i8*, align 8
  %.10 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([32 x i8], [32 x i8]* @.const.temperature_effectiveness_plate, i64 0, i64 0), i64 5, i64 5, i8** nonnull %.5, i8** nonnull %.6, i8** nonnull %.7, i8** nonnull %.8, i8** nonnull %.9)
  %.11 = icmp eq i32 %.10, 0
  br i1 %.11, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.e...endif.endif.if, %entry.endif.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif, %entry.endif.endif, %entry.endif.endif.endif.e...endif.endif.if.if, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.15 = load i8*, i8** @"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb", align 8
  %.20 = icmp eq i8* %.15, null
  br i1 %.20, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.24 = load i8*, i8** %.5, align 8
  %.25 = call i8* @PyNumber_Float(i8* %.24)
  %.26 = call double @PyFloat_AsDouble(i8* %.25)
  call void @Py_DecRef(i8* %.25)
  %.28 = call i8* @PyErr_Occurred()
  %.29 = icmp eq i8* %.28, null
  br i1 %.29, label %entry.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  %.33 = load i8*, i8** %.6, align 8
  %.34 = call i8* @PyNumber_Float(i8* %.33)
  %.35 = call double @PyFloat_AsDouble(i8* %.34)
  call void @Py_DecRef(i8* %.34)
  %.37 = call i8* @PyErr_Occurred()
  %.38 = icmp eq i8* %.37, null
  br i1 %.38, label %entry.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  %.42 = load i8*, i8** %.7, align 8
  %.45 = call i8* @PyNumber_Long(i8* %.42)
  %.46 = icmp eq i8* %.45, null
  br i1 %.46, label %entry.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.if, !prof !0

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.48 = call i64 @PyLong_AsLongLong(i8* nonnull %.45)
  call void @Py_DecRef(i8* nonnull %.45)
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif, %entry.endif.endif.endif.endif.if
  %.43.0 = phi i64 [ %.48, %entry.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif ]
  %.53 = call i8* @PyErr_Occurred()
  %.54 = icmp eq i8* %.53, null
  br i1 %.54, label %entry.endif.endif.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.58 = load i8*, i8** %.8, align 8
  %.61 = call i8* @PyNumber_Long(i8* %.58)
  %.62 = icmp eq i8* %.61, null
  br i1 %.62, label %entry.endif.endif.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.endif.endif.if, !prof !0

entry.endif.endif.endif.endif.endif.endif.if:     ; preds = %entry.endif.endif.endif.endif.endif.endif
  %.64 = call i64 @PyLong_AsLongLong(i8* nonnull %.61)
  call void @Py_DecRef(i8* nonnull %.61)
  br label %entry.endif.endif.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif.endif.endif:  ; preds = %entry.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif.endif.if
  %.59.0 = phi i64 [ %.64, %entry.endif.endif.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif.endif.endif ]
  %.69 = call i8* @PyErr_Occurred()
  %.70 = icmp eq i8* %.69, null
  br i1 %.70, label %entry.endif.endif.endif.endif.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif.endif.endif.endif: ; preds = %entry.endif.endif.endif.endif.endif.endif.endif
  %.74 = load i8*, i8** %.9, align 8
  %.75 = call i32 @PyObject_IsTrue(i8* %.74)
  %.77 = call i8* @PyErr_Occurred()
  %.78 = icmp eq i8* %.77, null
  br i1 %.78, label %entry.endif.endif.endif.e...endif, label %entry.if, !prof !1

entry.endif.endif.endif.e...endif:                ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif
  %.38.i = icmp eq i64 %.43.0, 1
  %.64.i = icmp eq i64 %.59.0, 1
  %or.cond.i = and i1 %.38.i, %.64.i
  br i1 %or.cond.i, label %entry.endif.endif.endif.e...endif.if.endif, label %B22.i

B22.i:                                            ; preds = %entry.endif.endif.endif.e...endif
  %.76 = icmp eq i32 %.75, 0
  br i1 %.76, label %B26.i, label %entry.endif.endif.endif.e...endif.endif.if

B26.i:                                            ; preds = %B22.i
  %.131.i = fcmp oeq double %.26, 0.000000e+00
  br i1 %.131.i, label %entry.endif.endif.endif.e...endif.endif.if, label %B26.endif.if.i, !prof !0

B26.endif.if.i:                                   ; preds = %B26.i
  br label %entry.endif.endif.endif.e...endif.endif.if

entry.endif.endif.endif.e...endif.if.endif:       ; preds = %entry.endif.endif.endif.e...endif
  %.102 = call i8* @PyFloat_FromDouble(double 1.100000e+00)
  ret i8* %.102

entry.endif.endif.endif.e...endif.endif.if:       ; preds = %B26.i, %B22.i, %B26.endif.if.i
  %excinfo.sroa.0.0.ph = phi i64 [ ptrtoint ({ i8*, i32 }* @.const.picklebuf.140612147179184 to i64), %B26.i ], [ ptrtoint ({ i8*, i32 }* @.const.picklebuf.140612147179104 to i64), %B22.i ], [ ptrtoint ({ i8*, i32 }* @.const.picklebuf.140612147179104 to i64), %B26.endif.if.i ]
  %0 = inttoptr i64 %excinfo.sroa.0.0.ph to { i8*, i32 }*
  call void @PyErr_Clear()
  %.107 = load { i8*, i32 }, { i8*, i32 }* %0, align 8
  %.108 = extractvalue { i8*, i32 } %.107, 0
  %.110 = extractvalue { i8*, i32 } %.107, 1
  %.111 = call i8* @numba_unpickle(i8* %.108, i32 %.110)
  %.112 = icmp eq i8* %.111, null
  br i1 %.112, label %entry.if, label %entry.endif.endif.endif.e...endif.endif.if.if, !prof !0

entry.endif.endif.endif.e...endif.endif.if.if:    ; preds = %entry.endif.endif.endif.e...endif.endif.if
  call void @numba_do_raise(i8* nonnull %.111)
  br label %entry.if
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i8* @PyNumber_Float(i8*) local_unnamed_addr

declare double @PyFloat_AsDouble(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyNumber_Long(i8*) local_unnamed_addr

declare i64 @PyLong_AsLongLong(i8*) local_unnamed_addr

declare i32 @PyObject_IsTrue(i8*) local_unnamed_addr

declare i8* @PyFloat_FromDouble(double) local_unnamed_addr

declare void @PyErr_Clear() local_unnamed_addr

declare i8* @numba_unpickle(i8*, i32) local_unnamed_addr

declare void @numba_do_raise(i8*) local_unnamed_addr

define double @"cfunc._ZN8__main__35temperature_effectiveness_plate$242Eddxxb"(double %.1, double %.2, i64 %.3, i64 %.4, i1 %.5) local_unnamed_addr {
entry:
  %.38.i = icmp eq i64 %.3, 1
  %.64.i = icmp eq i64 %.4, 1
  %or.cond.i = and i1 %.38.i, %.64.i
  br i1 %or.cond.i, label %entry.endif, label %B22.i

B22.i:                                            ; preds = %entry
  br i1 %.5, label %entry.if.if, label %B26.i

B26.i:                                            ; preds = %B22.i
  %.131.i = fcmp oeq double %.1, 0.000000e+00
  br i1 %.131.i, label %entry.if.if, label %B26.endif.if.i, !prof !0

B26.endif.if.i:                                   ; preds = %B26.i
  br label %entry.if.if

entry.endif:                                      ; preds = %entry, %.27
  %.7.06 = phi double [ 0.000000e+00, %.27 ], [ 1.100000e+00, %entry ]
  ret double %.7.06

.27:                                              ; preds = %entry.if.if, %entry.if.if.if
  %.47 = call i8* @PyUnicode_FromString(i8* getelementptr inbounds ([53 x i8], [53 x i8]* @".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>", i64 0, i64 0))
  call void @PyErr_WriteUnraisable(i8* %.47)
  call void @Py_DecRef(i8* %.47)
  call void @numba_gil_release(i32* nonnull %.245)
  br label %entry.endif

entry.if.if:                                      ; preds = %B22.i, %B26.i, %B26.endif.if.i
  %excinfo.sroa.0.0.ph = phi i64 [ ptrtoint ({ i8*, i32 }* @.const.picklebuf.140612147179184 to i64), %B26.i ], [ ptrtoint ({ i8*, i32 }* @.const.picklebuf.140612147179104 to i64), %B22.i ], [ ptrtoint ({ i8*, i32 }* @.const.picklebuf.140612147179104 to i64), %B26.endif.if.i ]
  %0 = inttoptr i64 %excinfo.sroa.0.0.ph to { i8*, i32 }*
  %.245 = alloca i32, align 4
  store i32 0, i32* %.245, align 4
  call void @numba_gil_ensure(i32* nonnull %.245)
  call void @PyErr_Clear()
  %.30 = load { i8*, i32 }, { i8*, i32 }* %0, align 8
  %.31 = extractvalue { i8*, i32 } %.30, 0
  %.33 = extractvalue { i8*, i32 } %.30, 1
  %.34 = call i8* @numba_unpickle(i8* %.31, i32 %.33)
  %.35 = icmp eq i8* %.34, null
  br i1 %.35, label %.27, label %entry.if.if.if, !prof !0

entry.if.if.if:                                   ; preds = %entry.if.if
  call void @numba_do_raise(i8* nonnull %.34)
  br label %.27
}

declare void @numba_gil_ensure(i32*) local_unnamed_addr

declare i8* @PyUnicode_FromString(i8*) local_unnamed_addr

declare void @PyErr_WriteUnraisable(i8*) local_unnamed_addr

declare void @numba_gil_release(i32*) local_unnamed_addr

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #1

attributes #0 = { nounwind writeonly }
attributes #1 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
--------------------ASSEMBLY temperature_effectiveness_plate--------------------
	.text
	.file	"<string>"
	.globl	_ZN8__main__35temperature_effectiveness_plate$242Eddxxb
	.p2align	4, 0x90
	.type	_ZN8__main__35temperature_effectiveness_plate$242Eddxxb,@function
_ZN8__main__35temperature_effectiveness_plate$242Eddxxb:
	cmpq	$1, %rdx
	jne	.LBB0_2
	cmpq	$1, %rcx
	jne	.LBB0_2
	movabsq	$4607632778762754458, %rax
	movq	%rax, (%rdi)
	xorl	%eax, %eax
	retq
.LBB0_2:
	testb	%r8b, %r8b
	jne	.LBB0_5
	vxorps	%xmm1, %xmm1, %xmm1
	vucomisd	%xmm1, %xmm0
	jne	.LBB0_5
	jnp	.LBB0_4
.LBB0_5:
	movabsq	$.const.picklebuf.140612147179104, %rax
	movq	%rax, (%rsi)
	movl	$1, %eax
	retq
.LBB0_4:
	movabsq	$.const.picklebuf.140612147179184, %rax
	movq	%rax, (%rsi)
	movl	$1, %eax
	retq
.Lfunc_end0:
	.size	_ZN8__main__35temperature_effectiveness_plate$242Eddxxb, .Lfunc_end0-_ZN8__main__35temperature_effectiveness_plate$242Eddxxb

	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI1_0:
	.quad	4607632778762754458
	.text
	.globl	_ZN7cpython8__main__35temperature_effectiveness_plate$242Eddxxb
	.p2align	4, 0x90
	.type	_ZN7cpython8__main__35temperature_effectiveness_plate$242Eddxxb,@function
_ZN7cpython8__main__35temperature_effectiveness_plate$242Eddxxb:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	pushq	%r15
	.cfi_def_cfa_offset 24
	pushq	%r14
	.cfi_def_cfa_offset 32
	pushq	%r13
	.cfi_def_cfa_offset 40
	pushq	%r12
	.cfi_def_cfa_offset 48
	pushq	%rbx
	.cfi_def_cfa_offset 56
	subq	$56, %rsp
	.cfi_def_cfa_offset 112
	.cfi_offset %rbx, -56
	.cfi_offset %r12, -48
	.cfi_offset %r13, -40
	.cfi_offset %r14, -32
	.cfi_offset %r15, -24
	.cfi_offset %rbp, -16
	movq	%rsi, %rdi
	subq	$8, %rsp
	.cfi_adjust_cfa_offset 8
	leaq	24(%rsp), %rbp
	leaq	32(%rsp), %rbx
	leaq	40(%rsp), %r10
	movabsq	$.const.temperature_effectiveness_plate, %rsi
	movabsq	$PyArg_UnpackTuple, %r11
	leaq	56(%rsp), %r8
	leaq	48(%rsp), %r9
	movl	$5, %edx
	movl	$5, %ecx
	movl	$0, %eax
	pushq	%rbp
	.cfi_adjust_cfa_offset 8
	pushq	%rbx
	.cfi_adjust_cfa_offset 8
	pushq	%r10
	.cfi_adjust_cfa_offset 8
	callq	*%r11
	addq	$32, %rsp
	.cfi_adjust_cfa_offset -32
	testl	%eax, %eax
	je	.LBB1_1
	movabsq	$_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb, %rax
	cmpq	$0, (%rax)
	je	.LBB1_4
	movq	48(%rsp), %rdi
	movabsq	$PyNumber_Float, %r14
	callq	*%r14
	movq	%rax, %rbx
	movabsq	$PyFloat_AsDouble, %rbp
	movq	%rax, %rdi
	callq	*%rbp
	vmovsd	%xmm0, 8(%rsp)
	movabsq	$Py_DecRef, %r12
	movq	%rbx, %rdi
	callq	*%r12
	movabsq	$PyErr_Occurred, %r15
	callq	*%r15
	testq	%rax, %rax
	jne	.LBB1_1
	movq	40(%rsp), %rdi
	callq	*%r14
	movq	%rax, %rbx
	movq	%rax, %rdi
	callq	*%rbp
	movq	%rbx, %rdi
	callq	*%r12
	callq	*%r15
	testq	%rax, %rax
	jne	.LBB1_1
	movq	32(%rsp), %rdi
	movabsq	$PyNumber_Long, %rbp
	callq	*%rbp
	movabsq	$PyLong_AsLongLong, %r13
	testq	%rax, %rax
	je	.LBB1_8
	movq	%rax, %rbx
	movq	%rax, %rdi
	callq	*%r13
	movq	%rax, %r14
	movq	%rbx, %rdi
	callq	*%r12
	callq	*%r15
	testq	%rax, %rax
	jne	.LBB1_1
.LBB1_11:
	movq	24(%rsp), %rdi
	callq	*%rbp
	testq	%rax, %rax
	je	.LBB1_12
	movq	%rax, %rbp
	movq	%rax, %rdi
	callq	*%r13
	movq	%rax, %rbx
	movq	%rbp, %rdi
	callq	*%r12
	callq	*%r15
	testq	%rax, %rax
	jne	.LBB1_1
.LBB1_15:
	movq	16(%rsp), %rdi
	movabsq	$PyObject_IsTrue, %rax
	callq	*%rax
	movl	%eax, %ebp
	callq	*%r15
	testq	%rax, %rax
	jne	.LBB1_1
	cmpq	$1, %r14
	jne	.LBB1_18
	cmpq	$1, %rbx
	jne	.LBB1_18
	movabsq	$PyFloat_FromDouble, %rax
	movabsq	$.LCPI1_0, %rcx
	vmovsd	(%rcx), %xmm0
	callq	*%rax
	jmp	.LBB1_2
.LBB1_18:
	movabsq	$.const.picklebuf.140612147179104, %rbx
	testl	%ebp, %ebp
	jne	.LBB1_21
	vxorps	%xmm0, %xmm0, %xmm0
	vmovsd	8(%rsp), %xmm1
	vucomisd	%xmm0, %xmm1
	jne	.LBB1_21
	jnp	.LBB1_20
.LBB1_21:
	movabsq	$PyErr_Clear, %rax
	callq	*%rax
	movl	8(%rbx), %esi
	movq	(%rbx), %rdi
	movabsq	$numba_unpickle, %rax
	callq	*%rax
	testq	%rax, %rax
	je	.LBB1_1
	movabsq	$numba_do_raise, %rcx
	movq	%rax, %rdi
	callq	*%rcx
.LBB1_1:
	xorl	%eax, %eax
.LBB1_2:
	addq	$56, %rsp
	.cfi_def_cfa_offset 56
	popq	%rbx
	.cfi_def_cfa_offset 48
	popq	%r12
	.cfi_def_cfa_offset 40
	popq	%r13
	.cfi_def_cfa_offset 32
	popq	%r14
	.cfi_def_cfa_offset 24
	popq	%r15
	.cfi_def_cfa_offset 16
	popq	%rbp
	.cfi_def_cfa_offset 8
	retq
.LBB1_4:
	.cfi_def_cfa_offset 112
	movabsq	$PyExc_RuntimeError, %rdi
	movabsq	$".const.missing Environment", %rsi
	movabsq	$PyErr_SetString, %rax
	callq	*%rax
	jmp	.LBB1_1
.LBB1_8:
	xorl	%r14d, %r14d
	callq	*%r15
	testq	%rax, %rax
	je	.LBB1_11
	jmp	.LBB1_1
.LBB1_12:
	xorl	%ebx, %ebx
	callq	*%r15
	testq	%rax, %rax
	je	.LBB1_15
	jmp	.LBB1_1
.LBB1_20:
	movabsq	$.const.picklebuf.140612147179184, %rbx
	jmp	.LBB1_21
.Lfunc_end1:
	.size	_ZN7cpython8__main__35temperature_effectiveness_plate$242Eddxxb, .Lfunc_end1-_ZN7cpython8__main__35temperature_effectiveness_plate$242Eddxxb
	.cfi_endproc

	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI2_0:
	.quad	4607632778762754458
	.text
	.globl	cfunc._ZN8__main__35temperature_effectiveness_plate$242Eddxxb
	.p2align	4, 0x90
	.type	cfunc._ZN8__main__35temperature_effectiveness_plate$242Eddxxb,@function
cfunc._ZN8__main__35temperature_effectiveness_plate$242Eddxxb:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	pushq	%r14
	pushq	%rbx
	.cfi_offset %rbx, -32
	.cfi_offset %r14, -24
	cmpq	$1, %rdi
	jne	.LBB2_3
	cmpq	$1, %rsi
	jne	.LBB2_3
	movabsq	$.LCPI2_0, %rax
	vmovsd	(%rax), %xmm0
	jmp	.LBB2_8
.LBB2_3:
	movabsq	$.const.picklebuf.140612147179104, %rbx
	testb	$1, %dl
	jne	.LBB2_6
	vxorps	%xmm1, %xmm1, %xmm1
	vucomisd	%xmm1, %xmm0
	jne	.LBB2_6
	jnp	.LBB2_5
.LBB2_6:
	movq	%rsp, %rax
	leaq	-16(%rax), %r14
	movq	%r14, %rsp
	movl	$0, -16(%rax)
	movabsq	$numba_gil_ensure, %rax
	movq	%r14, %rdi
	callq	*%rax
	movabsq	$PyErr_Clear, %rax
	callq	*%rax
	movl	8(%rbx), %esi
	movq	(%rbx), %rdi
	movabsq	$numba_unpickle, %rax
	callq	*%rax
	testq	%rax, %rax
	je	.LBB2_7
	movabsq	$numba_do_raise, %rcx
	movq	%rax, %rdi
	callq	*%rcx
.LBB2_7:
	movabsq	$".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>", %rdi
	movabsq	$PyUnicode_FromString, %rax
	callq	*%rax
	movq	%rax, %rbx
	movabsq	$PyErr_WriteUnraisable, %rax
	movq	%rbx, %rdi
	callq	*%rax
	movabsq	$Py_DecRef, %rax
	movq	%rbx, %rdi
	callq	*%rax
	movabsq	$numba_gil_release, %rax
	movq	%r14, %rdi
	callq	*%rax
	vxorps	%xmm0, %xmm0, %xmm0
.LBB2_8:
	leaq	-16(%rbp), %rsp
	popq	%rbx
	popq	%r14
	popq	%rbp
	.cfi_def_cfa %rsp, 8
	retq
.LBB2_5:
	.cfi_def_cfa %rbp, 16
	movabsq	$.const.picklebuf.140612147179184, %rbx
	jmp	.LBB2_6
.Lfunc_end2:
	.size	cfunc._ZN8__main__35temperature_effectiveness_plate$242Eddxxb, .Lfunc_end2-cfunc._ZN8__main__35temperature_effectiveness_plate$242Eddxxb
	.cfi_endproc

	.type	_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb,@object
	.comm	_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$242Eddxxb,8,8
	.type	.const.picklebuf.140612147179104,@object
	.section	.rodata,"a",@progbits
	.p2align	3
.const.picklebuf.140612147179104:
	.quad	.const.pickledata.140612147179104
	.long	163
	.zero	4
	.size	.const.picklebuf.140612147179104, 16

	.type	.const.picklebuf.140612147179184,@object
	.p2align	3
.const.picklebuf.140612147179184:
	.quad	.const.pickledata.140612147179184
	.long	69
	.zero	4
	.size	.const.picklebuf.140612147179184, 16

	.type	.const.pickledata.140612147179184,@object
	.p2align	4
.const.pickledata.140612147179184:
	.ascii	"\200\004\225:\000\000\000\000\000\000\000\214\bbuiltins\224\214\021ZeroDivisionError\224\223\224\214\020division by zero\224\205\224N\207\224."
	.size	.const.pickledata.140612147179184, 69

	.type	.const.pickledata.140612147179104,@object
	.p2align	4
.const.pickledata.140612147179104:
	.ascii	"\200\004\225\230\000\000\000\000\000\000\000\214\bbuiltins\224\214\nValueError\224\223\224\214<Supported number of passes does not have a formula available\224\205\224\214\037temperature_effectiveness_plate\224\214\021issue2_minimal.py\224K\r\207\224\207\224."
	.size	.const.pickledata.140612147179104, 163

	.type	.const.temperature_effectiveness_plate,@object
	.p2align	4
.const.temperature_effectiveness_plate:
	.asciz	"temperature_effectiveness_plate"
	.size	.const.temperature_effectiveness_plate, 32

	.type	".const.missing Environment",@object
	.p2align	4
".const.missing Environment":
	.asciz	"missing Environment"
	.size	".const.missing Environment", 20

	.type	".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>",@object
	.p2align	4
".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>":
	.asciz	"<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>"
	.size	".const.<numba.core.cpu.CPUContext object at 0x7fe2d115e6d0>", 53


	.section	".note.GNU-stack","",@progbits

================================================================================
[cache] index loaded from '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.nbi'
[cache] index saved to '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.nbi'
[cache] data saved to '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.1.nbc'
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := float64,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := float64,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := float64,
 arg.Np1 := int64,
 arg.Np2 := int64,
 arg.R1 := float64,
 arg.reverse := omitted(default=False),
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
-----------------------------------propagate------------------------------------
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $20return_value.1 := float64,
 $24pred := bool,
 $30binary_true_divide.2 := float64,
 $38binary_multiply.5 := float64,
 $42load_global.6 := recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 $56call_function_kw.13 := float64,
 $62return_value.15 := float64,
 $64load_global.0 := ValueError,
 $68call_function.2 := ValueError(...),
 $6compare_op.2 := bool,
 $8pred := bool,
 $const12.1 := Literal[int](1),
 $const18.0 := float64,
 $const26.0 := float64,
 $const4.1 := Literal[int](1),
 $const52.11 := bool,
 $const60.14 := float64,
 $const66.1 := Literal[str](Supported number of passes does not have a formula available),
 NTU1 := float64,
 NTU2 := float64,
 Np1 := int64,
 Np2 := int64,
 P2 := float64,
 R1 := float64,
 R2 := float64,
 arg.NTU1 := float64,
 arg.Np1 := int64,
 arg.Np2 := int64,
 arg.R1 := float64,
 arg.reverse := omitted(default=False),
 bool16 := Function(<class 'bool'>),
 bool24 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 reverse := bool]
---------------------------------Variable types---------------------------------
{'$14compare_op.2': bool,
 '$16pred': bool,
 '$20return_value.1': float64,
 '$24pred': bool,
 '$30binary_true_divide.2': float64,
 '$38binary_multiply.5': float64,
 '$42load_global.6': recursive(type(CPUDispatcher(<function temperature_effectiveness_plate at 0x7fe2e32c4ef0>))),
 '$56call_function_kw.13': float64,
 '$62return_value.15': float64,
 '$64load_global.0': ValueError,
 '$68call_function.2': ValueError(...),
 '$6compare_op.2': bool,
 '$8pred': bool,
 '$const12.1': Literal[int](1),
 '$const18.0': float64,
 '$const26.0': float64,
 '$const4.1': Literal[int](1),
 '$const52.11': bool,
 '$const60.14': float64,
 '$const66.1': Literal[str](Supported number of passes does not have a formula available),
 'NTU1': float64,
 'NTU2': float64,
 'Np1': int64,
 'Np2': int64,
 'P2': float64,
 'R1': float64,
 'R2': float64,
 'arg.NTU1': float64,
 'arg.Np1': int64,
 'arg.Np2': int64,
 'arg.R1': float64,
 'arg.reverse': omitted(default=False),
 'bool16': Function(<class 'bool'>),
 'bool24': Function(<class 'bool'>),
 'bool8': Function(<class 'bool'>),
 'reverse': bool}
----------------------------------Return type-----------------------------------
float64
-----------------------------------Call types-----------------------------------
{$const26.0 / R1: (float64, float64) -> float64,
 NTU1 * R1: (float64, float64) -> float64,
 Np1 == $const4.1: (int64, int64) -> bool,
 Np2 == $const12.1: (int64, int64) -> bool,
 call $42load_global.6(func=$42load_global.6, args=[], kws=[('R1', Var(R2, issue2_minimal.py:8)), ('NTU1', Var(NTU2, issue2_minimal.py:9)), ('Np1', Var(Np2, issue2_minimal.py:5)), ('Np2', Var(Np1, issue2_minimal.py:5)), ('reverse', Var($const52.11, issue2_minimal.py:11))], vararg=None): (float64, float64, int64, int64, bool) -> float64,
 call $64load_global.0($const66.1, func=$64load_global.0, args=[Var($const66.1, issue2_minimal.py:13)], kws=(), vararg=None): () -> ValueError(...),
 call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None): (bool,) -> bool,
 call bool24(reverse, func=bool24, args=(Var(reverse, issue2_minimal.py:5),), kws=(), vararg=None): (bool,) -> bool,
 call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, issue2_minimal.py:5),), kws=(), vararg=None): (bool,) -> bool}
------LLVM DUMP <function descriptor 'temperature_effectiveness_plate$1'>-------
; ModuleID = "temperature_effectiveness_plate$1"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"

@"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29" = common global i8* null
define i32 @"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"(double* noalias nocapture %"retptr", {i8*, i32}** noalias nocapture %"excinfo", double %"arg.R1", double %"arg.NTU1", i64 %"arg.Np1", i64 %"arg.Np2") 
{
entry:
  %"R1" = alloca double
  store double 0.0, double* %"R1"
  %"NTU1" = alloca double
  store double 0.0, double* %"NTU1"
  %"Np1" = alloca i64
  store i64 0, i64* %"Np1"
  %"Np2" = alloca i64
  store i64 0, i64* %"Np2"
  %"reverse" = alloca i1
  store i1 0, i1* %"reverse"
  %"$const4.1" = alloca i64
  store i64 0, i64* %"$const4.1"
  %"$6compare_op.2" = alloca i1
  store i1 0, i1* %"$6compare_op.2"
  %"bool8" = alloca i8*
  store i8* null, i8** %"bool8"
  %"$8pred" = alloca i1
  store i1 0, i1* %"$8pred"
  %"$const12.1" = alloca i64
  store i64 0, i64* %"$const12.1"
  %"$14compare_op.2" = alloca i1
  store i1 0, i1* %"$14compare_op.2"
  %"bool16" = alloca i8*
  store i8* null, i8** %"bool16"
  %"$16pred" = alloca i1
  store i1 0, i1* %"$16pred"
  %"$const18.0" = alloca double
  store double 0.0, double* %"$const18.0"
  %"$20return_value.1" = alloca double
  store double 0.0, double* %"$20return_value.1"
  %"bool24" = alloca i8*
  store i8* null, i8** %"bool24"
  %"$24pred" = alloca i1
  store i1 0, i1* %"$24pred"
  %"$const26.0" = alloca double
  store double 0.0, double* %"$const26.0"
  %"try_state" = alloca i64
  store i64 0, i64* %"try_state"
  %"$30binary_true_divide.2" = alloca double
  store double 0.0, double* %"$30binary_true_divide.2"
  %"R2" = alloca double
  store double 0.0, double* %"R2"
  %"$38binary_multiply.5" = alloca double
  store double 0.0, double* %"$38binary_multiply.5"
  %"NTU2" = alloca double
  store double 0.0, double* %"NTU2"
  %"$42load_global.6" = alloca i8*
  store i8* null, i8** %"$42load_global.6"
  %"$const52.11" = alloca i1
  store i1 0, i1* %"$const52.11"
  %".171" = alloca double
  store double 0.0, double* %".171"
  %"excinfo.1" = alloca {i8*, i32}*
  store {i8*, i32}* null, {i8*, i32}** %"excinfo.1"
  %"$56call_function_kw.13" = alloca double
  store double 0.0, double* %"$56call_function_kw.13"
  %"P2" = alloca double
  store double 0.0, double* %"P2"
  %"$const60.14" = alloca double
  store double 0.0, double* %"$const60.14"
  %"$62return_value.15" = alloca double
  store double 0.0, double* %"$62return_value.15"
  %"$64load_global.0" = alloca i8*
  store i8* null, i8** %"$64load_global.0"
  %"$const66.1" = alloca i8*
  store i8* null, i8** %"$const66.1"
  %"$68call_function.2" = alloca i8*
  store i8* null, i8** %"$68call_function.2"
  br label %"B0"
B0:
  %".9" = load double, double* %"R1"
  store double %"arg.R1", double* %"R1"
  %".12" = load double, double* %"NTU1"
  store double %"arg.NTU1", double* %"NTU1"
  %".15" = load i64, i64* %"Np1"
  store i64 %"arg.Np1", i64* %"Np1"
  %".18" = load i64, i64* %"Np2"
  store i64 %"arg.Np2", i64* %"Np2"
  %".21" = load i1, i1* %"reverse"
  store i1 false, i1* %"reverse"
  %".24" = load i64, i64* %"$const4.1"
  store i64 1, i64* %"$const4.1"
  %".26" = load i64, i64* %"Np1"
  %".27" = load i64, i64* %"$const4.1"
  %".28" = icmp eq i64 %".26", 1
  %".30" = load i1, i1* %"$6compare_op.2"
  store i1 %".28", i1* %"$6compare_op.2"
  %".32" = load i64, i64* %"$const4.1"
  store i64 0, i64* %"$const4.1"
  %".35" = load i8*, i8** %"bool8"
  store i8* null, i8** %"bool8"
  %".37" = load i1, i1* %"$6compare_op.2"
  %".39" = load i1, i1* %"$8pred"
  store i1 %".37", i1* %"$8pred"
  %".41" = load i8*, i8** %"bool8"
  store i8* null, i8** %"bool8"
  %".43" = load i1, i1* %"$6compare_op.2"
  store i1 0, i1* %"$6compare_op.2"
  %".45" = load i1, i1* %"$8pred"
  br i1 %".45", label %"B10", label %"B22"
B10:
  %".47" = load i1, i1* %"$8pred"
  store i1 0, i1* %"$8pred"
  %".50" = load i64, i64* %"$const12.1"
  store i64 1, i64* %"$const12.1"
  %".52" = load i64, i64* %"Np2"
  %".53" = load i64, i64* %"$const12.1"
  %".54" = icmp eq i64 %".52", 1
  %".56" = load i1, i1* %"$14compare_op.2"
  store i1 %".54", i1* %"$14compare_op.2"
  %".58" = load i64, i64* %"$const12.1"
  store i64 0, i64* %"$const12.1"
  %".61" = load i8*, i8** %"bool16"
  store i8* null, i8** %"bool16"
  %".63" = load i1, i1* %"$14compare_op.2"
  %".65" = load i1, i1* %"$16pred"
  store i1 %".63", i1* %"$16pred"
  %".67" = load i8*, i8** %"bool16"
  store i8* null, i8** %"bool16"
  %".69" = load i1, i1* %"$14compare_op.2"
  store i1 0, i1* %"$14compare_op.2"
  %".71" = load i1, i1* %"$16pred"
  br i1 %".71", label %"B18", label %"B22"
B18:
  %".73" = load i1, i1* %"reverse"
  store i1 0, i1* %"reverse"
  %".75" = load double, double* %"R1"
  store double 0.0, double* %"R1"
  %".77" = load i64, i64* %"Np2"
  store i64 0, i64* %"Np2"
  %".79" = load i64, i64* %"Np1"
  store i64 0, i64* %"Np1"
  %".81" = load double, double* %"NTU1"
  store double 0.0, double* %"NTU1"
  %".83" = load i1, i1* %"$16pred"
  store i1 0, i1* %"$16pred"
  %".86" = load double, double* %"$const18.0"
  store double 0x3ff199999999999a, double* %"$const18.0"
  %".88" = load double, double* %"$const18.0"
  %".90" = load double, double* %"$20return_value.1"
  store double %".88", double* %"$20return_value.1"
  %".92" = load double, double* %"$const18.0"
  store double 0.0, double* %"$const18.0"
  %".94" = load double, double* %"$20return_value.1"
  store double %".94", double* %"retptr"
  ret i32 0
B22:
  %".97" = load i1, i1* %"$8pred"
  store i1 0, i1* %"$8pred"
  %".99" = load i1, i1* %"$16pred"
  store i1 0, i1* %"$16pred"
  %".102" = load i8*, i8** %"bool24"
  store i8* null, i8** %"bool24"
  %".104" = load i1, i1* %"reverse"
  %".106" = load i1, i1* %"$24pred"
  store i1 %".104", i1* %"$24pred"
  %".108" = load i1, i1* %"reverse"
  store i1 0, i1* %"reverse"
  %".110" = load i8*, i8** %"bool24"
  store i8* null, i8** %"bool24"
  %".112" = load i1, i1* %"$24pred"
  br i1 %".112", label %"B64", label %"B26"
B26:
  %".114" = load i1, i1* %"$24pred"
  store i1 0, i1* %"$24pred"
  %".117" = load double, double* %"$const26.0"
  store double 0x3ff0000000000000, double* %"$const26.0"
  %".119" = load double, double* %"$const26.0"
  %".120" = load double, double* %"R1"
  %".121" = fcmp oeq double %".120",              0x0
  br i1 %".121", label %"B26.if", label %"B26.endif", !prof !0
B64:
  %".231" = load double, double* %"R1"
  store double 0.0, double* %"R1"
  %".233" = load i64, i64* %"Np2"
  store i64 0, i64* %"Np2"
  %".235" = load i64, i64* %"Np1"
  store i64 0, i64* %"Np1"
  %".237" = load double, double* %"NTU1"
  store double 0.0, double* %"NTU1"
  %".239" = load i1, i1* %"$24pred"
  store i1 0, i1* %"$24pred"
  %".242" = load i8*, i8** %"$64load_global.0"
  store i8* null, i8** %"$64load_global.0"
  %".245" = load i8*, i8** %"$const66.1"
  store i8* null, i8** %"$const66.1"
  %".248" = load i8*, i8** %"$68call_function.2"
  store i8* null, i8** %"$68call_function.2"
  %".250" = load i8*, i8** %"$const66.1"
  store i8* null, i8** %"$const66.1"
  %".252" = load i8*, i8** %"$68call_function.2"
  store i8* null, i8** %"$68call_function.2"
  %".254" = load i8*, i8** %"$64load_global.0"
  store i8* null, i8** %"$64load_global.0"
  store {i8*, i32}* @".const.picklebuf.140612146881952", {i8*, i32}** %"excinfo"
  %".257" = load i64, i64* %"try_state"
  %".258" = icmp ugt i64 %".257", 0
  %".259" = load {i8*, i32}*, {i8*, i32}** %"excinfo"
  ret i32 1
B26.if:
  store {i8*, i32}* @".const.picklebuf.140612146880992", {i8*, i32}** %"excinfo"
  store i64 0, i64* %"try_state"
  %".126" = load i64, i64* %"try_state"
  %".127" = icmp ugt i64 %".126", 0
  %".128" = load {i8*, i32}*, {i8*, i32}** %"excinfo"
  ret i32 1
B26.endif:
  %".130" = fdiv double %".119", %".120"
  %".132" = load double, double* %"$30binary_true_divide.2"
  store double %".130", double* %"$30binary_true_divide.2"
  %".134" = load double, double* %"$const26.0"
  store double 0.0, double* %"$const26.0"
  %".136" = load double, double* %"$30binary_true_divide.2"
  %".138" = load double, double* %"R2"
  store double %".136", double* %"R2"
  %".140" = load double, double* %"$30binary_true_divide.2"
  store double 0.0, double* %"$30binary_true_divide.2"
  %".142" = load double, double* %"NTU1"
  %".143" = load double, double* %"R1"
  %".144" = fmul double %".142", %".143"
  %".146" = load double, double* %"$38binary_multiply.5"
  store double %".144", double* %"$38binary_multiply.5"
  %".148" = load double, double* %"R1"
  store double 0.0, double* %"R1"
  %".150" = load double, double* %"NTU1"
  store double 0.0, double* %"NTU1"
  %".152" = load double, double* %"$38binary_multiply.5"
  %".154" = load double, double* %"NTU2"
  store double %".152", double* %"NTU2"
  %".156" = load double, double* %"$38binary_multiply.5"
  store double 0.0, double* %"$38binary_multiply.5"
  %".159" = load i8*, i8** %"$42load_global.6"
  store i8* null, i8** %"$42load_global.6"
  %".162" = load i1, i1* %"$const52.11"
  store i1 true, i1* %"$const52.11"
  %".164" = load double, double* %"R2"
  %".165" = load double, double* %"NTU2"
  %".166" = load i64, i64* %"Np2"
  %".167" = load i64, i64* %"Np1"
  %".168" = load i1, i1* %"$const52.11"
  %".169" = load i8*, i8** @".numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"
  %".170" = bitcast i8* %".169" to i32 (double*, {i8*, i32}**, double, double, i64, i64, i8)*
  store double 0.0, double* %".171"
  %".175" = zext i1 %".168" to i8
  %".176" = call i32 %".170"(double* %".171", {i8*, i32}** %"excinfo.1", double %".164", double %".165", i64 %".166", i64 %".167", i8 %".175")
  %".177" = load {i8*, i32}*, {i8*, i32}** %"excinfo.1"
  %".178" = icmp eq i32 %".176", 0
  %".179" = icmp eq i32 %".176", -2
  %".180" = icmp eq i32 %".176", -1
  %".181" = icmp eq i32 %".176", -3
  %".182" = or i1 %".178", %".179"
  %".183" = xor i1 %".182", -1
  %".184" = icmp sge i32 %".176", 1
  %".185" = select i1 %".184", {i8*, i32}* %".177", {i8*, i32}* undef
  %".186" = load double, double* %".171"
  br i1 %".183", label %"B26.endif.if", label %"B26.endif.endif", !prof !0
B26.endif.if:
  %".188" = load i64, i64* %"try_state"
  %".189" = icmp ugt i64 %".188", 0
  %".190" = load {i8*, i32}*, {i8*, i32}** %"excinfo"
  store {i8*, i32}* %".185", {i8*, i32}** %"excinfo"
  %".192" = xor i1 %".189", -1
  br i1 %".192", label %"B26.endif.if.if", label %"B26.endif.if.endif"
B26.endif.endif:
  %".197" = load double, double* %"$56call_function_kw.13"
  store double %".186", double* %"$56call_function_kw.13"
  %".199" = load double, double* %"R2"
  store double 0.0, double* %"R2"
  %".201" = load i64, i64* %"Np2"
  store i64 0, i64* %"Np2"
  %".203" = load i64, i64* %"Np1"
  store i64 0, i64* %"Np1"
  %".205" = load double, double* %"NTU2"
  store double 0.0, double* %"NTU2"
  %".207" = load i1, i1* %"$const52.11"
  store i1 0, i1* %"$const52.11"
  %".209" = load i8*, i8** %"$42load_global.6"
  store i8* null, i8** %"$42load_global.6"
  %".211" = load double, double* %"$56call_function_kw.13"
  %".213" = load double, double* %"P2"
  store double %".211", double* %"P2"
  %".215" = load double, double* %"P2"
  store double 0.0, double* %"P2"
  %".217" = load double, double* %"$56call_function_kw.13"
  store double 0.0, double* %"$56call_function_kw.13"
  %".220" = load double, double* %"$const60.14"
  store double 0x3ff4cccccccccccd, double* %"$const60.14"
  %".222" = load double, double* %"$const60.14"
  %".224" = load double, double* %"$62return_value.15"
  store double %".222", double* %"$62return_value.15"
  %".226" = load double, double* %"$const60.14"
  store double 0.0, double* %"$const60.14"
  %".228" = load double, double* %"$62return_value.15"
  store double %".228", double* %"retptr"
  ret i32 0
B26.endif.if.if:
  ret i32 %".176"
B26.endif.if.endif:
  br label %"B26.endif.endif"
}

@".const.pickledata.140612146880992" = internal constant [69 x i8] c"\80\04\95:\00\00\00\00\00\00\00\8c\08builtins\94\8c\11ZeroDivisionError\94\93\94\8c\10division by zero\94\85\94N\87\94."
@".const.picklebuf.140612146880992" = internal constant {i8*, i32} {i8* bitcast ([69 x i8]* @".const.pickledata.140612146880992" to i8*), i32 69}
@".numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb" = external global i8*
@".const.pickledata.140612146881952" = internal constant [163 x i8] c"\80\04\95\98\00\00\00\00\00\00\00\8c\08builtins\94\8c\0aValueError\94\93\94\8c<Supported number of passes does not have a formula available\94\85\94\8c\1ftemperature_effectiveness_plate\94\8c\11issue2_minimal.py\94K\0d\87\94\87\94."
@".const.picklebuf.140612146881952" = internal constant {i8*, i32} {i8* bitcast ([163 x i8]* @".const.pickledata.140612146881952" to i8*), i32 163}
!0 = !{ !"branch_weights", i32 1, i32 99 }
================================================================================
================================================================================
------------FUNCTION OPTIMIZED DUMP temperature_effectiveness_plate-------------
; ModuleID = 'temperature_effectiveness_plate'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29" = common global i8* null
@.const.picklebuf.140612146881952 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([163 x i8], [163 x i8]* @.const.pickledata.140612146881952, i32 0, i32 0), i32 163 }
@.const.picklebuf.140612146880992 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([69 x i8], [69 x i8]* @.const.pickledata.140612146880992, i32 0, i32 0), i32 69 }
@".numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb" = external global i8*
@.const.pickledata.140612146880992 = internal constant [69 x i8] c"\80\04\95:\00\00\00\00\00\00\00\8C\08builtins\94\8C\11ZeroDivisionError\94\93\94\8C\10division by zero\94\85\94N\87\94."
@.const.pickledata.140612146881952 = internal constant [163 x i8] c"\80\04\95\98\00\00\00\00\00\00\00\8C\08builtins\94\8C\0AValueError\94\93\94\8C<Supported number of passes does not have a formula available\94\85\94\8C\1Ftemperature_effectiveness_plate\94\8C\11issue2_minimal.py\94K\0D\87\94\87\94."
@.const.temperature_effectiveness_plate = internal constant [32 x i8] c"temperature_effectiveness_plate\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@_Py_NoneStruct = external global i8
@PyExc_StopIteration = external global i8
@PyExc_SystemError = external global i8
@".const.unknown error when calling native function" = internal constant [43 x i8] c"unknown error when calling native function\00"

define i32 @"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"(double* noalias nocapture %retptr, { i8*, i32 }** noalias nocapture %excinfo, double %arg.R1, double %arg.NTU1, i64 %arg.Np1, i64 %arg.Np2) {
entry:
  %.171 = alloca double
  store double 0.000000e+00, double* %.171
  %excinfo.1 = alloca { i8*, i32 }*
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo.1
  %.28 = icmp eq i64 %arg.Np1, 1
  br i1 %.28, label %B10, label %B22

B10:                                              ; preds = %entry
  %.54 = icmp eq i64 %arg.Np2, 1
  br i1 %.54, label %B18, label %B22

B18:                                              ; preds = %B10
  store double 1.100000e+00, double* %retptr
  ret i32 0

B22:                                              ; preds = %B10, %entry
  br i1 false, label %B64, label %B26

B26:                                              ; preds = %B22
  %.121 = fcmp oeq double %arg.R1, 0.000000e+00
  br i1 %.121, label %B26.if, label %B26.endif, !prof !0

B64:                                              ; preds = %B22
  store { i8*, i32 }* @.const.picklebuf.140612146881952, { i8*, i32 }** %excinfo
  ret i32 1

B26.if:                                           ; preds = %B26
  store { i8*, i32 }* @.const.picklebuf.140612146880992, { i8*, i32 }** %excinfo
  ret i32 1

B26.endif:                                        ; preds = %B26
  %.130 = fdiv double 1.000000e+00, %arg.R1
  %.144 = fmul double %arg.NTU1, %arg.R1
  %.169 = load i8*, i8** @".numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb"
  %.170 = bitcast i8* %.169 to i32 (double*, { i8*, i32 }**, double, double, i64, i64, i8)*
  store double 0.000000e+00, double* %.171
  %.176 = call i32 %.170(double* %.171, { i8*, i32 }** %excinfo.1, double %.130, double %.144, i64 %arg.Np2, i64 %arg.Np1, i8 1)
  %.177 = load { i8*, i32 }*, { i8*, i32 }** %excinfo.1
  %.178 = icmp eq i32 %.176, 0
  %.179 = icmp eq i32 %.176, -2
  %.182 = or i1 %.178, %.179
  %.183 = xor i1 %.182, true
  %.184 = icmp sge i32 %.176, 1
  br i1 %.183, label %B26.endif.if, label %B26.endif.endif, !prof !0

B26.endif.if:                                     ; preds = %B26.endif
  store { i8*, i32 }* %.177, { i8*, i32 }** %excinfo
  br i1 true, label %B26.endif.if.if, label %B26.endif.endif

B26.endif.endif:                                  ; preds = %B26.endif.if, %B26.endif
  store double 1.300000e+00, double* %retptr
  ret i32 0

B26.endif.if.if:                                  ; preds = %B26.endif.if
  ret i32 %.176
}

define i8* @"_ZN7cpython8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"(i8* %py_closure, i8* %py_args, i8* %py_kws) {
entry:
  %.5 = alloca i8*
  %.6 = alloca i8*
  %.7 = alloca i8*
  %.8 = alloca i8*
  %.9 = alloca i8*
  %.10 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([32 x i8], [32 x i8]* @.const.temperature_effectiveness_plate, i32 0, i32 0), i64 5, i64 5, i8** %.5, i8** %.6, i8** %.7, i8** %.8, i8** %.9)
  %.11 = icmp eq i32 %.10, 0
  %.74 = alloca double
  store double 0.000000e+00, double* %.74
  %excinfo = alloca { i8*, i32 }*
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo
  br i1 %.11, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.e...endif.endif, %entry.endif.endif.endif.e...endif.if, %entry.endif.endif.endif.e...endif.if.if, %entry.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif, %entry.endif.endif, %entry.endif.endif.endif.e...endif.endif.if, %entry.endif.endif.endif.e...endif.endif.endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.15 = load i8*, i8** @"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"
  %.16 = ptrtoint i8* %.15 to i64
  %.17 = add i64 %.16, 16
  %.18 = inttoptr i64 %.17 to i8*
  %.20 = icmp eq i8* null, %.15
  br i1 %.20, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i32 0, i32 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.24 = load i8*, i8** %.5
  %.25 = call i8* @PyNumber_Float(i8* %.24)
  %.26 = call double @PyFloat_AsDouble(i8* %.25)
  call void @Py_DecRef(i8* %.25)
  %.28 = call i8* @PyErr_Occurred()
  %.29 = icmp ne i8* null, %.28
  br i1 %.29, label %entry.if, label %entry.endif.endif.endif, !prof !0

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  %.33 = load i8*, i8** %.6
  %.34 = call i8* @PyNumber_Float(i8* %.33)
  %.35 = call double @PyFloat_AsDouble(i8* %.34)
  call void @Py_DecRef(i8* %.34)
  %.37 = call i8* @PyErr_Occurred()
  %.38 = icmp ne i8* null, %.37
  br i1 %.38, label %entry.if, label %entry.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  %.42 = load i8*, i8** %.7
  %.45 = call i8* @PyNumber_Long(i8* %.42)
  %.46 = icmp ne i8* null, %.45
  br i1 %.46, label %entry.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif, !prof !1

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.48 = call i64 @PyLong_AsLongLong(i8* %.45)
  call void @Py_DecRef(i8* %.45)
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif
  %.43.0 = phi i64 [ %.48, %entry.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif ]
  %.53 = call i8* @PyErr_Occurred()
  %.54 = icmp ne i8* null, %.53
  br i1 %.54, label %entry.if, label %entry.endif.endif.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.58 = load i8*, i8** %.8
  %.61 = call i8* @PyNumber_Long(i8* %.58)
  %.62 = icmp ne i8* null, %.61
  br i1 %.62, label %entry.endif.endif.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif.endif.endif, !prof !1

entry.endif.endif.endif.endif.endif.endif.if:     ; preds = %entry.endif.endif.endif.endif.endif.endif
  %.64 = call i64 @PyLong_AsLongLong(i8* %.61)
  call void @Py_DecRef(i8* %.61)
  br label %entry.endif.endif.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif.endif.endif:  ; preds = %entry.endif.endif.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif.endif.endif
  %.59.0 = phi i64 [ %.64, %entry.endif.endif.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif.endif.endif ]
  %.69 = call i8* @PyErr_Occurred()
  %.70 = icmp ne i8* null, %.69
  br i1 %.70, label %entry.if, label %entry.endif.endif.endif.endif.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif.endif.endif.endif.endif: ; preds = %entry.endif.endif.endif.endif.endif.endif.endif
  store double 0.000000e+00, double* %.74
  %.78 = call i32 @"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"(double* %.74, { i8*, i32 }** %excinfo, double %.26, double %.35, i64 %.43.0, i64 %.59.0)
  %.79 = load { i8*, i32 }*, { i8*, i32 }** %excinfo
  %.80 = icmp eq i32 %.78, 0
  %.81 = icmp eq i32 %.78, -2
  %.84 = or i1 %.80, %.81
  %.86 = icmp sge i32 %.78, 1
  %.88 = load double, double* %.74
  switch i32 %.78, label %entry.endif.endif.endif.e...endif [
    i32 -2, label %entry.endif.endif.endif.e...if
    i32 0, label %entry.endif.endif.endif.e...if
  ]

entry.endif.endif.endif.e...if:                   ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif.endif.endif.endif
  br i1 %.81, label %entry.endif.endif.endif.e...if.if, label %entry.endif.endif.endif.e...if.endif

entry.endif.endif.endif.e...endif:                ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif
  br i1 %.86, label %entry.endif.endif.endif.e...endif.if, label %entry.endif.endif.endif.e...endif.endif

entry.endif.endif.endif.e...if.if:                ; preds = %entry.endif.endif.endif.e...if
  call void @Py_IncRef(i8* @_Py_NoneStruct)
  ret i8* @_Py_NoneStruct

entry.endif.endif.endif.e...if.endif:             ; preds = %entry.endif.endif.endif.e...if
  %.93 = call i8* @PyFloat_FromDouble(double %.88)
  ret i8* %.93

entry.endif.endif.endif.e...endif.if:             ; preds = %entry.endif.endif.endif.e...endif
  call void @PyErr_Clear()
  %.98 = load { i8*, i32 }, { i8*, i32 }* %.79
  %.99 = extractvalue { i8*, i32 } %.98, 0
  %.101 = extractvalue { i8*, i32 } %.98, 1
  %.102 = call i8* @numba_unpickle(i8* %.99, i32 %.101)
  %.103 = icmp ne i8* null, %.102
  br i1 %.103, label %entry.endif.endif.endif.e...endif.if.if, label %entry.if, !prof !1

entry.endif.endif.endif.e...endif.endif:          ; preds = %entry.endif.endif.endif.e...endif
  switch i32 %.78, label %entry.endif.endif.endif.e...endif.endif.endif.endif [
    i32 -3, label %entry.endif.endif.endif.e...endif.endif.if
    i32 -1, label %entry.if
  ]

entry.endif.endif.endif.e...endif.if.if:          ; preds = %entry.endif.endif.endif.e...endif.if
  call void @numba_do_raise(i8* %.102)
  br label %entry.if

entry.endif.endif.endif.e...endif.endif.if:       ; preds = %entry.endif.endif.endif.e...endif.endif
  call void @PyErr_SetNone(i8* @PyExc_StopIteration)
  br label %entry.if

entry.endif.endif.endif.e...endif.endif.endif.endif: ; preds = %entry.endif.endif.endif.e...endif.endif
  call void @PyErr_SetString(i8* @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function", i32 0, i32 0))
  br label %entry.if
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...)

declare void @PyErr_SetString(i8*, i8*)

declare i8* @PyNumber_Float(i8*)

declare double @PyFloat_AsDouble(i8*)

declare void @Py_DecRef(i8*)

declare i8* @PyErr_Occurred()

declare i8* @PyNumber_Long(i8*)

declare i64 @PyLong_AsLongLong(i8*)

declare void @Py_IncRef(i8*)

declare i8* @PyFloat_FromDouble(double)

declare void @PyErr_Clear()

declare i8* @numba_unpickle(i8*, i32)

declare void @numba_do_raise(i8*)

declare void @PyErr_SetNone(i8*)

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
-----------------OPTIMIZED DUMP temperature_effectiveness_plate-----------------
; ModuleID = 'temperature_effectiveness_plate'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29" = common local_unnamed_addr global i8* null
@.const.picklebuf.140612146880992 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([69 x i8], [69 x i8]* @.const.pickledata.140612146880992, i32 0, i32 0), i32 69 }
@".numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb" = external local_unnamed_addr global i8*
@.const.pickledata.140612146880992 = internal constant [69 x i8] c"\80\04\95:\00\00\00\00\00\00\00\8C\08builtins\94\8C\11ZeroDivisionError\94\93\94\8C\10division by zero\94\85\94N\87\94."
@.const.temperature_effectiveness_plate = internal constant [32 x i8] c"temperature_effectiveness_plate\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@PyExc_StopIteration = external global i8
@PyExc_SystemError = external global i8
@".const.unknown error when calling native function" = internal constant [43 x i8] c"unknown error when calling native function\00"

define i32 @"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"(double* noalias nocapture %retptr, { i8*, i32 }** noalias nocapture %excinfo, double %arg.R1, double %arg.NTU1, i64 %arg.Np1, i64 %arg.Np2) local_unnamed_addr {
entry:
  %.171 = alloca double, align 8
  store double 0.000000e+00, double* %.171, align 8
  %excinfo.1 = alloca { i8*, i32 }*, align 8
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo.1, align 8
  %.28 = icmp eq i64 %arg.Np1, 1
  %.54 = icmp eq i64 %arg.Np2, 1
  %or.cond = and i1 %.28, %.54
  br i1 %or.cond, label %B18, label %B26

B18:                                              ; preds = %entry
  store double 1.100000e+00, double* %retptr, align 8
  ret i32 0

B26:                                              ; preds = %entry
  %.121 = fcmp oeq double %arg.R1, 0.000000e+00
  br i1 %.121, label %B26.if, label %B26.endif, !prof !0

B26.if:                                           ; preds = %B26
  store { i8*, i32 }* @.const.picklebuf.140612146880992, { i8*, i32 }** %excinfo, align 8
  ret i32 1

B26.endif:                                        ; preds = %B26
  %.130 = fdiv double 1.000000e+00, %arg.R1
  %.144 = fmul double %arg.R1, %arg.NTU1
  %.1691 = load i32 (double*, { i8*, i32 }**, double, double, i64, i64, i8)*, i32 (double*, { i8*, i32 }**, double, double, i64, i64, i8)** bitcast (i8** @".numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb" to i32 (double*, { i8*, i32 }**, double, double, i64, i64, i8)**), align 8
  store double 0.000000e+00, double* %.171, align 8
  %.176 = call i32 %.1691(double* nonnull %.171, { i8*, i32 }** nonnull %excinfo.1, double %.130, double %.144, i64 %arg.Np2, i64 %arg.Np1, i8 1)
  switch i32 %.176, label %B26.endif.if [
    i32 -2, label %B26.endif.endif
    i32 0, label %B26.endif.endif
  ]

B26.endif.if:                                     ; preds = %B26.endif
  %0 = bitcast { i8*, i32 }** %excinfo.1 to i64*
  %.1772 = load i64, i64* %0, align 8
  %1 = bitcast { i8*, i32 }** %excinfo to i64*
  store i64 %.1772, i64* %1, align 8
  ret i32 %.176

B26.endif.endif:                                  ; preds = %B26.endif, %B26.endif
  store double 1.300000e+00, double* %retptr, align 8
  ret i32 0
}

define i8* @"_ZN7cpython8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.171.i = alloca double, align 8
  %excinfo.1.i = alloca { i8*, i32 }*, align 8
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = alloca i8*, align 8
  %.8 = alloca i8*, align 8
  %.9 = alloca i8*, align 8
  %.10 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([32 x i8], [32 x i8]* @.const.temperature_effectiveness_plate, i64 0, i64 0), i64 5, i64 5, i8** nonnull %.5, i8** nonnull %.6, i8** nonnull %.7, i8** nonnull %.8, i8** nonnull %.9)
  %.11 = icmp eq i32 %.10, 0
  br i1 %.11, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.e...endif.if, %entry.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif, %entry.endif.endif, %entry.endif.endif.endif.e...endif.endif, %entry.endif.endif.endif.e...endif.if.if, %entry.endif.endif.endif.e...endif.endif.if, %entry.endif.endif.endif.e...endif.endif.endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.15 = load i8*, i8** @"_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29", align 8
  %.20 = icmp eq i8* %.15, null
  br i1 %.20, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.24 = load i8*, i8** %.5, align 8
  %.25 = call i8* @PyNumber_Float(i8* %.24)
  %.26 = call double @PyFloat_AsDouble(i8* %.25)
  call void @Py_DecRef(i8* %.25)
  %.28 = call i8* @PyErr_Occurred()
  %.29 = icmp eq i8* %.28, null
  br i1 %.29, label %entry.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif:                          ; preds = %entry.endif.endif
  %.33 = load i8*, i8** %.6, align 8
  %.34 = call i8* @PyNumber_Float(i8* %.33)
  %.35 = call double @PyFloat_AsDouble(i8* %.34)
  call void @Py_DecRef(i8* %.34)
  %.37 = call i8* @PyErr_Occurred()
  %.38 = icmp eq i8* %.37, null
  br i1 %.38, label %entry.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  %.42 = load i8*, i8** %.7, align 8
  %.45 = call i8* @PyNumber_Long(i8* %.42)
  %.46 = icmp eq i8* %.45, null
  br i1 %.46, label %entry.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.if, !prof !0

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.48 = call i64 @PyLong_AsLongLong(i8* nonnull %.45)
  call void @Py_DecRef(i8* nonnull %.45)
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif, %entry.endif.endif.endif.endif.if
  %.43.0 = phi i64 [ %.48, %entry.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif ]
  %.53 = call i8* @PyErr_Occurred()
  %.54 = icmp eq i8* %.53, null
  br i1 %.54, label %entry.endif.endif.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.58 = load i8*, i8** %.8, align 8
  %.61 = call i8* @PyNumber_Long(i8* %.58)
  %.62 = icmp eq i8* %.61, null
  br i1 %.62, label %entry.endif.endif.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.endif.endif.if, !prof !0

entry.endif.endif.endif.endif.endif.endif.if:     ; preds = %entry.endif.endif.endif.endif.endif.endif
  %.64 = call i64 @PyLong_AsLongLong(i8* nonnull %.61)
  call void @Py_DecRef(i8* nonnull %.61)
  br label %entry.endif.endif.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif.endif.endif:  ; preds = %entry.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif.endif.if
  %.59.0 = phi i64 [ %.64, %entry.endif.endif.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif.endif.endif ]
  %.69 = call i8* @PyErr_Occurred()
  %.70 = icmp eq i8* %.69, null
  br i1 %.70, label %entry.endif.endif.endif.endif.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif.endif.endif.endif: ; preds = %entry.endif.endif.endif.endif.endif.endif.endif
  %0 = bitcast double* %.171.i to i8*
  call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0)
  %1 = bitcast { i8*, i32 }** %excinfo.1.i to i8*
  call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %1)
  store double 0.000000e+00, double* %.171.i, align 8, !noalias !2
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo.1.i, align 8, !noalias !2
  %.28.i = icmp eq i64 %.43.0, 1
  %.54.i = icmp eq i64 %.59.0, 1
  %or.cond.i = and i1 %.28.i, %.54.i
  br i1 %or.cond.i, label %entry.endif.endif.endif.e...if.endif, label %B26.i

B26.i:                                            ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif
  %.121.i = fcmp oeq double %.26, 0.000000e+00
  br i1 %.121.i, label %entry.endif.endif.endif.e...endif.thread, label %B26.endif.i, !prof !0

entry.endif.endif.endif.e...endif.thread:         ; preds = %B26.i
  %2 = bitcast { i8*, i32 }** %excinfo.1.i to i8*
  %3 = bitcast double* %.171.i to i8*
  call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %3)
  call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %2)
  br label %entry.endif.endif.endif.e...endif.if

B26.endif.i:                                      ; preds = %B26.i
  %.130.i = fdiv double 1.000000e+00, %.26
  %.144.i = fmul double %.26, %.35
  %.1691.i = load i32 (double*, { i8*, i32 }**, double, double, i64, i64, i8)*, i32 (double*, { i8*, i32 }**, double, double, i64, i64, i8)** bitcast (i8** @".numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb" to i32 (double*, { i8*, i32 }**, double, double, i64, i64, i8)**), align 8, !noalias !2
  store double 0.000000e+00, double* %.171.i, align 8, !noalias !2
  %.176.i = call i32 %.1691.i(double* nonnull %.171.i, { i8*, i32 }** nonnull %excinfo.1.i, double %.130.i, double %.144.i, i64 %.59.0, i64 %.43.0, i8 1), !noalias !2
  switch i32 %.176.i, label %"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29.exit" [
    i32 -2, label %entry.endif.endif.endif.e...if.endif
    i32 0, label %entry.endif.endif.endif.e...if.endif
  ]

"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29.exit": ; preds = %B26.endif.i
  %4 = bitcast { i8*, i32 }** %excinfo.1.i to i8*
  %5 = bitcast double* %.171.i to i8*
  %.1772.i13 = load { i8*, i32 }*, { i8*, i32 }** %excinfo.1.i, align 8, !noalias !2
  call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %5)
  call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %4)
  %.86 = icmp sgt i32 %.176.i, 0
  br i1 %.86, label %entry.endif.endif.endif.e...endif.if, label %entry.endif.endif.endif.e...endif.endif

entry.endif.endif.endif.e...if.endif:             ; preds = %B26.endif.i, %B26.endif.i, %entry.endif.endif.endif.endif.endif.endif.endif.endif
  %.74.05 = phi double [ 1.100000e+00, %entry.endif.endif.endif.endif.endif.endif.endif.endif ], [ 1.300000e+00, %B26.endif.i ], [ 1.300000e+00, %B26.endif.i ]
  %6 = bitcast { i8*, i32 }** %excinfo.1.i to i8*
  %7 = bitcast double* %.171.i to i8*
  call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %7)
  call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %6)
  %.93 = call i8* @PyFloat_FromDouble(double %.74.05)
  ret i8* %.93

entry.endif.endif.endif.e...endif.if:             ; preds = %entry.endif.endif.endif.e...endif.thread, %"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29.exit"
  %8 = phi { i8*, i32 }* [ @.const.picklebuf.140612146880992, %entry.endif.endif.endif.e...endif.thread ], [ %.1772.i13, %"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29.exit" ]
  call void @PyErr_Clear()
  %.98 = load { i8*, i32 }, { i8*, i32 }* %8, align 8
  %.99 = extractvalue { i8*, i32 } %.98, 0
  %.101 = extractvalue { i8*, i32 } %.98, 1
  %.102 = call i8* @numba_unpickle(i8* %.99, i32 %.101)
  %.103 = icmp eq i8* %.102, null
  br i1 %.103, label %entry.if, label %entry.endif.endif.endif.e...endif.if.if, !prof !0

entry.endif.endif.endif.e...endif.endif:          ; preds = %"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29.exit"
  switch i32 %.176.i, label %entry.endif.endif.endif.e...endif.endif.endif.endif [
    i32 -3, label %entry.endif.endif.endif.e...endif.endif.if
    i32 -1, label %entry.if
  ]

entry.endif.endif.endif.e...endif.if.if:          ; preds = %entry.endif.endif.endif.e...endif.if
  call void @numba_do_raise(i8* nonnull %.102)
  br label %entry.if

entry.endif.endif.endif.e...endif.endif.if:       ; preds = %entry.endif.endif.endif.e...endif.endif
  call void @PyErr_SetNone(i8* nonnull @PyExc_StopIteration)
  br label %entry.if

entry.endif.endif.endif.e...endif.endif.endif.endif: ; preds = %entry.endif.endif.endif.e...endif.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function", i64 0, i64 0))
  br label %entry.if
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i8* @PyNumber_Float(i8*) local_unnamed_addr

declare double @PyFloat_AsDouble(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyNumber_Long(i8*) local_unnamed_addr

declare i64 @PyLong_AsLongLong(i8*) local_unnamed_addr

declare i8* @PyFloat_FromDouble(double) local_unnamed_addr

declare void @PyErr_Clear() local_unnamed_addr

declare i8* @numba_unpickle(i8*, i32) local_unnamed_addr

declare void @numba_do_raise(i8*) local_unnamed_addr

declare void @PyErr_SetNone(i8*) local_unnamed_addr

; Function Attrs: argmemonly nounwind
declare void @llvm.lifetime.start.p0i8(i64 immarg, i8* nocapture) #0

; Function Attrs: argmemonly nounwind
declare void @llvm.lifetime.end.p0i8(i64 immarg, i8* nocapture) #0

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #1

attributes #0 = { argmemonly nounwind }
attributes #1 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}
!2 = !{!3, !5}
!3 = distinct !{!3, !4, !"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29: %retptr"}
!4 = distinct !{!4, !"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29"}
!5 = distinct !{!5, !4, !"_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29: %excinfo"}

================================================================================
================================================================================
--------------------ASSEMBLY temperature_effectiveness_plate--------------------
	.text
	.file	"<string>"
	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI0_0:
	.quad	4607182418800017408
	.text
	.globl	_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29
	.p2align	4, 0x90
	.type	_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29,@function
_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29:
	.cfi_startproc
	pushq	%r14
	.cfi_def_cfa_offset 16
	pushq	%rbx
	.cfi_def_cfa_offset 24
	subq	$24, %rsp
	.cfi_def_cfa_offset 48
	.cfi_offset %rbx, -24
	.cfi_offset %r14, -16
	movq	%rdx, %rax
	movq	%rsi, %r14
	movq	%rdi, %rbx
	movq	$0, 16(%rsp)
	movq	$0, 8(%rsp)
	cmpq	$1, %rdx
	jne	.LBB0_5
	cmpq	$1, %rcx
	jne	.LBB0_5
	movabsq	$4607632778762754458, %rax
	jmp	.LBB0_3
.LBB0_5:
	vxorps	%xmm2, %xmm2, %xmm2
	vucomisd	%xmm2, %xmm0
	jne	.LBB0_7
	jnp	.LBB0_6
.LBB0_7:
	movabsq	$.LCPI0_0, %rdx
	vmovsd	(%rdx), %xmm2
	vdivsd	%xmm0, %xmm2, %xmm2
	vmulsd	%xmm1, %xmm0, %xmm1
	movabsq	$.numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb, %r9
	movq	$0, 16(%rsp)
	leaq	16(%rsp), %rdi
	leaq	8(%rsp), %rsi
	vmovapd	%xmm2, %xmm0
	movq	%rcx, %rdx
	movq	%rax, %rcx
	movl	$1, %r8d
	callq	*(%r9)
	cmpl	$-2, %eax
	je	.LBB0_10
	testl	%eax, %eax
	jne	.LBB0_9
.LBB0_10:
	movabsq	$4608533498688228557, %rax
.LBB0_3:
	movq	%rax, (%rbx)
	xorl	%eax, %eax
	addq	$24, %rsp
	.cfi_def_cfa_offset 24
	popq	%rbx
	.cfi_def_cfa_offset 16
	popq	%r14
	.cfi_def_cfa_offset 8
	retq
.LBB0_9:
	.cfi_def_cfa_offset 48
	movq	8(%rsp), %rcx
	movq	%rcx, (%r14)
	addq	$24, %rsp
	.cfi_def_cfa_offset 24
	popq	%rbx
	.cfi_def_cfa_offset 16
	popq	%r14
	.cfi_def_cfa_offset 8
	retq
.LBB0_6:
	.cfi_def_cfa_offset 48
	movabsq	$.const.picklebuf.140612146880992, %rax
	movq	%rax, (%r14)
	movl	$1, %eax
	addq	$24, %rsp
	.cfi_def_cfa_offset 24
	popq	%rbx
	.cfi_def_cfa_offset 16
	popq	%r14
	.cfi_def_cfa_offset 8
	retq
.Lfunc_end0:
	.size	_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29, .Lfunc_end0-_ZN8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29
	.cfi_endproc

	.section	.rodata.cst8,"aM",@progbits,8
	.p2align	3
.LCPI1_0:
	.quad	4607632778762754458
.LCPI1_1:
	.quad	4607182418800017408
.LCPI1_2:
	.quad	4608533498688228557
	.text
	.globl	_ZN7cpython8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29
	.p2align	4, 0x90
	.type	_ZN7cpython8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29,@function
_ZN7cpython8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	pushq	%r15
	.cfi_def_cfa_offset 24
	pushq	%r14
	.cfi_def_cfa_offset 32
	pushq	%r13
	.cfi_def_cfa_offset 40
	pushq	%r12
	.cfi_def_cfa_offset 48
	pushq	%rbx
	.cfi_def_cfa_offset 56
	subq	$72, %rsp
	.cfi_def_cfa_offset 128
	.cfi_offset %rbx, -56
	.cfi_offset %r12, -48
	.cfi_offset %r13, -40
	.cfi_offset %r14, -32
	.cfi_offset %r15, -24
	.cfi_offset %rbp, -16
	movq	%rsi, %rdi
	subq	$8, %rsp
	.cfi_adjust_cfa_offset 8
	leaq	72(%rsp), %rbp
	leaq	40(%rsp), %rbx
	leaq	48(%rsp), %r10
	movabsq	$.const.temperature_effectiveness_plate, %rsi
	movabsq	$PyArg_UnpackTuple, %r11
	leaq	64(%rsp), %r8
	leaq	56(%rsp), %r9
	movl	$5, %edx
	movl	$5, %ecx
	movl	$0, %eax
	pushq	%rbp
	.cfi_adjust_cfa_offset 8
	pushq	%rbx
	.cfi_adjust_cfa_offset 8
	pushq	%r10
	.cfi_adjust_cfa_offset 8
	callq	*%r11
	addq	$32, %rsp
	.cfi_adjust_cfa_offset -32
	testl	%eax, %eax
	je	.LBB1_1
	movabsq	$_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29, %rax
	cmpq	$0, (%rax)
	je	.LBB1_4
	movq	56(%rsp), %rdi
	movabsq	$PyNumber_Float, %r14
	callq	*%r14
	movq	%rax, %rbx
	movabsq	$PyFloat_AsDouble, %rbp
	movq	%rax, %rdi
	callq	*%rbp
	vmovsd	%xmm0, 24(%rsp)
	movabsq	$Py_DecRef, %r13
	movq	%rbx, %rdi
	callq	*%r13
	movabsq	$PyErr_Occurred, %r12
	callq	*%r12
	testq	%rax, %rax
	jne	.LBB1_1
	movq	48(%rsp), %rdi
	callq	*%r14
	movq	%rax, %rbx
	movq	%rax, %rdi
	callq	*%rbp
	vmovsd	%xmm0, 16(%rsp)
	movq	%rbx, %rdi
	callq	*%r13
	callq	*%r12
	testq	%rax, %rax
	jne	.LBB1_1
	movq	40(%rsp), %rdi
	movabsq	$PyNumber_Long, %rbp
	callq	*%rbp
	movabsq	$PyLong_AsLongLong, %r15
	testq	%rax, %rax
	je	.LBB1_9
	movq	%rax, %rbx
	movq	%rax, %rdi
	callq	*%r15
	movq	%rax, %r14
	movq	%rbx, %rdi
	callq	*%r13
	callq	*%r12
	testq	%rax, %rax
	jne	.LBB1_1
.LBB1_12:
	movq	32(%rsp), %rdi
	callq	*%rbp
	testq	%rax, %rax
	je	.LBB1_13
	movq	%rax, %rbx
	movq	%rax, %rdi
	callq	*%r15
	movq	%rax, %r15
	movq	%rbx, %rdi
	callq	*%r13
	callq	*%r12
	testq	%rax, %rax
	jne	.LBB1_1
.LBB1_16:
	movq	$0, 8(%rsp)
	movq	$0, (%rsp)
	cmpq	$1, %r14
	jne	.LBB1_20
	cmpq	$1, %r15
	jne	.LBB1_20
	movabsq	$.LCPI1_0, %rax
	vmovsd	(%rax), %xmm0
	jmp	.LBB1_19
.LBB1_20:
	vxorps	%xmm0, %xmm0, %xmm0
	vmovsd	24(%rsp), %xmm1
	vucomisd	%xmm0, %xmm1
	jne	.LBB1_22
	jnp	.LBB1_21
.LBB1_22:
	movabsq	$.LCPI1_1, %rax
	vmovsd	(%rax), %xmm0
	vdivsd	%xmm1, %xmm0, %xmm0
	vmulsd	16(%rsp), %xmm1, %xmm1
	movabsq	$.numba.unresolved$_ZN8__main__35temperature_effectiveness_plate$242Eddxxb, %rax
	movq	$0, 8(%rsp)
	leaq	8(%rsp), %rdi
	movq	%rsp, %rsi
	movq	%r15, %rdx
	movq	%r14, %rcx
	movl	$1, %r8d
	callq	*(%rax)
	movabsq	$.LCPI1_2, %rcx
	vmovsd	(%rcx), %xmm0
	cmpl	$-2, %eax
	je	.LBB1_19
	testl	%eax, %eax
	jne	.LBB1_24
.LBB1_19:
	movabsq	$PyFloat_FromDouble, %rax
	callq	*%rax
	jmp	.LBB1_2
.LBB1_24:
	jle	.LBB1_28
	movq	(%rsp), %rbx
.LBB1_26:
	movabsq	$PyErr_Clear, %rax
	callq	*%rax
	movl	8(%rbx), %esi
	movq	(%rbx), %rdi
	movabsq	$numba_unpickle, %rax
	callq	*%rax
	testq	%rax, %rax
	je	.LBB1_1
	movabsq	$numba_do_raise, %rcx
	movq	%rax, %rdi
	callq	*%rcx
	jmp	.LBB1_1
.LBB1_28:
	cmpl	$-3, %eax
	je	.LBB1_31
	cmpl	$-1, %eax
	je	.LBB1_1
	movabsq	$PyExc_SystemError, %rdi
	movabsq	$".const.unknown error when calling native function", %rsi
	jmp	.LBB1_5
.LBB1_31:
	movabsq	$PyExc_StopIteration, %rdi
	movabsq	$PyErr_SetNone, %rax
	callq	*%rax
	jmp	.LBB1_1
.LBB1_4:
	movabsq	$PyExc_RuntimeError, %rdi
	movabsq	$".const.missing Environment", %rsi
.LBB1_5:
	movabsq	$PyErr_SetString, %rax
	callq	*%rax
.LBB1_1:
	xorl	%eax, %eax
.LBB1_2:
	addq	$72, %rsp
	.cfi_def_cfa_offset 56
	popq	%rbx
	.cfi_def_cfa_offset 48
	popq	%r12
	.cfi_def_cfa_offset 40
	popq	%r13
	.cfi_def_cfa_offset 32
	popq	%r14
	.cfi_def_cfa_offset 24
	popq	%r15
	.cfi_def_cfa_offset 16
	popq	%rbp
	.cfi_def_cfa_offset 8
	retq
.LBB1_9:
	.cfi_def_cfa_offset 128
	xorl	%r14d, %r14d
	callq	*%r12
	testq	%rax, %rax
	je	.LBB1_12
	jmp	.LBB1_1
.LBB1_13:
	xorl	%r15d, %r15d
	callq	*%r12
	testq	%rax, %rax
	je	.LBB1_16
	jmp	.LBB1_1
.LBB1_21:
	movabsq	$.const.picklebuf.140612146880992, %rbx
	jmp	.LBB1_26
.Lfunc_end1:
	.size	_ZN7cpython8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29, .Lfunc_end1-_ZN7cpython8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29
	.cfi_endproc

	.type	_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29,@object
	.comm	_ZN08NumbaEnv8__main__35temperature_effectiveness_plate$241Eddxx28omitted$28default$3dFalse$29,8,8
	.type	.const.picklebuf.140612146880992,@object
	.section	.rodata,"a",@progbits
	.p2align	3
.const.picklebuf.140612146880992:
	.quad	.const.pickledata.140612146880992
	.long	69
	.zero	4
	.size	.const.picklebuf.140612146880992, 16

	.type	.const.pickledata.140612146880992,@object
	.p2align	4
.const.pickledata.140612146880992:
	.ascii	"\200\004\225:\000\000\000\000\000\000\000\214\bbuiltins\224\214\021ZeroDivisionError\224\223\224\214\020division by zero\224\205\224N\207\224."
	.size	.const.pickledata.140612146880992, 69

	.type	.const.temperature_effectiveness_plate,@object
	.p2align	4
.const.temperature_effectiveness_plate:
	.asciz	"temperature_effectiveness_plate"
	.size	.const.temperature_effectiveness_plate, 32

	.type	".const.missing Environment",@object
	.p2align	4
".const.missing Environment":
	.asciz	"missing Environment"
	.size	".const.missing Environment", 20

	.type	".const.unknown error when calling native function",@object
	.p2align	4
".const.unknown error when calling native function":
	.asciz	"unknown error when calling native function"
	.size	".const.unknown error when calling native function", 43


	.section	".note.GNU-stack","",@progbits

================================================================================
[cache] index loaded from '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.nbi'
[cache] index saved to '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.nbi'
[cache] data saved to '__pycache__/issue2_minimal.temperature_effectiveness_plate-3.py37m.2.nbc'
1.1
```
</details>


user: CalebBell
labels: caching: Issue involving caching
bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_6050: state: open
title: Support zero-length arrays in numba.cuda
body: As an example,
```python
@numba.cuda.jit
def foo():
    x = numba.cuda.local.array(shape=(2, 0), dtype=numba.int64)

foo()
```
gives `ValueError: array length <= 0`.

Currently these lines contain a workaround because of this issue:

https://github.com/numba/numba/blob/3399d618b334c75a7c5c1ab85ec02769fb3b4c3b/numba/cuda/cudadrv/devicearray.py#L432-L455

user: eric-wieser
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_6045: state: open
title: Passing an unusual slice into a jitted function gives a strange error
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
```python
import numba

@numba.njit
def fails_at_nothing(x): pass

fails_at_nothing(slice(1.0))
# TypeError: 'float' object cannot be interpreted as an integer
```
I'd expect either:
* No failure
* A chained exception explaining that numba only supports integral slices
user: eric-wieser
issue_6044: state: open
title: int(inf) does not raise OverflowError
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
```python
import numba

@numba.njit
def bar(x):
    return int(x)

bar(float('inf'))  # -9223372036854775808
# expected OverflowError: cannot convert float infinity to integer
```
user: eric-wieser
labels: good second issue: A good issue for second time contributors
bug - incorrect behavior: Bugs: incorrect behavior
issue_6033: state: open
title: Feature request jitclass inherting from Callable and class member support
body: From https://github.com/numba/numba/issues/2947, jitclass inheriting from e.g. `Callable` has numerous issues with unsupported class members, e.g.

```python
import numba
import numpy as np
from typing import Callable
from collections import OrderedDict

spec = OrderedDict()
for k in list("abc"):
    spec[k] = numba.float64

@numba.jitclass(spec)
class CallableQuadratic(Callable):
    def __init__(self, a, b, c):
        self.a = a
        self.b = b
        self.c = c

    def __call__(self, x):
        return self.c + x * (self.b + x * self.a)
```
gives:
```
TypeError: class members are not yet supported: __subclasshook__, __init_subclass__, __slots__, __class_getitem__, __abstractmethods__, _abc_impl, __orig_bases__, __parameters__
```
user: stuartarchibald
issue_6032: state: open
title: KeyError/PicklingError: Can't pickle class.. it's not found as numba.experimental.jitclass
body: Hello guys,

I am trying to use numba with @jitclass. I have multiple classes with class attribute members and typed lists

Do you have any idea why I get this error?

This is a sample code..

```
import numba as nb
from numba import jit, types, typed
from numba.experimental import jitclass
from numba import int64, float64

@jitclass([('x', float64), ('y', float64), ('z', float64)])
class Vector(object):
    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z


VectorType = Vector.class_type.instance_type

# VertexType = nb.deferred_type()
@jitclass([('pos', Vector.class_type.instance_type)])     
class Vertex(object):
    def __init__(self, pos):
        self.pos = pos

    def clone(self):
        return Vertex(self.pos)       

# VertexType.define(Vertex.class_type.instance_type)
VertexType = Vertex.class_type.instance_type   

# @jit(VertexType(VertexType), nopython=False)
# def CloneVertex(v):
#     return Vertex(Vector(v.pos.x, v.pos.y, v.pos.z))

@jitclass([('vertices', types.ListType(Vertex.class_type.instance_type)), ('shared', int64)])  
class Polygon(object):
    def __init__(self, vertices, shared):
        self.vertices = vertices
        self.shared = shared

PolygonType = Polygon.class_type.instance_type

def load_mesh(mesh_data):
    polygons = typed.List.empty_list(PolygonType)

    for polygon in mesh_data:
        vertices = typed.List.empty_list(VertexType)
        for v in polygon['vertices']:
             vertices.append( Vertex(Vector(v[0], v[1], v[2])) )
        polygons.append( Polygon(vertices, polygon['shared']) )

    return polygons

@jit(nopython=False)
def put_back(p):
    return p[0].vertices[0].x

mesh = [{'vertices': [(0.0, 0.0, 0.0), (1.0, 0.0, 1.0), (-1.0, -1.0, 0.0)], 'shared': 0}, {'vertices': [(1.0, 0.0, 0.0), (0.0, 0.0, 1.0), (1.0, -1.0, 0.0)], 'shared': 1}, {'vertices': [(1.0, 1.0, 0.0), (0.0, 1.0, 1.0), (1.0, -1.0, 1.0)], 'shared': 2}]


```

And I am using it from this code:
```


# load mesh..
p = load_mesh(mesh)
print(put_back(p))

```

the mesh object is a plain python list of dicts with floats inside..


user: rpopovici
issue_6026: state: open
title: Floating-point bit twiddling in CUDA
body: ## Feature request

I need to use `view` individual floating-point numbers as integers and backwards.  For example:
```python
np.array(np.array(23.65).view('i8') | 1).view('d').item()
```
should give `23.650000000000002` in CUDA device functions.

I also need to use `frexp` and `ldexp` in CUDA device functions.
user: zhihaoy
labels: CUDA: CUDA related issue/PR
issue_6018: state: open
title: Cache Fails When Cannot Find Unrelated Custom Definitions 
body: - [x] I have tried using the latest released version of Numba (0.50.1).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

When reading cached njitted functions it seems numba will try to load every overload it has encountered so far even if that overload is unrelated to the current execution of the function. When only using predefined types this works just fine, but user defined types like NamedTuples and jitclasses (I imagine there are others too), break this behavior in a way that is pretty confusing to the end user. Consider the following situation: 
1. The user defines a new custom type and uses it in an cache=True function
2. The user adds another custom type and uses it with the same function 
3. The user deletes the first custom type and runs their function again with the second type
4. The user gets an unpickling error because the overload associated with the first custom type cannot be resolved, even though it isn't being used.

Here is a reproducing example: `rep_cache_bug.py`
```python
import os,sys
from numba import njit
from numba.typed import List

do_both = len(sys.argv) > 1 and sys.argv[1] == "both"

@njit(cache=True)
def add_values(l):
	v = 0
	for x in l:
		v += x.value
	return v

store_code = '' + \
'from numba.core.types import NamedTuple, float64, unicode_type \n' + \
'from collections import namedtuple \n' + \
'Store = namedtuple("Store", ["name", "owner", "value"]) \n' + \
'Store_NT = NamedTuple([unicode_type,unicode_type,float64],Store) \n' 

shop_code = '' + \
'from numba.core.types import NamedTuple, float64, unicode_type \n'+  \
'from collections import namedtuple \n' + \
'Shop = namedtuple("Shop", ["name", "owner", "value"]) \n' + \
'Shop_NT = NamedTuple([unicode_type,unicode_type,float64],Shop) \n' 


with open("store.py", 'w') as f:
	f.write(store_code)

from store import Store, Store_NT 
stores = List.empty_list(Store_NT)
stores.append(Store("Franks", "Frank", 100.0))
stores.append(Store("Gems n stuff", "Alice", 600.0))

print(add_values(stores))
os.remove("store.py")

if(do_both):
	with open("shop.py", 'w') as f:
		f.write(shop_code)

	from shop import Shop, Shop_NT 
	shops = List.empty_list(Shop_NT)
	shops.append(Shop("Franks", "Frank", 100.0))
	shops.append(Shop("Gems n stuff", "Alice", 600.0))	

	print(add_values(shops))
	os.remove("shop.py")
```

First run
`python rep_cache_bug.py both`
Second run
`python rep_cache_bug.py`
Error
```
Traceback (most recent call last):
  File "rep_cache_bug.py", line 35, in <module>
    print(add_values(stores))
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 436, in _compile_for_args
    raise e
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 369, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 798, in compile
    cres = self._cache.load_overload(sig, self.targetctx)
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/caching.py", line 648, in load_overload
    return self._load_overload(sig, target_context)
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/caching.py", line 655, in _load_overload
    data = self._cache_file.load(key)
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/caching.py", line 497, in load
    overloads = self._load_index()
  File "/home/danny/.local/lib/python3.8/site-packages/numba/core/caching.py", line 525, in _load_index
    stamp, overloads = pickle.loads(data)
ModuleNotFoundError: No module named 'shop'
```
 
user: DannyWeitekamp
labels: discussion: An issue requiring discussion
caching: Issue involving caching
issue_6014: state: open
title: suggestion For Parallel loop and atomic container
body: As we discussed in the [issue 5108](https://github.com/numba/numba/issues/5108) 

There is need an atomic container to append in parallel loop. As far as I understand its require a lot of work.

Is there any possibility to make every parallel thread use their own container and at the give us merged one like hadoop map -reduce 
I think this could be easier than the atomic lock and modification.

Its very needed by.

Best
user: MyraBaba
issue_6012: state: open
title: BUG: Symbol not found: __powidf2
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
My CI runs have recently started failing on Windows 32 with `Symbol not found: __powidf2`

I don't have an easy to to repro other than running the code in my package `arch`.

Appveyor log is here:

https://ci.appveyor.com/project/bashtage/arch/build/job/f8xl4sqy63jled4t

I wonder if it is related to https://github.com/ldc-developers/ldc/issues/2262 
user: bashtage
labels: llvm: LLVM related issues
issue_6011: state: open
title: Signal handling inside compiled code
body: When writing a long running algorithm in Numba, it is not possible to terminate the process with Ctrl-C.  I learned about the cysignals package from the NumPy mailing list, and wonder if a similar idea would be useful for Numba:

https://cysignals.readthedocs.io/en/latest/interrupt.html#section-interrupt

A Numba equivalent to `sig_check()` seems useful, but `sig_on()` and `sig_off()` seem dangerous.
user: seibert
labels: good second issue: A good issue for second time contributors
issue_6007: state: open
title: Type inference failing on code explicitly not ran with certain variable type
body: - [x] I have tried using the latest released version of Numba
- [x] I have included below a minimal working reproducer 

I use numba with parts of code blocked off so it won't run if a certain variable is None. It is wonderful that numba recognizes that those code blocks won't run, so the type inference doesn't get upset multiplying a None by a number and so on.

I believe feature isn't quite smart enough to handle the case of two variables being None, however. The following code snippet reproduces the issue.

```
import numba

@numba.njit
def bend_rounded_Crane(Di, angle, rc=None, bend_diameters=None):
    if (rc is not None and bend_diameters is not None):
        if abs(Di*bend_diameters/rc - 1.0) > 1e-12:
            raise ValueError("Cannot specify both `rc` and `bend_diameters`")
    if rc is None:
        if bend_diameters is None:
            bend_diameters = 5.0
        rc = Di*bend_diameters
    return Di
print(numba.__version__)
bend_rounded_Crane(40.0, 15.0)
```

It is clear that the reader the first if statement block should not run/need type inference when the artuments `rc` and `bend_diameters` are both None, as in the example. However, numba fails on type inference.
```

0.50.1
Traceback (most recent call last):
  File "test.py", line 14, in <module>
    bend_rounded_Crane(40.0, 15.0)
  File "/home/caleb/.local/lib/python3.7/site-packages/numba/core/dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/caleb/.local/lib/python3.7/site-packages/numba/core/dispatcher.py", line 358, in error_rewrite
    reraise(type(e), e, None)
  File "/home/caleb/.local/lib/python3.7/site-packages/numba/core/utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function mul>) found for signature:
 
 >>> mul(float64, none)
 
There are 12 candidate implementations:
  - Of which 10 did not match due to:
  Overload of function 'mul': File: <numerous>: Line N/A.
    With argument(s): '(float64, none)':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'mul': File: unknown: Line unknown.
    With argument(s): '(float64, none)':
   No match for registered cases:
    * (int64, int64) -> int64
    * (int64, uint64) -> int64
    * (uint64, int64) -> int64
    * (uint64, uint64) -> uint64
    * (float32, float32) -> float32
    * (float64, float64) -> float64
    * (complex64, complex64) -> complex64
    * (complex128, complex128) -> complex128

During: typing of intrinsic-call at test.py (6)

File "test.py", line 6:
def bend_rounded_Crane(Di, angle, rc=None, bend_diameters=None):
    <source elided>
    if (rc is not None and bend_diameters is not None):
        if abs(Di*bend_diameters/rc - 1.0) > 1e-12:
        ^

```

By the way, I have been porting several open-source libraries I publish to run optionally with Numba - about 50,000 lines of code so far. The process is far from painless but it is very interesting to do. I also use PyPy for speed very often, so I have benchmarks for many things. Sometimes numba is better, sometimes PyPy is better. Both are really useful!

<details>
  <summary>Full output with NUMBA_DEBUG=1:</summary>
```
/home/caleb/.local/lib/python3.7/site-packages/numba/__init__.py:188: UserWarning: SVML was not found/could not be loaded.
  warnings.warn("SVML was not found/could not be loaded.")
================================================================================
--------------------------FUNCTION OPTIMIZED DUMP nrt---------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.139666276581936 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.139666276581936, i32 0, i32 0), i32 102 }
@.const.pickledata.139666276581936 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

define i64 @nrt_atomic_add(i64* %.1) {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

define i64 @nrt_atomic_sub(i64* %.1) {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = sub i64 %.4, 1
  ret i64 %.5
}

define i32 @nrt_atomic_cas(i64* %.1, i64 %.2, i64 %.3, i64* %.4) {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

define i8* @NRT_MemInfo_data_fast(i8* %.1) {
.3:
  %.4 = bitcast i8* %.1 to { i64, i8*, i8*, i8*, i64 }*
  %.5 = getelementptr { i64, i8*, i8*, i8*, i64 }, { i64, i8*, i8*, i8*, i64 }* %.4, i32 0, i32 3
  %.6 = load i8*, i8** %.5
  ret i8* %.6
}

; Function Attrs: noinline
define void @NRT_incref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.8 = call i64 @nrt_atomic_add(i64* %.7)
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif.if, %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.9 = call i64 @nrt_atomic_sub(i64* %.8)
  %.10 = icmp eq i64 %.9, 0
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  call void @NRT_MemInfo_call_dtor(i8* %.1)
  br label %.3.if
}

declare void @NRT_MemInfo_call_dtor(i8*)

define i32 @nrt_unresolved_abort(i8** %.1, { i8*, i32 }** %.2) {
.4:
  store { i8*, i32 }* @.const.picklebuf.139666276581936, { i8*, i32 }** %.2
  ret i32 1
}

attributes #0 = { noinline }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
-------------------------------OPTIMIZED DUMP nrt-------------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.139666276581936 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.139666276581936, i32 0, i32 0), i32 102 }
@.const.pickledata.139666276581936 = internal constant [102 x i8] c"\80\04\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_add(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i64 @nrt_atomic_sub(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, -1
  ret i64 %.5
}

; Function Attrs: nofree norecurse nounwind
define i32 @nrt_atomic_cas(i64* nocapture %.1, i64 %.2, i64 %.3, i64* nocapture %.4) local_unnamed_addr #0 {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4, align 8
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

; Function Attrs: norecurse nounwind readonly
define i8* @NRT_MemInfo_data_fast(i8* nocapture readonly %.1) local_unnamed_addr #1 {
.3:
  %.5 = getelementptr i8, i8* %.1, i64 24
  %0 = bitcast i8* %.5 to i8**
  %.6 = load i8*, i8** %0, align 8
  ret i8* %.6
}

; Function Attrs: nofree noinline norecurse nounwind
define void @NRT_incref(i8* %.1) local_unnamed_addr #2 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw add i64* %.7, i64 1 monotonic
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) local_unnamed_addr #3 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: nofree norecurse nounwind writeonly
define i32 @nrt_unresolved_abort(i8** nocapture readnone %.1, { i8*, i32 }** nocapture %.2) local_unnamed_addr #4 {
.4:
  store { i8*, i32 }* @.const.picklebuf.139666276581936, { i8*, i32 }** %.2, align 8
  ret i32 1
}

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #5

attributes #0 = { nofree norecurse nounwind }
attributes #1 = { norecurse nounwind readonly }
attributes #2 = { nofree noinline norecurse nounwind }
attributes #3 = { noinline }
attributes #4 = { nofree norecurse nounwind writeonly }
attributes #5 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
----------------------------------ASSEMBLY nrt----------------------------------
	.text
	.file	"<string>"
	.globl	nrt_atomic_add
	.p2align	4, 0x90
	.type	nrt_atomic_add,@function
nrt_atomic_add:
	movl	$1, %eax
	lock		xaddq	%rax, (%rdi)
	incq	%rax
	retq
.Lfunc_end0:
	.size	nrt_atomic_add, .Lfunc_end0-nrt_atomic_add

	.globl	nrt_atomic_sub
	.p2align	4, 0x90
	.type	nrt_atomic_sub,@function
nrt_atomic_sub:
	movq	$-1, %rax
	lock		xaddq	%rax, (%rdi)
	decq	%rax
	retq
.Lfunc_end1:
	.size	nrt_atomic_sub, .Lfunc_end1-nrt_atomic_sub

	.globl	nrt_atomic_cas
	.p2align	4, 0x90
	.type	nrt_atomic_cas,@function
nrt_atomic_cas:
	movq	%rsi, %rax
	xorl	%esi, %esi
	lock		cmpxchgq	%rdx, (%rdi)
	sete	%sil
	movq	%rax, (%rcx)
	movl	%esi, %eax
	retq
.Lfunc_end2:
	.size	nrt_atomic_cas, .Lfunc_end2-nrt_atomic_cas

	.globl	NRT_MemInfo_data_fast
	.p2align	4, 0x90
	.type	NRT_MemInfo_data_fast,@function
NRT_MemInfo_data_fast:
	movq	24(%rdi), %rax
	retq
.Lfunc_end3:
	.size	NRT_MemInfo_data_fast, .Lfunc_end3-NRT_MemInfo_data_fast

	.globl	NRT_incref
	.p2align	4, 0x90
	.type	NRT_incref,@function
NRT_incref:
	testq	%rdi, %rdi
	je	.LBB4_1
	lock		incq	(%rdi)
	retq
.LBB4_1:
	retq
.Lfunc_end4:
	.size	NRT_incref, .Lfunc_end4-NRT_incref

	.globl	NRT_decref
	.p2align	4, 0x90
	.type	NRT_decref,@function
NRT_decref:
	.cfi_startproc
	testq	%rdi, %rdi
	je	.LBB5_2
	#MEMBARRIER
	lock		decq	(%rdi)
	je	.LBB5_3
.LBB5_2:
	retq
.LBB5_3:
	#MEMBARRIER
	movabsq	$NRT_MemInfo_call_dtor, %rax
	jmpq	*%rax
.Lfunc_end5:
	.size	NRT_decref, .Lfunc_end5-NRT_decref
	.cfi_endproc

	.globl	nrt_unresolved_abort
	.p2align	4, 0x90
	.type	nrt_unresolved_abort,@function
nrt_unresolved_abort:
	movabsq	$.const.picklebuf.139666276581936, %rax
	movq	%rax, (%rsi)
	movl	$1, %eax
	retq
.Lfunc_end6:
	.size	nrt_unresolved_abort, .Lfunc_end6-nrt_unresolved_abort

	.type	.const.picklebuf.139666276581936,@object
	.section	.rodata,"a",@progbits
	.p2align	3
.const.picklebuf.139666276581936:
	.quad	.const.pickledata.139666276581936
	.long	102
	.zero	4
	.size	.const.picklebuf.139666276581936, 16

	.type	.const.pickledata.139666276581936,@object
	.p2align	4
.const.pickledata.139666276581936:
	.ascii	"\200\004\225[\000\000\000\000\000\000\000\214\bbuiltins\224\214\fRuntimeError\224\223\224\2146numba jitted function aborted due to unresolved symbol\224\205\224N\207\224."
	.size	.const.pickledata.139666276581936, 102


	.section	".note.GNU-stack","",@progbits

================================================================================
0.50.1
--------------------------IR DUMP: bend_rounded_Crane---------------------------
label 0:
    Di = arg(0, name=Di)                     ['Di']
    angle = arg(1, name=angle)               ['angle']
    rc = arg(2, name=rc)                     ['rc']
    bend_diameters = arg(3, name=bend_diameters) ['bend_diameters']
    $const4.1 = const(NoneType, None)        ['$const4.1']
    $6compare_op.2 = rc is not $const4.1     ['$6compare_op.2', '$const4.1', 'rc']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, test.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 50                    ['$8pred']
label 10:
    $const12.1 = const(NoneType, None)       ['$const12.1']
    $14compare_op.2 = bend_diameters is not $const12.1 ['$14compare_op.2', '$const12.1', 'bend_diameters']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, test.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 50                   ['$16pred']
label 18:
    $18load_global.0 = global(abs: <built-in function abs>) ['$18load_global.0']
    $24binary_multiply.3 = Di * bend_diameters ['$24binary_multiply.3', 'Di', 'bend_diameters']
    $28binary_true_divide.5 = $24binary_multiply.3 / rc ['$24binary_multiply.3', '$28binary_true_divide.5', 'rc']
    $const30.6 = const(float, 1.0)           ['$const30.6']
    $32binary_subtract.7 = $28binary_true_divide.5 - $const30.6 ['$28binary_true_divide.5', '$32binary_subtract.7', '$const30.6']
    $34call_function.8 = call $18load_global.0($32binary_subtract.7, func=$18load_global.0, args=[Var($32binary_subtract.7, test.py:6)], kws=(), vararg=None) ['$18load_global.0', '$32binary_subtract.7', '$34call_function.8']
    $const36.9 = const(float, 1e-12)         ['$const36.9']
    $38compare_op.10 = $34call_function.8 > $const36.9 ['$34call_function.8', '$38compare_op.10', '$const36.9']
    bool40 = global(bool: <class 'bool'>)    ['bool40']
    $40pred = call bool40($38compare_op.10, func=bool40, args=(Var($38compare_op.10, test.py:6),), kws=(), vararg=None) ['$38compare_op.10', '$40pred', 'bool40']
    branch $40pred, 42, 50                   ['$40pred']
label 42:
    $42load_global.0 = global(ValueError: <class 'ValueError'>) ['$42load_global.0']
    $const44.1 = const(str, Cannot specify both `rc` and `bend_diameters`) ['$const44.1']
    $46call_function.2 = call $42load_global.0($const44.1, func=$42load_global.0, args=[Var($const44.1, test.py:7)], kws=(), vararg=None) ['$42load_global.0', '$46call_function.2', '$const44.1']
    raise $46call_function.2                 ['$46call_function.2']
label 50:
    $const52.1 = const(NoneType, None)       ['$const52.1']
    $54compare_op.2 = rc is $const52.1       ['$54compare_op.2', '$const52.1', 'rc']
    bool56 = global(bool: <class 'bool'>)    ['bool56']
    $56pred = call bool56($54compare_op.2, func=bool56, args=(Var($54compare_op.2, test.py:8),), kws=(), vararg=None) ['$54compare_op.2', '$56pred', 'bool56']
    branch $56pred, 58, 78                   ['$56pred']
label 58:
    $const60.1 = const(NoneType, None)       ['$const60.1']
    $62compare_op.2 = bend_diameters is $const60.1 ['$62compare_op.2', '$const60.1', 'bend_diameters']
    bool64 = global(bool: <class 'bool'>)    ['bool64']
    $64pred = call bool64($62compare_op.2, func=bool64, args=(Var($62compare_op.2, test.py:9),), kws=(), vararg=None) ['$62compare_op.2', '$64pred', 'bool64']
    branch $64pred, 66, 70                   ['$64pred']
label 66:
    $const66.0 = const(float, 5.0)           ['$const66.0']
    bend_diameters = $const66.0              ['$const66.0', 'bend_diameters']
    jump 70                                  []
label 70:
    $74binary_multiply.2 = Di * bend_diameters ['$74binary_multiply.2', 'Di', 'bend_diameters']
    rc = $74binary_multiply.2                ['$74binary_multiply.2', 'rc']
    jump 78                                  []
label 78:
    $80return_value.1 = cast(value=Di)       ['$80return_value.1', 'Di']
    return $80return_value.1                 ['$80return_value.1']

______________________________________________________________________
REWRITING (RewriteConstRaises):
    $42load_global.0 = global(ValueError: <class 'ValueError'>) ['$42load_global.0']
    $const44.1 = const(str, Cannot specify both `rc` and `bend_diameters`) ['$const44.1']
    $46call_function.2 = call $42load_global.0($const44.1, func=$42load_global.0, args=[Var($const44.1, test.py:7)], kws=(), vararg=None) ['$42load_global.0', '$46call_function.2', '$const44.1']
    raise $46call_function.2                 ['$46call_function.2']
____________________________________________________________
    $42load_global.0 = global(ValueError: <class 'ValueError'>) ['$42load_global.0']
    $const44.1 = const(str, Cannot specify both `rc` and `bend_diameters`) ['$const44.1']
    $46call_function.2 = call $42load_global.0($const44.1, func=$42load_global.0, args=[Var($const44.1, test.py:7)], kws=(), vararg=None) ['$42load_global.0', '$46call_function.2', '$const44.1']
    <static> raise <class 'ValueError'>('Cannot specify both `rc` and `bend_diameters`') []
______________________________________________________________________
--------------------------IR DUMP: bend_rounded_Crane---------------------------
label 0:
    Di = arg(0, name=Di)                     ['Di']
    angle = arg(1, name=angle)               ['angle']
    rc = arg(2, name=rc)                     ['rc']
    bend_diameters = arg(3, name=bend_diameters) ['bend_diameters']
    $const4.1 = const(NoneType, None)        ['$const4.1']
    $6compare_op.2 = rc is not $const4.1     ['$6compare_op.2', '$const4.1', 'rc']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, test.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 50                    ['$8pred']
label 10:
    $const12.1 = const(NoneType, None)       ['$const12.1']
    $14compare_op.2 = bend_diameters is not $const12.1 ['$14compare_op.2', '$const12.1', 'bend_diameters']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, test.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 50                   ['$16pred']
label 18:
    $18load_global.0 = global(abs: <built-in function abs>) ['$18load_global.0']
    $24binary_multiply.3 = Di * bend_diameters ['$24binary_multiply.3', 'Di', 'bend_diameters']
    $28binary_true_divide.5 = $24binary_multiply.3 / rc ['$24binary_multiply.3', '$28binary_true_divide.5', 'rc']
    $const30.6 = const(float, 1.0)           ['$const30.6']
    $32binary_subtract.7 = $28binary_true_divide.5 - $const30.6 ['$28binary_true_divide.5', '$32binary_subtract.7', '$const30.6']
    $34call_function.8 = call $18load_global.0($32binary_subtract.7, func=$18load_global.0, args=[Var($32binary_subtract.7, test.py:6)], kws=(), vararg=None) ['$18load_global.0', '$32binary_subtract.7', '$34call_function.8']
    $const36.9 = const(float, 1e-12)         ['$const36.9']
    $38compare_op.10 = $34call_function.8 > $const36.9 ['$34call_function.8', '$38compare_op.10', '$const36.9']
    bool40 = global(bool: <class 'bool'>)    ['bool40']
    $40pred = call bool40($38compare_op.10, func=bool40, args=(Var($38compare_op.10, test.py:6),), kws=(), vararg=None) ['$38compare_op.10', '$40pred', 'bool40']
    branch $40pred, 42, 50                   ['$40pred']
label 42:
    $42load_global.0 = global(ValueError: <class 'ValueError'>) ['$42load_global.0']
    $const44.1 = const(str, Cannot specify both `rc` and `bend_diameters`) ['$const44.1']
    $46call_function.2 = call $42load_global.0($const44.1, func=$42load_global.0, args=[Var($const44.1, test.py:7)], kws=(), vararg=None) ['$42load_global.0', '$46call_function.2', '$const44.1']
    <static> raise <class 'ValueError'>('Cannot specify both `rc` and `bend_diameters`') []
label 50:
    $const52.1 = const(NoneType, None)       ['$const52.1']
    $54compare_op.2 = rc is $const52.1       ['$54compare_op.2', '$const52.1', 'rc']
    bool56 = global(bool: <class 'bool'>)    ['bool56']
    $56pred = call bool56($54compare_op.2, func=bool56, args=(Var($54compare_op.2, test.py:8),), kws=(), vararg=None) ['$54compare_op.2', '$56pred', 'bool56']
    branch $56pred, 58, 78                   ['$56pred']
label 58:
    $const60.1 = const(NoneType, None)       ['$const60.1']
    $62compare_op.2 = bend_diameters is $const60.1 ['$62compare_op.2', '$const60.1', 'bend_diameters']
    bool64 = global(bool: <class 'bool'>)    ['bool64']
    $64pred = call bool64($62compare_op.2, func=bool64, args=(Var($62compare_op.2, test.py:9),), kws=(), vararg=None) ['$62compare_op.2', '$64pred', 'bool64']
    branch $64pred, 66, 70                   ['$64pred']
label 66:
    $const66.0 = const(float, 5.0)           ['$const66.0']
    bend_diameters = $const66.0              ['$const66.0', 'bend_diameters']
    jump 70                                  []
label 70:
    $74binary_multiply.2 = Di * bend_diameters ['$74binary_multiply.2', 'Di', 'bend_diameters']
    rc = $74binary_multiply.2                ['$74binary_multiply.2', 'rc']
    jump 78                                  []
label 78:
    $80return_value.1 = cast(value=Di)       ['$80return_value.1', 'Di']
    return $80return_value.1                 ['$80return_value.1']

------------------------SSA IR DUMP: bend_rounded_Crane-------------------------
label 0:
    Di = arg(0, name=Di)                     ['Di']
    angle = arg(1, name=angle)               ['angle']
    rc = arg(2, name=rc)                     ['rc']
    bend_diameters = arg(3, name=bend_diameters) ['bend_diameters']
    $const4.1 = const(NoneType, None)        ['$const4.1']
    $6compare_op.2 = rc is not $const4.1     ['$6compare_op.2', '$const4.1', 'rc']
    bool8 = global(bool: <class 'bool'>)     ['bool8']
    $8pred = call bool8($6compare_op.2, func=bool8, args=(Var($6compare_op.2, test.py:5),), kws=(), vararg=None) ['$6compare_op.2', '$8pred', 'bool8']
    branch $8pred, 10, 50                    ['$8pred']
label 10:
    $const12.1 = const(NoneType, None)       ['$const12.1']
    $14compare_op.2 = bend_diameters is not $const12.1 ['$14compare_op.2', '$const12.1', 'bend_diameters']
    bool16 = global(bool: <class 'bool'>)    ['bool16']
    $16pred = call bool16($14compare_op.2, func=bool16, args=(Var($14compare_op.2, test.py:5),), kws=(), vararg=None) ['$14compare_op.2', '$16pred', 'bool16']
    branch $16pred, 18, 50                   ['$16pred']
label 18:
    $18load_global.0 = global(abs: <built-in function abs>) ['$18load_global.0']
    $24binary_multiply.3 = Di * bend_diameters ['$24binary_multiply.3', 'Di', 'bend_diameters']
    $28binary_true_divide.5 = $24binary_multiply.3 / rc ['$24binary_multiply.3', '$28binary_true_divide.5', 'rc']
    $const30.6 = const(float, 1.0)           ['$const30.6']
    $32binary_subtract.7 = $28binary_true_divide.5 - $const30.6 ['$28binary_true_divide.5', '$32binary_subtract.7', '$const30.6']
    $34call_function.8 = call $18load_global.0($32binary_subtract.7, func=$18load_global.0, args=[Var($32binary_subtract.7, test.py:6)], kws=(), vararg=None) ['$18load_global.0', '$32binary_subtract.7', '$34call_function.8']
    $const36.9 = const(float, 1e-12)         ['$const36.9']
    $38compare_op.10 = $34call_function.8 > $const36.9 ['$34call_function.8', '$38compare_op.10', '$const36.9']
    bool40 = global(bool: <class 'bool'>)    ['bool40']
    $40pred = call bool40($38compare_op.10, func=bool40, args=(Var($38compare_op.10, test.py:6),), kws=(), vararg=None) ['$38compare_op.10', '$40pred', 'bool40']
    branch $40pred, 42, 50                   ['$40pred']
label 42:
    $42load_global.0 = global(ValueError: <class 'ValueError'>) ['$42load_global.0']
    $const44.1 = const(str, Cannot specify both `rc` and `bend_diameters`) ['$const44.1']
    $46call_function.2 = call $42load_global.0($const44.1, func=$42load_global.0, args=[Var($const44.1, test.py:7)], kws=(), vararg=None) ['$42load_global.0', '$46call_function.2', '$const44.1']
    <static> raise <class 'ValueError'>('Cannot specify both `rc` and `bend_diameters`') []
label 50:
    $const52.1 = const(NoneType, None)       ['$const52.1']
    $54compare_op.2 = rc is $const52.1       ['$54compare_op.2', '$const52.1', 'rc']
    bool56 = global(bool: <class 'bool'>)    ['bool56']
    $56pred = call bool56($54compare_op.2, func=bool56, args=(Var($54compare_op.2, test.py:8),), kws=(), vararg=None) ['$54compare_op.2', '$56pred', 'bool56']
    branch $56pred, 58, 78                   ['$56pred']
label 58:
    $const60.1 = const(NoneType, None)       ['$const60.1']
    $62compare_op.2 = bend_diameters is $const60.1 ['$62compare_op.2', '$const60.1', 'bend_diameters']
    bool64 = global(bool: <class 'bool'>)    ['bool64']
    $64pred = call bool64($62compare_op.2, func=bool64, args=(Var($62compare_op.2, test.py:9),), kws=(), vararg=None) ['$62compare_op.2', '$64pred', 'bool64']
    branch $64pred, 66, 70                   ['$64pred']
label 66:
    $const66.0 = const(float, 5.0)           ['$const66.0']
    bend_diameters.1 = $const66.0            ['$const66.0', 'bend_diameters.1']
    jump 70                                  []
label 70:
    bend_diameters.2 = phi(incoming_values=[Var(bend_diameters, test.py:5), Var(bend_diameters.1, test.py:10)], incoming_blocks=[58, 66]) ['bend_diameters', 'bend_diameters.1', 'bend_diameters.2']
    $74binary_multiply.2 = Di * bend_diameters.2 ['$74binary_multiply.2', 'Di', 'bend_diameters.2']
    rc.1 = $74binary_multiply.2              ['$74binary_multiply.2', 'rc.1']
    jump 78                                  []
label 78:
    $80return_value.1 = cast(value=Di)       ['$80return_value.1', 'Di']
    return $80return_value.1                 ['$80return_value.1']

-----------------------------------propagate------------------------------------
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $18load_global.0 := Function(<built-in function abs>),
 $24binary_multiply.3 := <undecided>,
 $28binary_true_divide.5 := <undecided>,
 $32binary_subtract.7 := <undecided>,
 $34call_function.8 := <undecided>,
 $38compare_op.10 := <undecided>,
 $42load_global.0 := ValueError,
 $46call_function.2 := ValueError(...),
 $54compare_op.2 := bool,
 $56pred := bool,
 $62compare_op.2 := bool,
 $64pred := bool,
 $6compare_op.2 := bool,
 $74binary_multiply.2 := float64,
 $80return_value.1 := float64,
 $8pred := bool,
 $const12.1 := none,
 $const30.6 := float64,
 $const36.9 := float64,
 $const4.1 := none,
 $const44.1 := Literal[str](Cannot specify both `rc` and `bend_diameters`),
 $const52.1 := none,
 $const60.1 := none,
 $const66.0 := float64,
 Di := float64,
 angle := float64,
 arg.Di := float64,
 arg.angle := float64,
 arg.bend_diameters := omitted(default=None),
 arg.rc := omitted(default=None),
 bend_diameters := none,
 bend_diameters.1 := float64,
 bend_diameters.2 := OptionalType(float64) i.e. the type 'float64 or None',
 bool16 := Function(<class 'bool'>),
 bool40 := Function(<class 'bool'>),
 bool56 := Function(<class 'bool'>),
 bool64 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 rc := none,
 rc.1 := float64]
-----------------------------------propagate------------------------------------
---- type variables ----
[$14compare_op.2 := bool,
 $16pred := bool,
 $18load_global.0 := Function(<built-in function abs>),
 $24binary_multiply.3 := <undecided>,
 $28binary_true_divide.5 := <undecided>,
 $32binary_subtract.7 := <undecided>,
 $34call_function.8 := <undecided>,
 $38compare_op.10 := <undecided>,
 $42load_global.0 := ValueError,
 $46call_function.2 := ValueError(...),
 $54compare_op.2 := bool,
 $56pred := bool,
 $62compare_op.2 := bool,
 $64pred := bool,
 $6compare_op.2 := bool,
 $74binary_multiply.2 := float64,
 $80return_value.1 := float64,
 $8pred := bool,
 $const12.1 := none,
 $const30.6 := float64,
 $const36.9 := float64,
 $const4.1 := none,
 $const44.1 := Literal[str](Cannot specify both `rc` and `bend_diameters`),
 $const52.1 := none,
 $const60.1 := none,
 $const66.0 := float64,
 Di := float64,
 angle := float64,
 arg.Di := float64,
 arg.angle := float64,
 arg.bend_diameters := omitted(default=None),
 arg.rc := omitted(default=None),
 bend_diameters := none,
 bend_diameters.1 := float64,
 bend_diameters.2 := OptionalType(float64) i.e. the type 'float64 or None',
 bool16 := Function(<class 'bool'>),
 bool40 := Function(<class 'bool'>),
 bool56 := Function(<class 'bool'>),
 bool64 := Function(<class 'bool'>),
 bool8 := Function(<class 'bool'>),
 rc := none,
 rc.1 := float64]
Traceback (most recent call last):
  File "test.py", line 14, in <module>
    bend_rounded_Crane(40.0, 15.0)
  File "/home/caleb/.local/lib/python3.7/site-packages/numba/core/dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/caleb/.local/lib/python3.7/site-packages/numba/core/dispatcher.py", line 358, in error_rewrite
    reraise(type(e), e, None)
  File "/home/caleb/.local/lib/python3.7/site-packages/numba/core/utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function mul>) found for signature:
 
 >>> mul(float64, none)
 
There are 12 candidate implementations:
  - Of which 10 did not match due to:
  Overload of function 'mul': File: <numerous>: Line N/A.
    With argument(s): '(float64, none)':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'mul': File: unknown: Line unknown.
    With argument(s): '(float64, none)':
   No match for registered cases:
    * (int64, int64) -> int64
    * (int64, uint64) -> int64
    * (uint64, int64) -> int64
    * (uint64, uint64) -> uint64
    * (float32, float32) -> float32
    * (float64, float64) -> float64
    * (complex64, complex64) -> complex64
    * (complex128, complex128) -> complex128

During: typing of intrinsic-call at test.py (6)

File "test.py", line 6:
def bend_rounded_Crane(Di, angle, rc=None, bend_diameters=None):
    <source elided>
    if (rc is not None and bend_diameters is not None):
        if abs(Di*bend_diameters/rc - 1.0) > 1e-12:
        ^

 
</details>


user: CalebBell
issue_5997: state: open
title: Self-referential types cannot be unpickled
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
This numba type has a self reference:
```python
import numba
class Nasty(numba.types.Dummy):
    def __init__(self):
        super().__init__("Oops")
        self.loop = self  # in reality there is a cache that eventually forms a loop
```
This causes a bizarre error when unpickling:
```python
>>> p = pickle.dumps(Nasty())
>>> pickle.loads(p)
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-19-0ff50e04be57> in <module>
----> 1 pickle.loads(p)

c:\users\wiese\repos\ga\numba\numba\core\types\abstract.py in _type_reconstructor(reconstructor, reconstructor_args, state)
     74 if state:
     75     obj.__dict__.update(state)
---> 76 return type(obj)._intern(obj)

c:\users\wiese\repos\ga\numba\numba\core\types\abstract.py in _TypeMetaclass._intern(cls, inst)
     47 def _intern(cls, inst):
     48     # Try to intern the created instance
     49     wr = weakref.ref(inst, _on_type_disposal)
---> 50     orig = _typecache.get(wr)
     51     orig = orig and orig()
     52     if orig is not None:

c:\users\wiese\repos\ga\numba\numba\core\types\abstract.py in Type.__hash__(self)
    117 def __hash__(self):
--> 118     return hash(self.key)

c:\users\wiese\repos\ga\numba\numba\core\types\abstract.py in Type.key(self)
     95 @property
     96 def key(self):
     97     """
     98     A property used for __eq__, __ne__ and __hash__.  Can be overridden
     99     in subclasses.
    100     """
--> 101     return self.name

AttributeError: 'Nasty' object has no attribute 'name'
```

user: eric-wieser
labels: discussion: An issue requiring discussion
issue_5994: state: open
title: Literal sets missing implementations
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

It seems using literal sets in jit decorated functions causes errors.

```
@numba.njit
def get_union():
    return {4} | {1}

get_union()
```
Yields
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function or_>) found for signature:
 
 >>> or_(set(Literal[int](4)), set(Literal[int](1)))
 
There are 6 candidate implementations:
  - Of which 4 did not match due to:
  Overload of function 'or_': File: <numerous>: Line N/A.
    With argument(s): '(set(Literal[int](4)), set(Literal[int](1)))':
   No match.
  - Of which 2 did not match due to:
  Operator Overload in function 'or_': File: unknown: Line unknown.
    With argument(s): '(set(Literal[int](4)), set(Literal[int](1)))':
   No match for registered cases:
    * (bool, bool) -> bool
    * (int64, int64) -> int64
    * (int64, uint64) -> int64
    * (uint64, int64) -> int64
    * (uint64, uint64) -> uint64

During: typing of intrinsic-call at <ipython-input-5-3354ebb3e034> (3)

File "<ipython-input-5-3354ebb3e034>", line 3:
def get_union():
    return {4} | {1}
    ^
```

I tried to find where the candidate implementations are evaluated for this example (in `numba/core/base.py`) without luck.  There's a [`@lower_builtin` here](https://github.com/numba/numba/blob/master/numba/cpython/setobj.py#L1376-L1389) that I would have thought handles this.  One thought I had is that it looks like we're typing these as a set of a literal int, instead of a literal set (i.e. the `dtype`s of the two arguments are `Literal[int](4)` and `Literal[int](1)`, which don't match).

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: EPronovost
issue_5990: state: open
title: differentiate between cpython and numpy scalars
body: Unless I'm missing something, numba seems to be ignoring the signature that I'm trying to enforce.

Compare:
```python
def test():
    Z = np.zeros(2, dtype=np.float32)
    return Z[0]

print(numba.typeof(test()))
>>> float32
```

with
```python
@numba.jit(numba.float32(), nopython=True)
def test():
    Z = np.zeros(2, dtype=np.float32)
    return Z[0]

print(numba.typeof(test()))
>>> float64
```

What am I missing?
user: ziofil
issue_5989: state: open
title: Update tests use of Popen
body: > Perhaps those `Popen`'s ought to have a guard thread watching them to sigkill if they get stuck.

_Originally posted by @stuartarchibald in https://github.com/numba/numba/pull/5674#issuecomment-658761441_

All tests using `Popen` should have a watcher to terminate the subprocess in case the subprocess gets stuck. Something like https://github.com/numba/numba/blob/e043ee705d65abd3a066500be4d62b54bdf3586c/numba/cuda/tests/cudadrv/test_detect.py#L31
user: sklam
labels: good second issue: A good issue for second time contributors
issue_5988: state: open
title: Add utilities to the namemangler to produce things like "the Numba jit/cpython wrapper prefix"
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

See this comment https://github.com/numba/numba/pull/5674#discussion_r450319771
user: stuartarchibald
issue_5983: state: open
title: After computing delayed dask from numba, opening subprocess hangs on repeated `sched_yield`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Summary of bug

Under a particularly specific set of circumstances, computing a `dask` array from a `dask.delayed` call based on a `numba` function leads any subsequent calls to `subprocess.Popen` to hang with 100% CPU on Linux kernel 4.12.14.  The `strace` command reveals a thread calling `sched_yield` repeatedly, apparently stuck in an infinite loop.  I'm not sure if this problem is due to numba or dask or llvm or somewhere else, I'm reporting it here because it appears since upgrading numba from 0.48 to 0.50 (it does not appear with 0.48).  If this is the wrong place, please excuse me and kindly point me to the right place :)

## MCVE

The main file:

```python
import numpy
import dask
import dask.array
import mwe_weird
import numba
dask.config.set(scheduler="threads")
nx = ny = 500
@numba.jit(nopython=True, parallel=True, cache=True)
def calc():
    return numpy.zeros((nx, ny), dtype=numpy.float32)
delayed_func = dask.delayed(calc, pure=True)
delayed_res = delayed_func()
oops = dask.array.from_delayed(
        delayed_res,
        shape=(nx, ny),
        dtype=numpy.float32)

oops.compute()
import subprocess
subprocess.Popen(["cat /dev/null"], shell=True)
```

The secondary file `mwe_weird.py`:

```python
import numpy
import numba

@numba.jit(
        ['UniTuple(float32[:, :], 3)(float32[:, :], float32[:, :])',
         'UniTuple(float32[:, :], 3)(float64[:, :], float64[:, :])'],
        nopython=True, parallel=True, cache=True)
def calc_gradient_vector(BT_t0, BT_t1):
    (nx, ny) = BT_t0.shape
    vbtfx = numpy.zeros((nx, ny), dtype=numba.float32)
    vbtfy = numpy.zeros((nx, ny), dtype=numba.float32)
    vbtfz = numpy.zeros((nx, ny), dtype=numba.float32)

    return (vbtfx, vbtfy, vbtfz)
```

## Clues (perhaps)

Calling the main file causes Python to hang on the `subprocess.Popen` call.

The problem disappears if:

* The unused `import mwe_weird` is removed, or
* The type hints inside `mwe_weird` are removed, or
* `oops.compute()` is removed, or
* the `numba.jit` decorator is removed, or
* the dask scheduler single-threaded or processes is used, or
* calc is replaced by a direct `dask.array.zeros(...)` call, or
* numba is downgraded from 0.50 to 0.48 and llvmlite from 0.33 to 0.31, or
* probably other circumstances I have not seen.

The problem appears during the `Popen` call.  Calling the script with `strace -o ... -ff python mwe.py` reveals one file with many repetitions of the system call `sched_yield` until killed (at which point it had ten million such lines):

```
$ tail /tmp/strace.7559 
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
--- SIGQUIT {si_signo=SIGQUIT, si_code=SI_KERNEL} ---
+++ killed by SIGQUIT (core dumped) +++
```

During this time, the process uses 100% CPU.

I don't know how to get a Python traceback for more specific pointing; even when running `python -X faulthandler` there is no traceback after killing (which I should probably expect to be absent with such a hard kill).  Regular interrupt (ctrl+C) has no effect.  Running `python -m trace --trace ...`, the final lines when it's hanging are:

```
subprocess.py(1635):                     fds_to_keep = set(pass_fds)
subprocess.py(1636):                     fds_to_keep.add(errpipe_write)
subprocess.py(1637):                     self.pid = _posixsubprocess.fork_exec(
```

## Versions

Dask 0.20.0, numba 0.50,1, numpy 1.18.5, llvmlite 0.33.0, Python 3.8.3.  Tested on three different Linux systems, including one openSUSE 15.0 with Linux kernel 4.12.14-lp150.12.82-default and one Ubuntu 20.04 with Linux kernel 5.40.0-40-generic.

## Further context

The problem appears to occur during a very specific set of circumstances and it took quite some time to come up with the minimal working example.  I hope what I came up with is minimal enough.  I don't know enough about the internals of either numba or dask to more specifically reproduce the circumstances.  Please let me know in case you need any further information.

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: gerritholl
labels: threading: Issue involving the threading layers
issue_5977: state: open
title: Equality tests on floats: add support for math.isclose() and numpy.isclose()
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case.

-->

When testing the equality of two floating point numbers, it’s good practices to rely on approximations (e.g., `abs(a - b) < epsilon`) rather than on exact/bit-to-bit comparison.

In Python we can use [`math.isclose`](https://docs.python.org/3/library/math.html#math.isclose) or [`numpy.isclose`](https://numpy.org/doc/stable/reference/generated/numpy.isclose.html) to do such tests. These functions are a bit different but both can be equally useful. Unlike the built-in `math.isclose`, `numpy.isclose` is not symmetric in `a` and `b` – it assumes `b` is the reference value – so that `isclose(a, b)` might be different from `isclose(b, a)`.

* Floating point comparison is a common enough operation so that Numba can support it (for both `math` and `numpy` libraries).
* Moreover, all arguments of each function should be supported (relative tolerance, absolute tolerance, and `equal_nan` if existing) because each use case can have specific parameters.

----
*I could not find an issue about that when searching issues with keywords "isclose", "float comparison", "float equality".*
user: alexandrehuat
labels: good first issue: A good issue for a first time contributor
issue_5976: state: open
title: Memory leak on trivial compilation
body: Linux x64
python                    3.8.3           cpython_he5300dc_0    conda-forge
numba                     0.50.1           py38hcb8c335_0    conda-forge
llvmlite                  0.33.0           py38h4f45e52_0    conda-forge

I have a long-running service which dynamically creates Python functions, decorates them with numba, runs them, and discards them soon thereafter. I'm observing substantial memory leaks.

The POC that lets you reproduce the issue is trivial:
```python
import gc
import numba

while True:
    @numba.jit(["f8(f8)"])
    def f(x):
        return x * 2

    del f
    gc.collect()
```
With this, I see the RSS of my python process growing by roughly **32 kiB per cycle**. If I make the wrapped code more complex, the amount of memory leak per cycle goes up.
In my use case, this very quickly adds up to gigabytes.

user: crusaderky
issue_5967: state: open
title: Typed list: Unable to add empty fortran array
body: The following snippet:
```python

from numba.typed import List
import numpy as np


l = List()
l.append(np.array([[1,2,3], [4,5,6]], order="F"))
l.append(np.array([], dtype=int, order="F").reshape(2,0))

```
Results in:
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
- Resolution failure for literal arguments:
No implementation of function Function(<function impl_append at 0x7fd5a5fd00d0>) found for signature:

 >>> impl_append(ListType[array(int64, 2d, F)], array(int64, 2d, C))

There are 2 candidate implementations:
  - Of which 2 did not match due to:
  Overload in function 'impl_append': File: numba/typed/listobject.py: Line 589.
    With argument(s): '(ListType[array(int64, 2d, F)], array(int64, 2d, C))':
   Rejected as the implementation raised a specific error:
     LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)


   File "../../../venv/lib/python3.8/site-packages/numba/typed/listobject.py", line 597:
       def impl(l, item):
           casteditem = _cast(item, itemty)
```
It works fine with `order="C"`. The issue seems to be that empty arrays are interpreted a C arrays no matter what.
Numba version: 0.50.1
user: ghost
issue_5965: state: open
title: custom logging level for numba internals.
body: Numba could do with a custom logging level to use internally so that developers of numba can switch on logging but it doesn't impact consumers of numba with e.g. `logging.DEBUG` enabled.
user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_5964: state: open
title: Type inference problem with literal unroll
body: I am getting a strange typing error when using `literal_unroll`:

```python
from numba import njit, literal_unroll
import numpy as np


points = np.arange(20)
mapper = (1,2)
vect = np.zeros(20)

@njit
def foo(points, out, mapper):

    t_start = points[0]
    assert t_start == 0
    t_end = points[-1]

    for idx in literal_unroll(mapper):
        aux = np.zeros(t_end - t_start + 1, np.float64)
    return out

foo(points, vect, mapper)
```
yields (on v.0.50)

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Type of variable 'aux.69' cannot be determined, operation: $60call_method.11.68, location: <ipython-input-9-ac1b4e60e276> (17)

File "<ipython-input-9-ac1b4e60e276>", line 17:
def foo(points, out, mapper):
    <source elided>
    for idx in literal_unroll(mapper):
        aux = np.zeros(t_end - t_start + 1, np.float64)
```

What is very strange is that the problem disappears if the `assert` line is removed.
I tracked the type inference with `NUMBA_DEBUG_TYPEINFER` and found that initially the variable is correctly typed, but at a later point it is marked as `<undecided>`. It might be related to SSA, because `aux` is correctly typed but `aux.69` is not.

user: luk-f-a
issue_5955: state: open
title: LoweringError: LLVM IR Parsing Error during scanpy sc.pp.calculate_qc_metrics
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [Y] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [Y] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Apologies in advance if there was a better way to do this that I didn't figure out - essentially cross-posting an issue I had with Scanpy (https://github.com/theislab/scanpy/issues/1147) that seems to be coming from an underlying conflict with Numba, resulting in a runtime error. Details from that copied below, thanks to @ivirshup for pointing me in this direction.

Running through a tutorial using the 10xGenomics 3K PBMC dataset in Jupyter Notebook on Windows 10, caught an error at sc.pp.calculate_qc_metrics. Based on a quick look with my untrained eyes, this may not be a scanpy issue per se so much as an underlying data structure conflict issue in numba and/or llvmlite?

Trimmed down code I used to reach that point (the skipped steps, in ellipses, don't seem to be necessary, but I may still have a few extras there):

<!-- Put a minimal reproducible example that reproduces the bug in the code block below: -->
```python
import scanpy as sc
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt

...

adata = sc.read_10x_mtx("/PBMC_10X/")

...

adata_10x = sc.read_10x_mtx("/PBMC_10X/")

...

sc.pp.calculate_qc_metrics(adata_10x, inplace = True)
```

That spat out:

<!-- Put your Error output in this code block (if applicable, else delete the block): -->
```pytb
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~\anaconda3\lib\site-packages\numba\errors.py in new_error_context(fmt_, *args, **kwargs)
    716     try:
--> 717         yield
    718     except NumbaError as e:

~\anaconda3\lib\site-packages\numba\lowering.py in lower_block(self, block)
    287                                    loc=self.loc, errcls_=defaulterrcls):
--> 288                 self.lower_inst(inst)
    289         self.post_block(block)

~\anaconda3\lib\site-packages\numba\lowering.py in lower_inst(self, inst)
    475                 if isinstance(inst, _class):
--> 476                     func(self, inst)
    477                     return

~\anaconda3\lib\site-packages\numba\npyufunc\parfor.py in _lower_parfor_parallel(lowerer, parfor)
    240         lowerer, parfor, typemap, typingctx, targetctx, flags, {},
--> 241         bool(alias_map), index_var_typ, parfor.races)
    242     numba.parfor.sequential_parfor_lowering = False

~\anaconda3\lib\site-packages\numba\npyufunc\parfor.py in _create_gufunc_for_parfor_body(lowerer, parfor, typemap, typingctx, targetctx, flags, locals, has_aliases, index_var_typ, races)
   1168         flags,
-> 1169         locals)
   1170 

~\anaconda3\lib\site-packages\numba\compiler.py in compile_ir(typingctx, targetctx, func_ir, args, return_type, flags, locals, lifted, lifted_from, is_lifted_loop, library, pipeline_class)
    614         return pipeline.compile_ir(func_ir=func_ir, lifted=lifted,
--> 615                                    lifted_from=lifted_from)
    616 

~\anaconda3\lib\site-packages\numba\compiler.py in compile_ir(self, func_ir, lifted, lifted_from)
    340         FixupArgs().run_pass(self.state)
--> 341         return self._compile_ir()
    342 

~\anaconda3\lib\site-packages\numba\compiler.py in _compile_ir(self)
    399         assert self.state.func_ir is not None
--> 400         return self._compile_core()
    401 

~\anaconda3\lib\site-packages\numba\compiler.py in _compile_core(self)
    372                 if is_final_pipeline:
--> 373                     raise e
    374         else:

~\anaconda3\lib\site-packages\numba\compiler.py in _compile_core(self)
    363             try:
--> 364                 pm.run(self.state)
    365                 if self.state.cr is not None:

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    346                 patched_exception = self._patch_error(msg, e)
--> 347                 raise patched_exception
    348 

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    337                 if isinstance(pass_inst, CompilerPass):
--> 338                     self._runPass(idx, pass_inst, state)
    339                 else:

~\anaconda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in _runPass(self, index, pss, internal_state)
    301         with SimpleTimer() as pass_time:
--> 302             mutated |= check(pss.run_pass, internal_state)
    303         with SimpleTimer() as finalize_time:

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in check(func, compiler_state)
    274         def check(func, compiler_state):
--> 275             mangled = func(compiler_state)
    276             if mangled not in (True, False):

~\anaconda3\lib\site-packages\numba\typed_passes.py in run_pass(self, state)
    406         # TODO: Pull this out into the pipeline
--> 407         NativeLowering().run_pass(state)
    408         lowered = state['cr']

~\anaconda3\lib\site-packages\numba\typed_passes.py in run_pass(self, state)
    348                                        metadata=metadata)
--> 349                 lower.lower()
    350                 if not flags.no_cpython_wrapper:

~\anaconda3\lib\site-packages\numba\lowering.py in lower(self)
    231         # Materialize LLVM Module
--> 232         self.library.add_ir_module(self.module)
    233 

~\anaconda3\lib\site-packages\numba\targets\codegen.py in add_ir_module(self, ir_module)
    200         ir = cgutils.normalize_ir_text(str(ir_module))
--> 201         ll_module = ll.parse_assembly(ir)
    202         ll_module.name = ir_module.name

~\anaconda3\lib\site-packages\llvmlite\binding\module.py in parse_assembly(llvmir, context)
     25             mod.close()
---> 26             raise RuntimeError("LLVM IR parsing error\n{0}".format(errmsg))
     27     return mod

RuntimeError: Failed in nopython mode pipeline (step: nopython mode backend)
LLVM IR parsing error
<string>:4053:36: error: '%.2725' defined with type 'i64' but expected 'i32'
  %".2726" = icmp eq i32 %".2724", %".2725"
                                   ^


During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-21-b19e785cf655> in <module>
----> 1 sc.pp.calculate_qc_metrics(adata_10x, inplace = True)

~\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py in calculate_qc_metrics(adata, expr_type, var_type, qc_vars, percent_top, layer, use_raw, inplace, parallel)
    281         percent_top=percent_top,
    282         inplace=inplace,
--> 283         X=X,
    284     )
    285     var_metrics = describe_var(

~\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py in describe_obs(adata, expr_type, var_type, qc_vars, percent_top, layer, use_raw, inplace, X, parallel)
    107     if percent_top:
    108         percent_top = sorted(percent_top)
--> 109         proportions = top_segment_proportions(X, percent_top)
    110         for i, n in enumerate(percent_top):
    111             obs_metrics[f"pct_{expr_type}_in_top_{n}_{var_type}"] = (

~\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py in top_segment_proportions(mtx, ns)
    364             mtx = csr_matrix(mtx)
    365         return top_segment_proportions_sparse_csr(
--> 366             mtx.data, mtx.indptr, np.array(ns, dtype=np.int)
    367         )
    368     else:

~\anaconda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    418                     e.patch_message('\n'.join((str(e).rstrip(), help_msg)))
    419             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 420             raise e
    421 
    422     def inspect_llvm(self, signature=None):

~\anaconda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    351                 argtypes.append(self.typeof_pyval(a))
    352         try:
--> 353             return self.compile(tuple(argtypes))
    354         except errors.ForceLiteralArg as e:
    355             # Received request for compiler re-entry with the list of arguments

~\anaconda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~\anaconda3\lib\site-packages\numba\dispatcher.py in compile(self, sig)
    766             self._cache_misses[sig] += 1
    767             try:
--> 768                 cres = self._compiler.compile(args, return_type)
    769             except errors.ForceLiteralArg as e:
    770                 def folded(args, kws):

~\anaconda3\lib\site-packages\numba\dispatcher.py in compile(self, args, return_type)
     75 
     76     def compile(self, args, return_type):
---> 77         status, retval = self._compile_cached(args, return_type)
     78         if status:
     79             return retval

~\anaconda3\lib\site-packages\numba\dispatcher.py in _compile_cached(self, args, return_type)
     89 
     90         try:
---> 91             retval = self._compile_core(args, return_type)
     92         except errors.TypingError as e:
     93             self._failed_cache[key] = e

~\anaconda3\lib\site-packages\numba\dispatcher.py in _compile_core(self, args, return_type)
    107                                       args=args, return_type=return_type,
    108                                       flags=flags, locals=self.locals,
--> 109                                       pipeline_class=self.pipeline_class)
    110         # Check typing error if object mode is used
    111         if cres.typing_error is not None and not flags.enable_pyobject:

~\anaconda3\lib\site-packages\numba\compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    549     pipeline = pipeline_class(typingctx, targetctx, library,
    550                               args, return_type, flags, locals)
--> 551     return pipeline.compile_extra(func)
    552 
    553 

~\anaconda3\lib\site-packages\numba\compiler.py in compile_extra(self, func)
    329         self.state.lifted = ()
    330         self.state.lifted_from = None
--> 331         return self._compile_bytecode()
    332 
    333     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~\anaconda3\lib\site-packages\numba\compiler.py in _compile_bytecode(self)
    391         """
    392         assert self.state.func_ir is None
--> 393         return self._compile_core()
    394 
    395     def _compile_ir(self):

~\anaconda3\lib\site-packages\numba\compiler.py in _compile_core(self)
    371                 self.state.status.fail_reason = e
    372                 if is_final_pipeline:
--> 373                     raise e
    374         else:
    375             raise CompilerError("All available pipelines exhausted")

~\anaconda3\lib\site-packages\numba\compiler.py in _compile_core(self)
    362             res = None
    363             try:
--> 364                 pm.run(self.state)
    365                 if self.state.cr is not None:
    366                     break

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    345                     (self.pipeline_name, pass_desc)
    346                 patched_exception = self._patch_error(msg, e)
--> 347                 raise patched_exception
    348 
    349     def dependency_analysis(self):

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    336                 pass_inst = _pass_registry.get(pss).pass_inst
    337                 if isinstance(pass_inst, CompilerPass):
--> 338                     self._runPass(idx, pass_inst, state)
    339                 else:
    340                     raise BaseException("Legacy pass in use")

~\anaconda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in _runPass(self, index, pss, internal_state)
    300             mutated |= check(pss.run_initialization, internal_state)
    301         with SimpleTimer() as pass_time:
--> 302             mutated |= check(pss.run_pass, internal_state)
    303         with SimpleTimer() as finalize_time:
    304             mutated |= check(pss.run_finalizer, internal_state)

~\anaconda3\lib\site-packages\numba\compiler_machinery.py in check(func, compiler_state)
    273 
    274         def check(func, compiler_state):
--> 275             mangled = func(compiler_state)
    276             if mangled not in (True, False):
    277                 msg = ("CompilerPass implementations should return True/False. "

~\anaconda3\lib\site-packages\numba\typed_passes.py in run_pass(self, state)
    405 
    406         # TODO: Pull this out into the pipeline
--> 407         NativeLowering().run_pass(state)
    408         lowered = state['cr']
    409         signature = typing.signature(state.return_type, *state.args)

~\anaconda3\lib\site-packages\numba\typed_passes.py in run_pass(self, state)
    347                 lower = lowering.Lower(targetctx, library, fndesc, interp,
    348                                        metadata=metadata)
--> 349                 lower.lower()
    350                 if not flags.no_cpython_wrapper:
    351                     lower.create_cpython_wrapper(flags.release_gil)

~\anaconda3\lib\site-packages\numba\lowering.py in lower(self)
    193         if self.generator_info is None:
    194             self.genlower = None
--> 195             self.lower_normal_function(self.fndesc)
    196         else:
    197             self.genlower = self.GeneratorLower(self)

~\anaconda3\lib\site-packages\numba\lowering.py in lower_normal_function(self, fndesc)
    246         # Init argument values
    247         self.extract_function_arguments()
--> 248         entry_block_tail = self.lower_function_body()
    249 
    250         # Close tail of entry block

~\anaconda3\lib\site-packages\numba\lowering.py in lower_function_body(self)
    271             bb = self.blkmap[offset]
    272             self.builder.position_at_end(bb)
--> 273             self.lower_block(block)
    274 
    275         self.post_lower()

~\anaconda3\lib\site-packages\numba\lowering.py in lower_block(self, block)
    286             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    287                                    loc=self.loc, errcls_=defaulterrcls):
--> 288                 self.lower_inst(inst)
    289         self.post_block(block)
    290 

~\anaconda3\lib\contextlib.py in __exit__(self, type, value, traceback)
    128                 value = type()
    129             try:
--> 130                 self.gen.throw(type, value, traceback)
    131             except StopIteration as exc:
    132                 # Suppress StopIteration *unless* it's the same exception that

~\anaconda3\lib\site-packages\numba\errors.py in new_error_context(fmt_, *args, **kwargs)
    723         from numba import config
    724         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 725         six.reraise(type(newerr), newerr, tb)
    726 
    727 

~\anaconda3\lib\site-packages\numba\six.py in reraise(tp, value, tb)
    667         if value.__traceback__ is not tb:
    668             raise value.with_traceback(tb)
--> 669         raise value
    670 
    671 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Failed in nopython mode pipeline (step: nopython mode backend)
LLVM IR parsing error
<string>:4053:36: error: '%.2725' defined with type 'i64' but expected 'i32'
  %".2726" = icmp eq i32 %".2724", %".2725"
                                   ^


File "..\..\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py", line 399:
def top_segment_proportions_sparse_csr(data, indptr, ns):
    <source elided>
    partitioned = np.zeros((indptr.size - 1, maxidx), dtype=data.dtype)
    for i in numba.prange(indptr.size - 1):
    ^

[1] During: lowering "id=13[LoopNest(index_variable = parfor_index.260, range = (0, $122binary_subtract.5, 1))]{130: <ir.Block at C:\Users\lyciansarpedon\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py (399)>, 400: <ir.Block at C:\Users\lyciansarpedon\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py (405)>, 402: <ir.Block at C:\Users\lyciansarpedon\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py (406)>, 276: <ir.Block at C:\Users\lyciansarpedon\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py (403)>, 318: <ir.Block at C:\Users\lyciansarpedon\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py (404)>}Var(parfor_index.260, _qc.py:399)" at C:\Users\lyciansarpedon\anaconda3\lib\site-packages\scanpy\preprocessing\_qc.py (399)
```

Unlikely to be related, but this was after I had issues installing scanpy from conda (as in #1142), which I got around by installing through pip.

#### Versions:
<!-- Output of scanpy.logging.print_versions() -->

>Initial run:
 scanpy==1.4.6 anndata==0.7.1 umap==0.3.10 numba==0.48.0 numpy==1.18.1 scipy==1.4.1 pandas==1.0.1 scikit-learn==0.22.1 statsmodels==0.11.0
Most recent run with the same error:
scanpy==1.5.1 anndata==0.7.1 umap==0.3.10 numba==0.50.1 numpy==1.18.5 scipy==1.5.0 pandas==1.0.5 scikit-learn==0.23.1 statsmodels==0.11.1
(I also get a "NumbaWarning: The TBB threading layer requires TBB version 2019.5 or later i.e., TBB_INTERFACE_VERSION >= 11005. Found TBB_INTERFACE_VERSION = 11000. The TBB threading layer is disabled." with the updated packages. pip shows a 2020.0.133 version, but installing it claims that the only version available is 2019.0.)
user: lyciansarpedon
issue_5953: state: open
title: Extreme compilation times with long tuples
body: Hi, I'm getting very long compilation times when long tuples are involved. I know this is expected to a certain extent, due to the way tuples are lowered. But I see much larger compilation times when numpy arrays are involved, which is surprising to my naive understanding of what's happening.
In an extreme case (nested tuple of 250 elements, each with 4 arrays inside), I get 1 hour compilation time. I cannot share that example, but I built a simple reproducer below

```python
from numba import njit
import numpy as np

@njit
def foo(a):
    return a

for k in (5, 10, 25,50,100):
    tup2 = tuple( (1.1, 2.1, 3.1, 4.1, 5.1) for _ in range(k))
    a= foo(tup2)
    ptimes1 = foo.get_metadata()[foo.signatures[-1]]['pipeline_times']['nopython']
    print(k, sum([x.run for x in ptimes1.values()]))
    
# 5 0.32819065299554495
# 10 0.46837430398591096
# 25 1.147047581995139
# 50 2.5427525069899275
# 100 6.019512153005053

for k in (5, 10, 25,50,100):
    tup2 = tuple( (np.ones(1), np.ones(2), np.ones(3), np.ones(4), np.ones(5)) for _ in range(k))
    a= foo(tup2)
    ptimes1 = foo.get_metadata()[foo.signatures[-1]]['pipeline_times']['nopython']
    print(k, sum([x.run for x in ptimes1.values()]))
    
# 5 0.49908995699996694
# 10 1.2091799160000107
# 25 5.3744369600000255
# 50 24.340151891999938
# 100 192.002215966
```

cc @stuartarchibald 
user: luk-f-a
labels: performance: performance related issue
boxing: Problem with boxing/unboxing
issue_5950: state: open
title: ndarray.flags.writeable = False for structured array compiles/silently fails to assign with njit
body: I'd have expected some kind of error, either compile-time or run-time with the following code:

```python
import numpy as np
from numba import njit
cb_type = np.dtype([('a', np.int32), ])
types = np.zeros(1, dtype=cb_type)
types[0]['a'] = 4
types.flags.writeable = False
print(types)

@njit
def set_val():
    types[0]['a'] = 3

set_val()
print(types)
```
Instead, the assignment appears to be silently ignored, resulting in output of
```
[(4,)]
[(4,)]
```

Running as plain-python produces the expected exception:
```
ValueError: assignment destination is read-only
```
user: nelson2005
issue_5934: state: open
title: Cannot Fill 0d Structured/Record Arrays
body: 

- [ x] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Hello all. First of all thanks for numba! So it seems that filling or directly instantiating single element 0-dimensional structured arrays is not supported in numba, but it is supported in numpy. Below are several examples which fail in numba but work in numpy (assuming slight syntax changes .x -> ['x']).

```python
point_dtype = np.dtype([('x', np.float64),#])
                         ('y', np.float64)])
@njit
def fill_point1():
    np.array((1.0,2.0),dtype=point_dtype)

@njit
def fill_point2():
    p = np.empty((),dtype=point_dtype)
    p.x = 1.0
    p.y = 2.0

@njit
def fill_point3():
    p = np.empty((),dtype=point_dtype)
    p.x = np.array(1.0,dtype=np.float64)
    p.y = np.array(2.0,dtype=np.float64)

@njit
def fill_point4():
    p = np.recarray(1,dtype=point_dtype)
    p.x = 1.0
    p.y = 2.0

p = np.recarray(1,dtype=point_dtype)
@njit
def fill_point5(p):
    p.x = 1.0
    p.y = 2.0
```
This method does work though
```python
@njit
def fill_point_working():
    p = np.empty((1,),dtype=point_dtype)
    p[0].x = 1.0
    p[0].y = 2.0
```
user: DannyWeitekamp
issue_5932: state: open
title: Unification error for datetimes (minimum/maximum)
body: ## Reporting a bug

- [X] I have tried using the latest released version of Numba (most recent is
 visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Checked the docs and GH issues and can't find anything similar after a quick search.

conda list produces for numpy/numba:
```
numba                     0.49.1           py38h47e9c7a_0
numpy                     1.18.5           py38h6530119_0
numpy-base                1.18.5           py38hc3f5095_0
```

### Minimum Workable Example
```
import numpy as np
import numba

@numba.njit
def test(a, b, some_condition):
    if some_condition:
        x = a
    else:
        x = np.minimum(a, b)

    return x

test(np.datetime64("2000-01-01"), np.datetime64("2020-06-29"), False)
```

This produces the following error:
```
Cannot unify datetime64[] and datetime64[D] for 'x.2'

def test(a, b, some_condition):
    <source elided>

    return x
    ^
```
## Expected outcome
I would expect the smallest datetime (or largest for np.maximum) to be returned. For integers the test works great so what I think is happening is that np.minimum discards some metadata of the dtype, though I'm not entirely clear on how to fix this (e.g. if I use `np.minimum(a, b).astype("datetime64[D]")` I get a new error `Unknown attribute 'astype' of type datetime64[]`). 


## Full traceback

<details>
<summary>Traceback details</summary>
```
test(np.datetime64("1700-01-01"), np.datetime64("2000-01-01"), False)
Traceback (most recent call last):
  File "<...>\lib\site-packages\numba\core\dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "<...>\lib\site-packages\numba\core\dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "<...>\lib\site-packages\numba\core\utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Cannot unify datetime64[] and datetime64[D] for 'x.2', defined at <...>/scratch.py (691)

File "scratch.py", line 691:
def test(a, b, some_condition):
    <source elided>

    return x
    ^

[1] During: typing of assignment at <...>/scratch.py (691)

File "M1Code.py", line 691:
def test(a, b, some_condition):
    <source elided>

    return x
    ^
```
</details>
user: AA-Turner
issue_5929: state: open
title: numpy ediff1d tests have TypeError in `to_end` (numpy 1.19)
body: - [x] I have tried using the latest released version of Numba: 0.50.1
- [x] I have included below a minimal working reproducer

I'm seeing some errors in tests, building and running numba 0.50.1 on Debian unstable (python 3.8.3, numpy 1.19.0).

I'll focus on runtime test failures here (running tests on installed system, not build-time tests).  Runtime [tests](https://salsa.debian.org/science-team/numba/-/blob/debian/experimental/debian/tests/python3-numba) are triggered with `MPLBACKEND=Agg python3.8 -Wd -m numba.runtests -v -m` but the failing test can be run manually:

    python3 -m pytest -k "test_ediff1d_edge_cases" /usr/lib/python3/dist-packages/numba/tests/test_np_functions.py -v

The error summary is

    ======================================================================
    ERROR: test_ediff1d_edge_cases (numba.tests.test_np_functions.TestNPFunctions)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/usr/lib/python3/dist-packages/numba/tests/test_np_functions.py", line 2045, in test_ediff1d_edge_cases
        _check_raises_type_error(params, 'to_begin')
      File "/usr/lib/python3/dist-packages/numba/tests/test_np_functions.py", line 2012, in _check_raises_type_error
        pyfunc(**params)
      File "/usr/lib/python3/dist-packages/numba/tests/test_np_functions.py", line 229, in ediff1d
        return np.ediff1d(ary, to_end, to_begin)
      File "<__array_function__ internals>", line 5, in ediff1d
      File "/usr/lib/python3/dist-packages/numpy/lib/arraysetops.py", line 107, in ediff1d
        raise TypeError("dtype of `to_end` must be compatible "
    TypeError: dtype of `to_end` must be compatible with input `ary` under the `same_kind` rule.

This is with numpy 1.19 which has only just been released, so I'm wondering if it's an adjustment which numba needs to make in test_ediff1d_edge_cases to work with the new numpy.
user: drew-parsons
labels: good second issue: A good issue for second time contributors
issue_5924: state: open
title: allow staticmethod's to be compiled with jit(forceobj=True)
body: ## Feature request

A common design pattern that I run into is data classes that read/write to a file with a staticmethod. For example,
```python
import numpy as np

class Bag(object):
    def __init__(self, value):
        self.value = value
        self.array = np.zeros(value, dtype=np.float32)

    @staticmethod
    def from_file(filename):
        with open(filename, 'r') as f:
            value = int(f.readline().split()[0])
        return Bag(value)
```
To use this with jitclass, I currently need to use the objmode context manager. For example,
```python
import numpy as np
from numba import jitclass          # import the decorator
from numba import int32, float32    # import the types

spec = [
    ('value', int32),               # a simple scalar field
    ('array', float32[:]),          # an array field
]

@jitclass(spec)
class Bag(object):
    def __init__(self, value):
        self.value = value
        self.array = np.zeros(value, dtype=np.float32)

    @staticmethod
    def from_file(filename):
        with objmode(value='int32'):
            f = open(filename, 'r')
            value = int(f.readline().split()[0])
            f.close()
        return Bag(value)
```
I find this to be a bit inelegant, as the context manager adds an extra line of indentation. I also ran into some code that compiles fine as a separate function decorated with jit(forceobj=True) but fails for the objmode context manager (I can expand on this separately if you think it's worth addressing).

My proposed solution would be to add a kwarg to the jitclass decorator that specifies functions to be compiled with jit(objmode=True). For example,
```python
@jitclass(spec, objmode=['from_file', ...])
```
In principle, this doesn't need to be restricted to staticmethods, but that is the use case that I am targeting. I think the implementation would be straightforward (famous last words, am I right?). The code [here](https://github.com/numba/numba/blob/master/numba/experimental/jitclass/boxing.py#L48) would read:
```python
def _generate_method(name, func, objmode=False):
    """
    Generate a wrapper for calling a method.  Note the wrapper will only
    accept positional arguments.
    """
    source = _method_code_template.format(method=name)
    glbls = {}
    exec(source, glbls)
    if objmode:
        method = jit(glbls['method'], forceobj=True)
    else:
        method = njit(glbls['method'])

    @wraps(func)
    def wrapper(*args, **kwargs):
        return method(*args, **kwargs)

    return wrapper
```
Then the call to this function [here](https://github.com/numba/numba/blob/master/numba/experimental/jitclass/boxing.py#L105) would need to check if 'name' is in the objmode list.
user: mturiansky
issue_5916: state: open
title: Fix numba.typed.List pre-allocation
body: Currently pre-allocation, even though it is  implemented, does not work as intended.

Observe the following example:

```
In [6]: import numba as nb

In [7]: l = nb.typed.List(lsttype=nb.types.ListType(nb.int64), allocated=100)

In [8]: l._allocated
Out[8]: <bound method List._allocated of ListType[int64]([])>

In [9]: l._allocated()
Out[9]: 100

In [10]: l.append(0)

In [11]: l._allocated()
Out[11]: 4
```

So, as can been seen, the pre-allocation does indeed work and the list is instantiated with space for 100 elements. However, as soon as an element is appended to the `List` the allocation shrinks again. The reason for this is, that on an append, the list is resized and the semantics are such that the list allocation will shrink if it is deemed too large.

See also: https://github.com/numba/numba/blob/master/numba/cext/listobject.c#L365-L368

As possible solution here is to add a flag to the list structure, for example `no_realloc`. This could be set to false, before performing a known series of `append` operations, for example when instantiating a List from an iterable of known size, or when copying an existing List. Of course this method is a double edged sword as disabling reallocation of a List can quickly lead to segmentation faults if used without great care. 

Another use-case that comes to mind is `extend` and operations with similar semantics such as `setitem` with a slice. However, it is currently not possible to manually reallocate an existing List instance -- only pre-allocation upon initialization is currently supported. Effectively an additional c-level function `realloc` will need to be implemented to support this use-case too. It would then also benefit from the `no_realloc` flag however.

A `no_realloc` flag isn't the only design we have here. An alternative would be to implement a non-reallocating `resize` function and thereby enable a non-reallocating `append` variant which could be used in the situations described above. The advantage here is that it would not require the programmer to remember to unset the `no_realloc` flag again.
user: esc
issue_5915: state: open
title: Accelerate numba.typed.List constructor when used from the interpreter. 
body: Currently the creation of a `numba.typed.List` from an iterable in the interpreter runs in interpreted Python. There may  be performance gains to be achieved, by moving this creation process to a JIT compiled function.

As a motivation, let's have a quick look at the following example:

```python
import numpy as np
import numba as nb


@nb.njit
def create(array):
    return nb.typed.List(array)

a = np.arange(1000000)
```

Then timing this results in:

```
In [2]: %timeit create.py_func(a)
1.1 s ± 10.4 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [3]: %timeit create(a)
9.81 ms ± 850 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [4]: %timeit create.py_func(a)
1.15 s ± 23 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [5]: %timeit create(a)
10.7 ms ± 864 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
````

The code in question is here:

https://github.com/numba/numba/blob/master/numba/typed/typedlist.py#L242-L247
user: esc
labels: performance: performance related issue
issue_5911: state: open
title: Feature Request: __hash__ for Enum and IntEnum
body: Initial discussion https://gitter.im/numba/numba?at=5ef0a19f54d7862dc4a03f1f

Currently `__hash__` is not implemented for `Enum` and `IntEnum`. Because of this they cannot be used as keys for `typed.Dict` which is a bit unfortunate.

The CPython implementation for hashing Enums is surprising simple, it is simply `hash(name)`

https://github.com/python/cpython/blob/b4e85cadfbc2b1b24ec5f3159e351dbacedaa5e0/Lib/enum.py#L641-L642

But unfortunately within numba Enums are currently lowered as their Value field only, so that the name field is not trivially accessible. Therefore implementing the `__hash__` function may get tricky.

https://github.com/numba/numba/blob/ae598dbf252bad3917b76d9e9844e6ab59bcd218/numba/cpython/enumimpl.py#L55-L60
------------------------

In case someone wants to look into this a few hints (or things that surprised me):
```python
In [1]: from enum import Enum 
   ...:  
   ...: class Color(Enum): 
   ...:     RED = 1 
   ...:     BLUE = 2 
   ...:     GREEN=3 
   ...:     MAGENTA=1 
   ...:                                                                                                              

In [2]: type(Color)                                                                                                  
Out[2]: enum.EnumMeta 
# Enums are of type EnumMeta (but the type is called Enum in numba)

In [3]: type(Color.RED)                                                                                              
Out[3]: <enum 'Color'> 
# Enum members are of type Enum (but the type is called EnumMember in numba)

In [4]: Color.RED.name                                                                                               
Out[4]: 'RED'

In [5]: Color.BLUE.name                                                                                              
Out[5]: 'BLUE'

In [6]: Color.MAGENTA.name                                                                                           
Out[6]: 'RED'
# Aliases (members with same value) seem to have their name set to the first member 
# with this value, this is why all aliases have the same hash

```
user: HPLegion
issue_5910: state: open
title: AOT compiled function inside JIT function fails.
body: I am trying to use numba to speed up a project, but I have hit an issue trying to use an AOT-compiled function inside a JIT-compiled function. Is this expected to be supported?

My reason for wanting to do this is that I have a family of physical functions that are very slow to compile and that are pretty much set in stone, with a caller function that is fast to compile and likely to change, which made me want to compile the first set AOT and the caller JIT.

I've made a minimal working example with the following structure:
```
test
-- __init__.py
-- foo_src.py
-- test.py`
```

foo_src.py contains:
```
from numba import jit
from numba.pycc import CC

cc = CC('foo')

@jit(nopython=True)
@cc.export('bar', 'i8(i8)')
def bar(x):
    return x * 4

if __name__ == "__main__":
    cc.compile()`
```

test.py contains:
```
from numba import jit
import foo

@jit(nopython=True)
def baz(x):
    y = 0
    for i in range(x):
        y += foo.bar(i)
    return y

if __name__ == "__main__":
    print (baz(10))`
```
The error message I get is:
```
Unknown attribute 'bar' of type Module(<module 'foo' from 'D:\\pythontest\\foo.cp37-win_amd64.pyd'>)
```

I've checked that it works fine with the same functions if make both JIT or both AOT, but the combination seems to fail.

user: thijsvanputten
labels: AOT: ahead of time compilation issue
issue_5909: state: open
title: typedlist slower than Python list
body: Here is a basic and pure Python implementation of the Dijkstra's algorithm:


```python
from heapq import heappush, heappop

def dijkstra(adj_List, weights_List, src):
    """
    Dijkstra algorithm for Python list
    # Arguments
        adj_List: list of lists of int
        weights_List: list of lists of float
        src: int

    # Output : lists of float
    """
    n=len(adj_List)
    
    processed= [0]*n
    processed[src]=1 
    
    INF=float("inf")
    
    dist= [INF]*n
    dist[src]=0.     

    distances=[src]
       
    while len(distances)!=0:
        u=heappop(distances)
        d=dist[u]
        if processed[u]==1:
            processed[u]=2
            
            k=len(adj_List[u])
            a_u=adj_List[u]
            w_u=weights_List[u]
                
            for i in range(k):
                v=a_u[i]
                w=w_u[i]
                dd=d+w
                if processed[v]==0 or dd<dist[v]:
                    heappush(distances, v)
                    dist[v]=dd
                    if processed[v]==0:
                        processed[v]=1
    return dist
```


To adapt this implementation to Numba nopython mode, you need to use typedlist because adjacency lists are lists of lists. The heapqueue is not a problem here since it deals only with a Python one dimensional list of ints. Adapting is pretty straightforward:

```python
@njit
def dijkstra_numba(adj_List, weights_List, src):
    """
    Dijkstra algorithm for Numba typedlist
    # Arguments
        adj_List: ListType[ListType[int64]]
        weights_List: ListType[ListType[double]]
        src: int

    # Output : ListType[double]
    """
    
    n=len(adj_List)
    
    # Numba typedlist
    processed= List([0]*n)
    processed[src]=1 
    
    INF=np.inf

    # Numba typedlist    
    dist= List([INF]*n)
    dist[src]=0.     

    distances=[src]
       
    while len(distances)!=0:
        u=heappop(distances)
        d=dist[u]
        if processed[u]==1:
            processed[u]=2
            
            k=len(adj_List[u])
            a_u=adj_List[u]
            w_u=weights_List[u]
                
            for i in range(k):
                v=a_u[i]
                w=w_u[i]
                dd=d+w
                if processed[v]==0 or dd<dist[v]:
                    heappush(distances, v)
                    dist[v]=dd
                    if processed[v]==0:
                        processed[v]=1
    return dist
```


The code is the same except for the type of the lists. The problem is that the Numba implementation is slower than the pure Python one. Against a graph with 1200 vertices, the results are :



```
Generating graph data structure from stdin
...
Number of vertices : 1200
Number of edges : 150000
Number of src to be tested : 120
Generated in 0.23s

Python List:    0.78s

Conversion to Numba typedlist:  1.67s

Numba List:     0.91s

Check: True
```


I have the same speed ratio with a bigger test file (7000 vertices and 1,750,000 edges). The same algorithm written in C++ is 40 faster than pure Python code, so there is probably room for improvement.

Again, the Python heapqueue is not a problem : if you pack adjacency lists into two big **Numpy arrays**, using an offsett array and the same heapqueue but  avoiding typelists, Numba performs 15 better than pure Python code but this implementation is tricky and unreadable.


Links to test files : [test_graphs_dijkstra.zip](https://drive.google.com/file/d/1bnJHu0jqQogdPH_HPvPG-ZPaIFDGyhcY/view?usp=sharing)

The complete code (Python 3.6 and Numba 0.50 on Linux Ubuntu 18.04):



```python
from time import  perf_counter
from heapq import heappush, heappop
import numpy as np
from numba import njit, int64, double
from numba.typed import List 


# ============ Dijkstra all shortest path from src ===========================

def dijkstra(adj_List, weights_List, src):
    """
    Dijkstra algorithm for Python list
    # Arguments
        adj_List: list of lists of int
        weights_List: list of lists of float
        src: int

    # Output : lists of float
    """
    n=len(adj_List)
    
    processed= [0]*n
    processed[src]=1 
    
    INF=float("inf")
    
    dist= [INF]*n
    dist[src]=0.     

    distances=[src]
       
    while len(distances)!=0:
        u=heappop(distances)
        d=dist[u]
        if processed[u]==1:
            processed[u]=2
            
            k=len(adj_List[u])
            a_u=adj_List[u]
            w_u=weights_List[u]
                
            for i in range(k):
                v=a_u[i]
                w=w_u[i]
                dd=d+w
                if processed[v]==0 or dd<dist[v]:
                    heappush(distances, v)
                    dist[v]=dd
                    if processed[v]==0:
                        processed[v]=1
    return dist


@njit
def dijkstra_numba(adj_List, weights_List, src):
    """
    Dijkstra algorithm for Numba typedlist
    # Arguments
        adj_List: ListType[ListType[int64]]
        weights_List: ListType[ListType[double]]
        src: int

    # Output : ListType[double]
    """
    
    n=len(adj_List)
    
    # Numba typedlist
    processed= List([0]*n)
    processed[src]=1 
    
    INF=np.inf

    # Numba typedlist    
    dist= List([INF]*n)
    dist[src]=0.     

    distances=[src]
       
    while len(distances)!=0:
        u=heappop(distances)
        d=dist[u]
        if processed[u]==1:
            processed[u]=2
            
            k=len(adj_List[u])
            a_u=adj_List[u]
            w_u=weights_List[u]
                
            for i in range(k):
                v=a_u[i]
                w=w_u[i]
                dd=d+w
                if processed[v]==0 or dd<dist[v]:
                    heappush(distances, v)
                    dist[v]=dd
                    if processed[v]==0:
                        processed[v]=1
    return dist

# =======================================

def get_data_from_stdin():
    # returns adjacency list 
    # and the corresponding weighted list
    # as native Python list of lists
    ntests=int(input())
    all_src=[int(input()) for _ in range(ntests)]
    n=int(input())
    adj_List, weights_List=[[] for _ in range(n)],[[] for _ in range(n)]

    for u in range(n):
        input()
        degree=int(input())
        for _ in range(degree):
            w, v = input().split()
            adj_List[u].append(int(v))
            weights_List[u].append(float(w))
    return adj_List, weights_List, all_src

def list2List(M, numba_type):
    # converts from a Python list of list
    # to the corresponding
    # Numba typedlist of typedlists
    # Numba_type : int64 or double
    
    N=List([List([numba_type(0)])])
    N.pop() # to get an empty List
    for L in M:
        if L:
            N.append(List(L))
        else:
            t=List.empty_list(numba_type)
            N.append(t)
    return N

def convert2numba(adj_List, weights_List):
    # converts Python adjacency lists
    # to the corresponding Numba adjacency typedlists

    numba_type=int64
    adj_List=list2List(adj_List, numba_type)

    numba_type=double
    weights_List=list2List(weights_List, numba_type)
    
    return adj_List, weights_List
    
# =================== Adjancency lists generation =====================

print("Generating graph data structure from stdin")
print("...")

begin_perf=perf_counter()


adj_List, weights_List, all_src =get_data_from_stdin()

print("Number of vertices : %s" %len(adj_List))
print("Number of edges : %s" %(sum(len(L) for L in adj_List)))
print("Number of src to be tested : %s" %len(all_src))

print("Generated in %.2fs\n" %(perf_counter()-begin_perf))

# =================== Dijkstra with Python list ===================


begin_perf=perf_counter()

dist_python_list=[dijkstra(adj_List, weights_List, origin) for origin in all_src]

elapsed_numba_list = perf_counter()-begin_perf

print("Python list:\t%.2fs\n" %elapsed_numba_list)


# =================== Data Conversion from Python 2d-lists to Numba 2d-typedlists   ===================



begin_perf=perf_counter()

adj_List, weights_List=convert2numba(adj_List, weights_List)

elapsed_conversion = perf_counter()-begin_perf

print("Conversion to Numba typedlist:\t%.2fs\n" %elapsed_conversion)    


# =================== Dijkstra with Numba typedlist ===================


# Numba compilation warmup
origin=all_src[0]
dist=dijkstra_numba(adj_List, weights_List, origin)


begin_perf=perf_counter()

distances_numba=[dijkstra_numba(adj_List, weights_List, origin) for origin in all_src]

elapsed_numba_list = perf_counter()-begin_perf

print("Numba List:\t%.2fs\n" %elapsed_numba_list)    

# =======================================================

# checking the results
dist_numba_list_to_list = list(list(t) for t in distances_numba)
print("Check:", dist_python_list == dist_numba_list_to_list)
```






user: Pascal-Ortiz
labels: performance: performance related issue
issue_5907: state: open
title: Numpy wrappers not used for scalar return values
body: Numba-compiled functions that return scalars are not a drop-in replacement for the Numpy equivalents. Consider:

```
print(np.sum(np.zeros(5, dtype='uint64')).dtype)
print(nb.njit()(lambda xs: np.sum(xs))(np.zeros(5, dtype='uint64')).dtype)
```

This prints `uint64` and then fails  (`AttributeError: 'int' object has no attribute 'dtype'`). The issue is that Numba is not wrapping the scalar result in a numpy wrapper type.

It's useful to preserve the dtype to support patterns like this generalized rolling window function:

```
def rolling_window(f, window, xs):
    N, = xs.shape
    
    result = np.empty(max(0, N - window), dtype=f(xs[:0]).dtype)
    for i in range(N - window):
        result[i] = f(xs[i:i+window])
    
    return result

rolling_window(np.sum, 2, np.array([True, False, True, True])) # Works
rolling_window(nb.njit()(lambda x: np.sum(x)), 2, np.array([True, False, True, True])) # Fails
```

user: batterseapower
issue_5905: state: open
title: Yielding while iterating over a typed list results in a segfault
body: In Numba 0.50 on macOS Catalina yielding while iterating over a typed list in a no-object mode jitted function results in a segfault, regardless of whether the entries of the list are used or not.

The issue can be reproduced with (simplified—any real use-case would include using the entries of the list):
```python
import numba as nb

@nb.njit
def create_generator():
    foo = nb.typed.List([1, 2])
    for _ in foo:
        yield 1

generator = create_generator()
next(generator)
next(generator)  # Segfaults
```

Doing the same with a reflected list works as expected:
```python
import numba as nb

@nb.njit
def create_generator():
    foo = [1, 2]
    for _ in foo:
        yield 1

generator = create_generator()
next(generator)
next(generator)  # 1
```
user: Allardvm
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_5904: state: open
title: Performance issue with prange when an user-defined function is called
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

The notebook that contains the results are here: https://github.com/yaoyuki/prange_performance/blob/master/example_performance_issue.ipynb

In the following example, I want to parallelize a function rand over multiple random seeds. I faced a performance issue with it when rand calls a user-defined function 'exponential'. However, If I do not use the function 'exponential' but do the same thing in a tedious way in rand, I did get a big performance gain. I'm suspecting a bug here.


```python
import numpy as np
import numba as nb
import numpy.random as rng

mus = np.array([0.1, 0.2, 0.3, 0.4, 0.5, 0.6])

@nb.njit
def exponential(scales):
    
    length = len(scales)
    t_array = np.zeros((length))
    
    for i in range(length):
        t_array[i] = rng.exponential(scales[i])
        
    return t_array

@nb.njit
def rand(mus, step_max, seed):
    
    step = 0
    tau = 0.
    
    rng.seed(seed)
    dtaus = np.zeros(len(mus))
    
    while (step < step_max):
        step = step + 1
        
        dtaus = exponential(1./mus)
        
        tau += np.min(dtaus)
        
    return tau

@nb.njit
def nopar_simulate_multi(mus, step_max, num):
    
    seeds = np.arange(num)
    taus = np.zeros(num)
    
    for i in nb.prange(num):
        tau = rand(mus, step_max, seeds[i])
        
        taus[i] = tau
        
        
    return taus

@nb.njit(parallel = True)
def par_simulate_multi(mus, step_max, num):
    
    seeds = np.arange(num)
    taus = np.zeros(num)
    
    for i in nb.prange(num):
        tau = rand(mus, step_max, seeds[i])
        
        taus[i] = tau
        
        
    return taus

```

```python
%%time
tmp = nopar_simulate_multi(mus, 50000, 320)
```
> CPU times: user 10.2 s, sys: 9.47 ms, total: 10.2 s
> Wall time: 10.1 s

```python
%%time
tmp = par_simulate_multi(mus, 50000, 320)
```
> CPU times: user 6min 39s, sys: 306 ms, total: 6min 39s
> Wall time: 7.16 s

I instead loop over mus inside the rand, 
I do get good performance from prange.

```python
@nb.njit
def rand_wo(mus, step_max, seed):

    
    step = 0
    tau = 0.
    
    rng.seed(seed)
    dtaus = np.zeros(len(mus))
    
    while (step < step_max):
        step = step + 1
        
        for i in range(len(mus)):
            dtaus[i] = rng.exponential(1./mus[i])
        
        
        tau += np.min(dtaus)
        
    return tau

@nb.njit
def nopar_simulate_multi_wo(mus, step_max, num):
    
    seeds = np.arange(num)
    taus = np.zeros(num)
    
    for i in nb.prange(num):
        tau = rand_wo(mus, step_max, seeds[i])
        
        taus[i] = tau
        
        
    return taus


@nb.njit(parallel = True)
def par_simulate_multi_wo(mus, step_max, num):
    
    seeds = np.arange(num)
    taus = np.zeros(num)
    
    for i in nb.prange(num):
        tau = rand_wo(mus, step_max, seeds[i])
        
        taus[i] = tau
        
        
    return taus

```

```python
%%time
tmp = nopar_simulate_multi_wo(mus, 50000, 320)
```
> CPU times: user 7.66 s, sys: 3.05 ms, total: 7.66 s
> Wall time: 7.6 s

```python
%%time
tmp = par_simulate_multi_wo(mus, 50000, 320)
```
> CPU times: user 9.45 s, sys: 25 ms, total: 9.48 s
> Wall time: 220 ms


<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I use numba 0.49.1 on anaconda.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: yaoyuki
labels: performance: performance related issue
issue_5903: state: open
title: Keyword-only arguments and default arguments always do the wrong thing when combined
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

Default arguments never work with keyword-only arguments:

```python
import numba 
@numba.njit
def foo(a, b = 1, *, c = 10):
    return a + b + c

foo(1, 2) 
# gives: 4
# expected: 13

foo(1) 
# gives: TypeError: not enough arguments: expected at least 2, got 1
# expected: 12

@numba.njit
def bar(a, b = 1, *, c):
    return a + b + c

bar(1, c=2)
# gives: TypeError: missing argument 'b'
# expected: 4

bar(1, 2)
# gives: 4
# expected: TypeError: missing argument 'c'

@numba.njit
def baz(a, b, *, c = 1):
    return a + b + c

baz(1, 1)
# gives: TypeError: not enough arguments: expected 3, got 2
# expected: 3
```
<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->


user: eric-wieser
issue_5899: state: open
title: Add support for programming Tensor Cores in CUDA kernel
body: ## Feature request

Please add the possibility to use Tensor Cores, from the RTX NVIDIA GPUs, when writing a CUDA kernel. This would enable to perform high speed matrix multiplications in FP16 / FP32. 
user: diepala
labels: CUDA: CUDA related issue/PR
issue_5897: state: open
title: Reflected-list and typed List produce slow concatenate for list of equal sized arrays
body: Hi, I am trying to take advantage of having `N` numpy arrays of `shape=(1, 2)` and implement a faster version of `np.concatenate` using Numba (for this particular case). I have tried this implementation:

```python
import numpy as np
from numba import njit
from numba.typed import List

@njit
def _concat_equal1(arrays, out):
    for i in range(len(arrays)):
        out[i] =  arrays[i][0]

    return out

def concat_equal1(arrays):
    out = np.empty(shape=(len(arrays), 2), dtype=float)
    return _concat_equal1(arrays, out) 
```

The problem is that when `arrays` is a reflected-list the performance is really slow (especially when compared with numpy's "optimized" concatenate function:

```python
a = np.random.random(size=(1000, 2))
la = [ai[np.newaxis] for ai in a]

>>> %timeit np.concatenate(la)
361 µs ± 7.14 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

>>> %timeit concat_equal1(la)
10.7 ms ± 187 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
```

However, when I use a `numba.typed.List` I get a much better performance:
```python
>>> tla = List(la)
>>> %timeit concat_equal1(tla)
77.9 µs ± 1.23 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```

 Which seems great! **But** the time that takes to construct a typed List is orders of magnitude worse:
```python
>>> %timeit tla = List(la)
1.6 ms ± 23.9 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```
This calls `append` for each item and performs real poorly smh.

Am I doing something wrong? Can this be achieved in other ways?

Thanks,
Michael

user: mishana
labels: performance - run time: Performance issue occurring at run time.
issue_5896: state: open
title: 'NoneType' object has no attribute 'args'
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

The following code:
```
from numba.pycc import CC


def main():
    ds = {1: (2, 3)}       # (A)
    x = ds.get(1, (4, 5))  # (B)
    # x = ds[1]            # (B2)
    y = x[1]               # (C)


cc = CC('my_module')
cc.export('main', '()')(main)
cc.compile()
```

produces the following error(digested):

```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
'NoneType' object has no attribute 'args'

File "t2.py", line 8:
def main():
    <source elided>
    # x = ds[1]            # (B2)
    y = x[1]               # (C)
    ^

During: lowering "$26binary_subscr.10 = static_getitem(value=x, index=1, index_var=$const24.9)" at t2.py (8)
```

Full stderr: https://gist.github.com/nishio/99eebe8011553025726a7730d2bef61f

If I use the line B2 instead of the line B, the error doesn't occur.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: nishio
issue_5895: state: open
title: Support for numpy.dot in higher dimensions
body: (Sorry for posting twice in a row) Currently np.dot is only supported on 1D and 2D arrays, may be useful to have this feature in 3D arrays as well for convolutions and such
user: George-Lu-1997
issue_5894: state: open
title: Support for np.ix_
body: This allows us to easily retrieve slices of multi-dimensional arrays
user: George-Lu-1997
issue_5886: state: open
title: Add support for overloading the __call__ operator
body: With this in place, `@numba.extending.overload_method(ExtensionType, '__call__')` appears to work.

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
mailing list https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

Possibly a fix for #5885.
user: eric-wieser
issue_5885: state: open
title: Add support for overloading `__call__` on custom types with `extending.overload`
body: ## Feature request

It would be great if I could write:
```pass
@numba.extending.overload('call')
def my_type_call(self):
    if isinstance(self, MyNumbaExtensionType):
        return lambda self: 42
```

This is likely a prerequisite for #1606
user: eric-wieser
issue_5880: state: open
title: Bug: Argwhere returns `a` storage 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

`np.argwhere` returns an object with storage type `a`, but this should not happen (I think), because non-numb numpy returns a standard array and the code works fine.

cc @gcarleo

Reproducer:
```python
>>> from numba import njit
>>> import numpy as np
>>> a=np.array([True, False, False, True, False])
>>> @njit
... def test(arr):
...   return np.argwhere(arr).reshape(-1)
...
>>> test(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/filippovicentini/Documents/pythonenvs/1_Carleo_FFNN/lib/python3.7/site-packages/numba/core/dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/Users/filippovicentini/Documents/pythonenvs/1_Carleo_FFNN/lib/python3.7/site-packages/numba/core/dispatcher.py", line 358, in error_rewrite
    reraise(type(e), e, None)
  File "/Users/filippovicentini/Documents/pythonenvs/1_Carleo_FFNN/lib/python3.7/site-packages/numba/core/utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
- Resolution failure for literal arguments:
reshape() supports contiguous array only
- Resolution failure for non-literal arguments:
reshape() supports contiguous array only

During: resolving callee type: BoundFunction(array.reshape for array(int64, 2d, A))
During: typing of call at <stdin> (3)


File "<stdin>", line 3:
<source missing, REPL/exec in use?>
```

```
import numba
>>> numba.__version__
'0.50.0'
```
user: PhilipVinc
issue_5878: state: open
title: ConcurrentBag-like data structure for parallel appends
body: I'm writing an `@njit(parallel=True)` decorated function which runs a `prange` loop. The intent was to define a data structure outside the loop, and append to it from within, like so:

```
@njit(parallel=True)
def parallel_append():
    thing_to_append_to = ConcurrentBag()
    for i in prange(100):
        thing_to_append_to.append(i)
```

The order of insertion is unimportant; naturally, it cannot be guaranteed anyway. Unfortunately, replacing the imaginary `ConcurrentBag()` with a `TypedList`, `set` or any other data structure seems to return:

```
Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
```

Or similar `SIG*` errors. Presumably because it's not thread safe. A concurrent bag-like data structure would be super helpful because it is not always efficient to preallocate a NumPy array (In my case, the expected number of appends are orders of magnitude less than the maximum number). Not only that, but one can append namedtuples and other useful structures to a list, while NumPy arrays are limited to primitives for now.
user: lowjiajin
issue_5875: state: open
title: libdispatch-based (GCD) workqueue
body: It might be useful to have a workqueue implementation (for when ``parallel=True`` is used) based on [libdispatch](https://github.com/apple/swift-corelibs-libdispatch) (aka Grand Central Dispatch). For users running on macOS, a libdispatch-based workqueue could provide additional efficiency compared to e.g. TBB due to it's integration with the OS and scheduler. With _libdispatch_ being available as part of the OS, it would also give users a decent parallel backend without _requiring_ the additional package dependency on TBB (so they'd just opt-in if they wanted it).

@seibert suggested this as a possible approach in #2091, but once the TBB backend was implemented in #2217 it seems to have been forgotten about.

I ran across an old-but-interesting blog post comparing the scalability of GCD vs. OpenMP for parallelized computational tasks; there's been a lot of work and improvements both to GCD and OpenMP runtimes since the post was written and the results would likely be different now, but it does demonstrate some viability of the approach:
http://www.idryman.org/blog/2012/08/05/grand-central-dispatch-vs-openmp/

Is there any opposition to having a _libdispatch_-based workqueue in numba? If not, I can take a shot at implementing one.
user: jack-pappas
issue_5874: state: open
title: Support literal string in structured dtype 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Details from gitter conversation at https://gitter.im/numba/numba?at=5ee899037c64f31f1163b038

usecase:
```python
import numpy as np
from numba import njit
from numba.types import literal

dt = np.dtype([('attr1', np.float64), ('attr2', np.int64)], align=True)
a = np.zeros(10, dtype=dt)

@njit
def h(a, aname):
    return a[aname]

h(a, literal('attr1'))
```

traceback:
```pytb
Invalid use of Function(<built-in function getitem>) with argument(s) of type(s): (array(Record(attr1[type=float64;offset=0],attr2[type=int64;offset=8];16;True), 1d, C), Literalstr)
```

Numba should expand structured dtype getitem to support literal string.


user: sklam
labels: good second issue: A good issue for second time contributors
issue_5873: state: open
title: Implement `type` key-word-argument for `numba.typed.List` constructor
body: Since the inception of the `numba.typed.List` the `List.empty_list` factory method has been a crutch to get the code working. Originally, it was supposed to be called `List.empty` -- however due to "reasons" this caused a conflict with `numba.typed.Dict.empty` (investigation to follow) and so it now has it's current unwieldy form.

Now that `numba.typed.List` has a way to be initialized in a Pythonic fashion from an iterable (see: https://github.com/numba/numba/pull/5294),  it would be nice to allow the constructor to take `type` (or `typ` or `type_` to avoid naming conflicts?) as a keyword argument, so as to allow manual specification of the types. As outlined in https://github.com/numba/numba/pull/5716 the API would look something like:

```
l = List()                 # empty list with undefined type
l = List(type=int64)       # empty list with defined type
l = List(iter)             # list initialized from iter
l = List(iter, type=int64) # list initialized from iter and with items cast to given type
```

In addition, we may want to deprecate/rename `empty_list` to `_empty_list` since it will probably still be used under the hood. And also, some parts of the code-base may need to be updated to reflect this change. Lastly the documentation will need to be scanned and potentially updated to reflect the changes.

Note: this should also be made compatible with `NUMBA_DISABLE_JIT` as in this case, the keyword argument will just be ignore and a regular Python list will be returned.
user: esc
labels: discussion: An issue requiring discussion
issue_5872: state: open
title: cannot write to numpy array in namedtuple with parallel=True
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

With `parallel=True` it does not seem as if anything is wirtten to a numpy array in a namedtuple.

Running this code:

```
import numpy as np
from collections import namedtuple
from numba import njit, prange

sol_tuple = namedtuple(f'sol',['N','x','y'])
N = 10
sol = sol_tuple(N=N,x=np.zeros(N),y=np.zeros(N))

@njit
def test(sol):
    sol.y[:] = 5
    for i in prange(sol.N):
        if i < 5:
            sol.x[i] = i**2
        else:
            sol.x[i] = i

test(sol)
print(sol.x)
print(sol.y)
```

Results in both arrays being zero:

```
[0. 0. 0. 0. 0. 0. 0. 0. 0. 0.]
[0. 0. 0. 0. 0. 0. 0. 0. 0. 0.]
```

When removing `parallel=True`  the code correctly results in:

```
[ 0.  1.  4.  9. 16.  5.  6.  7.  8.  9.]
[5. 5. 5. 5. 5. 5. 5. 5. 5. 5.]
```
user: JeppeDruedahl
issue_5864: state: open
title: Support for np.fft.fft, np.fft.ifft etc.
body: ## Feature request

It would be amazing if numba would support the [FFT pack of numpy](https://numpy.org/doc/1.18/reference/routines.fft.html). Personally, I would be interested in

```
   np.fft.fft
   np.fft.ifft
   np.fft.rfft
   np.fft.irfft
```

Obviously, there are many applications in signal processing that could benefit from this.

Are there any plans for that?



user: fhchl
issue_5863: state: open
title: Add Table with llvm, llvmlite and numba compatibility to Readme
body: Sometimes it is not possible to use the most recent version of `numba` and `llvmlite` because a given system has only an older version of `llvm` installed.

There is a compatiblity table included in the readme of `llvmlite` (https://github.com/numba/llvmlite#compatibility), but it would be also really helpful sometimes to have an easy way of figuring out which `numba` version would be optimal for a given configuration.

I think a similar table in the readme of `numba` would be a nice addition.

The information usually is provided in the release notes and could be compiled from there without to much efforts.
user: cosama
issue_5845: state: open
title: Refactor deepcopy func_ir and its statements.
body: There should be a better way to deepcopy a func_ir including its statements.

_Originally posted by @sklam in https://github.com/numba/numba/pull/5812/review_comment/create_
user: sklam
issue_5840: state: open
title: Typed Tuple
body: This PR adds a decorator `@typed_tuple` that can be used to enforce type constraints on a `namedtuple` class.  Doing this allows us to statically define the numba type, so we do not need to escape to python during dispatch when such a tuple is passed as an argument to a jitted function.  This gives an order of magnitude speedup in such cases (see docstring of `typed_tuple` for examples).

This PR depends on the typing work from https://github.com/numba/numba/pull/5609.
user: EPronovost
issue_5839: state: open
title: Dispatching for custom types is way slower than builtin types
body: ## Feature request
Given two very simple functions:
```python
@numba.njit
def ident(x):
    return x

@numba.njit
def value_of(y):
    return y.value
```
and a custom type something like:
```python
class MultiVector:
    value: np.ndarray  # shape (32,)

class MultiVectorType(types.Type):
    def __init__(self, dtype: np.dtype):
        assert isinstance(dtype, np.dtype)
        self.dtype = dtype
        super().__init__(name='MultiVector[{!r}]'.format(numba.from_dtype(dtype)))

    @property
    def key(self):
        return self.dtype

    @property
    def value_type(self):
        return numba.from_dtype(self.dtype)[:]

@numba.extending.typeof_impl.register(MultiVector)
def _typeof_MultiVector(val: MultiVector, c) -> MultiVectorType:
    return MultiVectorType(dtype=val.value.dtype)

@numba.extending.register_model(MultiVectorType)
class MultiVectorModel(numba.extending.models.StructModel):
    def __init__(self, dmm, fe_type):
        members = [
            ('value', fe_type.value_type),
        ]
        super().__init__(dmm, fe_type, members)
```
I see an order of magnitude difference between the time taken to dispatch to the correct implementation
```python

In [30]: %prun -D v2.stats for i in range(1000): ident(e1.value)
         1003 function calls in 0.002 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.002    0.002    0.002    0.002 <string>:1(<module>)
     1000    0.000    0.000    0.000    0.000 <ipython-input-16-a8e3226cc0f9>:1(ident)
        1    0.000    0.000    0.002    0.002 {built-in method builtins.exec}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
```
```python
In [29]: %prun for i in range(1000): value_of(e1)
         26003 function calls in 0.037 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.006    0.006    0.037    0.037 <string>:1(<module>)
     1000    0.005    0.000    0.009    0.000 _multivector.py:29(__init__)
     1000    0.003    0.000    0.018    0.000 abstract.py:59(__call__)
     1000    0.002    0.000    0.021    0.000 _multivector.py:47(_typeof_MultiVector)
     1000    0.002    0.000    0.002    0.000 <ipython-input-1-32c196e65f6a>:2(value_of)
     1000    0.002    0.000    0.028    0.000 typeof.py:23(typeof)
     1000    0.002    0.000    0.030    0.000 dispatcher.py:629(typeof_pyval)
     1000    0.002    0.000    0.002    0.000 {method 'format' of 'str' objects}
     1000    0.002    0.000    0.025    0.000 functools.py:869(wrapper)
     1000    0.002    0.000    0.007    0.000 abstract.py:47(_intern)
     1000    0.002    0.000    0.005    0.000 {method 'get' of 'dict' objects}
     1000    0.001    0.000    0.002    0.000 functools.py:813(dispatch)
     1000    0.001    0.000    0.002    0.000 abstract.py:120(__eq__)
     1000    0.001    0.000    0.002    0.000 abstract.py:117(__hash__)
     1000    0.001    0.000    0.001    0.000 numpy_support.py:84(from_dtype)
     1000    0.001    0.000    0.001    0.000 weakref.py:382(__getitem__)
     3000    0.001    0.000    0.001    0.000 _multivector.py:34(key)
     1000    0.001    0.000    0.001    0.000 <string>:1(__new__)
     1000    0.001    0.000    0.001    0.000 {built-in method __new__ of type object at 0x00007FF803D13810}
     1000    0.000    0.000    0.000    0.000 abstract.py:92(__init__)
     1000    0.000    0.000    0.000    0.000 {built-in method builtins.hash}
     1000    0.000    0.000    0.000    0.000 abstract.py:114(__repr__)
     1000    0.000    0.000    0.000    0.000 {built-in method builtins.getattr}
     1000    0.000    0.000    0.000    0.000 {built-in method _abc.get_cache_token}
     1000    0.000    0.000    0.000    0.000 {built-in method builtins.isinstance}
        1    0.000    0.000    0.037    0.037 {built-in method builtins.exec}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
```

What's happening is that `ident(e1.value)` is taking a fast path in `typecode_using_fingerprint`, while my type has to got through the `functools.singledispatch` path.

Here's the `snakeviz` output for the custom type:

![image](https://user-images.githubusercontent.com/425260/84183242-7e064800-aa83-11ea-861c-1034dedf1a5f.png)

Note that only slight more than half the dispatch time is actually spent in my `__init__` and `_typeof_MultiVector` functions, the rest is just overhead.
user: eric-wieser
labels: performance: performance related issue
discussion: An issue requiring discussion
performance - run time: Performance issue occurring at run time.
issue_5831: state: open
title: Make boxing two-phase to more efficiently support dependent types
body: ## Feature request

Today, `box`ing takes arguments `(typ, val, c)`, and is responsible for assembling the compiled function body which calls C API's to reconstruct a fully-formed `PyObject *` pointer.

The requirement to emit C APIs is rather burdensome. Typically, this unboxing will need to invoke a constructor for a regular python type, which means either it must:
* Be pickled into the compiled bytecode, and reassembled upon request.
* Have a statically-declared name, and be imported by the boxer
* Have its pointer address embedded into the boxer, which feels dangerous in the face of file-system caching or object lifetime. This is the approach taken by `jitclass`:
  https://github.com/numba/numba/blob/015dbf83df8b11bb25d0aa6b96cae809939dfaf6/numba/experimental/jitclass/boxing.py#L134-L146

These problems are a big deal for dependent types (aka dynamically created `type`s), because:
* `pickle` results can now be large and slow to reassemble.
* no statically declared name is available.

My idea is that boxing could be modelled in the same way as unpickling:

* Instead of producing the final `PyObject *`, the boxer should produce an intermediate object.
* After running all the C level boxers, the final step of all jitted functions is to run the post-processor from the python side, of `return_type.final_box(intermediate_val)`:
* Built-in collection types like `list` would have second-stage boxers like:
  ```python
  def final_unbox(typ, intermed):
      return [
          self.dtype.final_unbox(item) for item in intermed)
      ]
  ```
* Types like jitclass could have second-stage boxers like
  ```python
  def final_unbox(typ, intermed):
      x, y, z = intermed
      # call `final_unbox` on appropriate types for x, y, and z
      x = ... .final_unbox(x)
      ...
      return typ.whatever_the_python_type_is_called()
  ```

The key trick here is we no longer attempt to embed information from `typ` in the C-level unboxer - instead we apply that information as a wrapper on the python side around the outermost jitted function.

---
I haven't fully thought through the ramifications of this idea. I think the main concern would be whether there are places where boxing occurs without re-entry into the python code - perhaps object loops in ufuncs.
user: eric-wieser
labels: discussion: An issue requiring discussion
issue_5829: state: open
title: Incorrect results when working with transposed arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing `list`
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
I am performing a simple multiplication of on array. If I use the jit decorator, the resulting array has an incorrect memory layout or wrong axes(?).  
Expected behavior: Both functions should get the same result

It seems to be related to this issue: https://github.com/numba/numba/issues/4764
I am using Anaconda with Python 3.7.7 and numba 49.1 on Windows 10. 

Minimal example:
<pre>import numpy as np
import numba
test = np.arange(8).reshape(2, 4)
def np_multiply(a):
    a = a.T
    a = a.reshape(2, 2, 2)
    result = a * 2
    return result

numba_multiply = numba.jit(np_multiply)

print(np_multiply(test))
[[[ 0  8]
  [ 2 10]]
 [[ 4 12]
  [ 6 14]]]

print(numba_multiply(test))
[[[ 0  8]
  [ 4 12]]
 [[ 2 10]
  [ 6 14]]]<code>
user: SandroMartens
issue_5822: state: open
title: sort function of typed list is very slow
body: Dear developers,

The sort function of the typed list is almost 10 times slower than that of the reflected list.

```python
import numba as nb

@nb.njit
def mk_typed_list(n):
    x = nb.typed.List()

    for i in range(n):
        x.append(np.random.randint(0, 100))
    return x

X_t = mk_typed_list(10**7)
X = list(X_t)

%prun X_t.sort()
%prun X.sort()
```
Sorting X_t need 23s while sorting X only took 2.3s. 
It seems that access to type lists is 2-3 orders of magnitude slower than reflection lists and bumpy arrays. 

user: Rinoahu
labels: performance: performance related issue
issue_5813: state: open
title: feature request for np.mgrid
body: Hi!

I am trying to use numba on below piece of code, that generates gaussian kernel:

```
import numpy as np
import numba
from numba import jit

@jit(nopython=False)
def gaussian(r,c,sigma): 
    x, y = np.mgrid[-(r-1)/2:(r-1)/2+1,-(c-1)/2:(c-1)/2+1]
    gauss = (1/(2*np.pi*sigma**2))*np.exp(-(x**2+y**2)/(2*sigma))
    return gauss

gaussian(9,10,15)
```

Then, found out numba does not support mgrid (correct?), so changes the code to:

```
@jit(nopython=True)
def gaussian(r,c,sigma): 
    xvals = np.arange(-(r-1)/2,(r-1)/2+1,1)
    yvals = np.arange(-(c-1)/2,(c-1)/2+1,1)
    xx = np.asarray([[x for y in yvals] for x in xvals])
    yy = np.asarray([yvals for x in xvals])
    gauss = (1/(2*np.pi*sigma**2))*np.exp(-(xx**2+yy**2)/(2*sigma))
    return gauss
```

now, I am getting errors hinting numba fails creating np array from list:

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
[1m[1m[1mInvalid use of Function(<built-in function array>) with argument(s) of type(s): (list(array(float64, 1d, C)))

This error is usually caused by passing an argument of a type that is unsupported by the named function.[0m[0m
[0m[1m[1] During: resolving callee type: Function(<function asarray at 0x000001CCF684B948>)[0m
[0m[1m[2] During: typing of call at test.py (30)
```

Any help to resolve the issue including edit suggestion would be much appreciated. Also is there any work underway to include mgrid support, this could be really helpful in computer vision applications.

Cheers,
Mike
user: mmohseni91
issue_5809: state: open
title: Dangerous default arguments in numba
body: While reading the numba source code I noticed that dangerous default arguments are used in several places.

When defining a function like
```python
def f(arg={}):
    pass
```
the default argument is created during the definition of the function, not during the call.

That means that all calls which fall to the default argument share the same instance of that dictionary (list, etc..)

This can easily have "funny" side effects, as shown in the following (somewhat contrived) example
```python
from numba import njit, int32

@njit
def f(x):
    c = 0.5
    return c+x
print(f(1))

f.locals["c"] = int32

@njit
def g(x):
    c = 0.5
    return c+x
print(g(1))
print(g.locals)
```
returns
```
1.5
1
{'c': int32}
```
This happens because `f` and `g` end up sharing the same instance of `locals` (the jit decorator is defined as `def jit([...], locals={})`).
user: HPLegion
labels: good first issue: A good issue for a first time contributor
issue_5801: state: open
title: Type unification problem of integer temp variables in a parfor loop
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Hi,

I found an example when getitem implementation for a new extension type (pandas.RangeIndex) cannot be compiled in a parfor loop, if getitem result is used as a key in a typed.Dict lookup operation.

The reason for the problem is likely unsafe numpy-like type unification rules in Number.unify() that unify two variables (temporary phi variables from different branches inside a loop) of types int64, uint64 to float64, affecting result type of getitem operation and finally causing failure since this result is used as a key in typed.Dict with integer domain key_type. Below is a test that can reproduce the problem:

```
import numba
from numba import types
from numba.extending import overload

import unittest
import numpy as np

class TestSuite(unittest.TestCase):

    def test_reproducer1(self):

        def range_getitem(start, stop, step, idx):
            pass

        @overload(range_getitem)
        def range_getitem_ovld(start, stop, step, idx):
            if not (isinstance(idx, types.Integer)
                    and isinstance(start, types.Number)
                    and isinstance(stop, types.Number)
                    and isinstance(step, types.Number)):
                return

            def range_getitem_impl(start, stop, step, idx):
                range_len = len(range(start, stop, step))

                # this line causes type unification problem between int64 (range_len + idx) and uint64 (idx)             
                idx = (range_len + idx) if idx < 0 else idx
                return start + step * idx                   # with this line it fails
                # return start + step * types.int64(idx)    # this can be a workaround
            return range_getitem_impl

        @numba.njit(parallel=True)
        def test_impl(n, values, start, stop, step):
            values_dict = {}
            for x in values:
                values_dict[x] = True

            res = np.empty(n, dtype=types.bool_)
            for i in numba.prange(n):
                res[i] = range_getitem(start, stop, step, i) in values_dict
            return res

        start, stop, step = 1, 10, 2
        range_len = len(range(start, stop, step))
        values = np.asarray([1, 3, 4, 2, 9], dtype=np.int64)
        print(test_impl(range_len, values, start, stop, step))


if __name__ == "__main__":
    unittest.main()
```

And here's the IR of range_getitem_impl and typevars dict after constraints propagation is finished:
```
label 0:
    start = arg(0, name=start)               ['start']
    stop = arg(1, name=stop)                 ['stop']
    step = arg(2, name=step)                 ['step']
    idx = arg(3, name=idx)                   ['idx']
    $2load_global.0 = global(len: <built-in function len>) ['$2load_global.0']
    $4load_global.1 = global(range: <class 'range'>) ['$4load_global.1']
    $12call_function.5 = call $4load_global.1(start, stop, step, func=$4load_global.1, args=[Var(start, example_test.py:24), Var(stop, example_test.py:24), Var(step, example_test.py:24)], kws=(), vararg=None) ['$12call_function.5', '$4load_global.1', 'start', 'step', 'stop']
    $14call_function.6 = call $2load_global.0($12call_function.5, func=$2load_global.0, args=[Var($12call_function.5, example_test.py:24)], kws=(), vararg=None) ['$12call_function.5', '$14call_function.6', '$2load_global.0']
    range_len = $14call_function.6           ['$14call_function.6', 'range_len']
    $const20.8 = const(int, 0)               ['$const20.8']
    $22compare_op.9 = idx < $const20.8       ['$22compare_op.9', '$const20.8', 'idx']
    bool24 = global(bool: <class 'bool'>)    ['bool24']
    $24pred = call bool24($22compare_op.9, func=bool24, args=(Var($22compare_op.9, example_test.py:29),), kws=(), vararg=None) ['$22compare_op.9', '$24pred', 'bool24']
    branch $24pred, 26, 34                   ['$24pred']
label 26:
    $30binary_add.2 = range_len + idx        ['$30binary_add.2', 'idx', 'range_len']
    $phi36.0 = $30binary_add.2               ['$30binary_add.2', '$phi36.0']        # this will be typed as int64
    jump 36                                  []
label 34:
    $phi36.0.1 = idx                         ['$phi36.0.1', 'idx']                # this will be typed uint64 (same as arg.idx)
    jump 36                                  []
label 36:
    $phi36.0.2 = phi(incoming_values=[Var($phi36.0, example_test.py:29), Var($phi36.0.1, example_test.py:29)], incoming_blocks=[26, 34]) ['$phi36.0', '$phi36.0.1', '$phi36.0.2']    # this will unify types for $phi36.0 and $phi36.0.1
    idx.1 = $phi36.0.2                       ['$phi36.0.2', 'idx.1']
    $44binary_multiply.4 = step * idx.1      ['$44binary_multiply.4', 'idx.1', 'step']
    $46binary_add.5 = start + $44binary_multiply.4 ['$44binary_multiply.4', '$46binary_add.5', 'start']
    $48return_value.6 = cast(value=$46binary_add.5) ['$46binary_add.5', '$48return_value.6']
    return $48return_value.6                 ['$48return_value.6']
```
```
[Current context]: File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\typed_passes.py", line 71, in type_inference_stage
>>> infer.typevars
{'arg.start': arg.start := int64
'arg.stop': arg.stop := int64
'arg.step': arg.step := int64
'arg.idx': arg.idx := uint64
'$2load_global.0': $2load_global.0 := Function(<built-in function len>)
'$4load_global.1': $4load_global.1 := Function(<class 'range'>)
'$const20.8': $const20.8 := Literal[int](0)
'bool24': bool24 := Function(<class 'bool'>)
'start': start := int64
'stop': stop := int64
'step': step := int64
'idx': idx := uint64
'$12call_function.5': $12call_function.5 := range_state_int64
'$14call_function.6': $14call_function.6 := int64
'range_len': range_len := int64
'$22compare_op.9': $22compare_op.9 := bool
'$24pred': $24pred := bool
'$30binary_add.2': $30binary_add.2 := int64
'$phi36.0': $phi36.0 := int64
'$phi36.0.1': $phi36.0.1 := uint64
'$phi36.0.2': $phi36.0.2 := float64
'idx.1': idx.1 := float64
'$44binary_multiply.4': $44binary_multiply.4 := float64
'$46binary_add.5': $46binary_add.5 := float64
'$48return_value.6': $48return_value.6 := float64}
```

The error is following:
```
======================================================================
ERROR: test_reproducer1 (__main__.TestSuite)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "example_test.py", line 48, in test_reproducer1
    print(test_impl(range_len, values, start, stop, step))
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\num
ba\core\dispatcher.py", line 415, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\num
ba\core\dispatcher.py", line 358, in error_rewrite
    reraise(type(e), e, None)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\num
ba\core\utils.py", line 80, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython m
ode backend)
Failed in nopython mode pipeline (step: nopython frontend)
No implementation of function Function(<built-in function contains>) found for si
gnature:

 >>> contains(DictType[int64,bool], float64)

There are 14 candidate implementations:
  - Of which 12 did not match due to:
  Overload in function 'contains': File: <built-in>: Line <N/A>.
    With argument(s): '(DictType[int64,bool], float64)':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'contains': File: <built-in>: Line <N/A>.
    With argument(s): '(DictType[int64,bool], float64)':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<intrinsic _cast>) found for signature:


    >>> <unknown function>(float64, class(int64))

   There are 2 candidate implementations:
     - Of which 2 did not match due to:
     Overload in function '_cast': File: numba\typed\typedobjectutils.py: Line 23
.
       With argument(s): '(float64, class(int64))':
      Rejected as the implementation raised a specific error:
        TypingError: cannot safely cast float64 to int64. Please cast explicitly.

     raised from C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\
numba\numba\typed\typedobjectutils.py:73

   During: resolving callee type: Function(<intrinsic _cast>)
   During: typing of call at C:\Users\akozlov\AppData\Local\Continuum\anaconda3\n
umba_master\numba\numba\typed\dictobject.py (807)


   File "numba\typed\dictobject.py", line 807:
       def impl(d, k):
           k = _cast(k, keyty)
           ^

  raised from C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\num
ba\numba\core\typeinfer.py:994

During: typing of intrinsic-call at example_test.py (42)

File "example_test.py", line 42:
        def test_impl(n, values, start, stop, step):
            <source elided>
            for i in numba.prange(n):
                res[i] = range_getitem(start, stop, step, i) in values_dict
                ^

During: lowering "id=0[LoopNest(index_variable = parfor_index.3, range = (0, n, 1
))]{52: <ir.Block at example_test.py (41)>}Var(parfor_index.3, example_test.py:41
)" at example_test.py (41)
```

I verified problem is still applicable on master: 0.50.0.dev0+378.g079a70274


Best Regards,
Alexey.
user: kozlov-alexey
issue_5799: state: open
title: Meta-class destructor is not called on exit
body: ## Reporting a bug
* As stated in the title, meta-class destructors (`__del__` on a meta-class instance) are not called on exit when using `njit`-ed functions. In the example below, `Test class deleted` is not printed after the script exits. The problem goes away with any of the following changes:
    * Removing `njit` decorator from `njit`-ed function.
    * Passing a scalar to `njit`-ed function (e.g calling `jitted(1)` instead of `jitted(x)`)
* Strangely, the issue also happens even if you pass a scalar to the function but define a `numba.typed.List` with tuple elements (shown in the commented sample).
* The class destructor (`__del__` on a class instance) is called (not shown in the sample code).

I don't understand well what could be happening, but I'm guessing the issue lies somewhere around the use of `numba.typed.List` ?

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (0.49.1).
- [x] I have included below a minimal working reproducer.

Environment:
* numba 0.49.1
* python 3.7.2

```python
import numba
# bug: meta-class destructor is not called on exit
#   (in this example, "Test class deleted" is not printed)
#
# The problem goes away with any of the following changes:
#    * removing njit decorator from jitted()
#    * Passing a scalar to jitted (e.g. calling jitted(1) instead of jitted(x))


@numba.njit
def jitted(x):
    return x


class deltype(type):
    def __del__(self):
        print(f"{self.__name__} class deleted")


Test = deltype("Test", (object,), {})

x = numba.typed.List()
for i in range(10):
    x.append(123)
jitted(x)

# Strangely, this also reproduces the issue:
# x = numba.typed.List()
# for i in range(10):
#     x.append(tuple(float(i) for i in range(3)))
# jitted(1)  # note that x is never actually used
```
user: alegonz
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_5792: state: open
title: Not work  jit_options={'error_model': 'numpy'}
body: jit_options={'error_model': 'numpy'} work in @njit and @overload, but not work in overload_method.

numba=0.49.0

```python
import numba
from numba import cgutils, types
from numba.extending import (intrinsic, make_attribute_wrapper, models,
                             overload_method, overload, register_model)
from numba.typing import signature


def divide(a, b):
    pass


@overload(divide, jit_options={'error_model': 'numpy'})
def divide_overload(a, b):
    def _impl(a, b):
        return a / b
    return _impl


@numba.njit(nopython=True)
def test_divide(a, b):
    return divide(a, b)


print("TEST1: ", test_divide(1, 0))


class Dummy:
    def __init__(self, data):
        self.data = data

    def div(self, other):
        return data / other.data


class DummyType(types.Type):
    def __init__(self, data):
        self.data = data
        super().__init__(name=f'Dummy({self.data})')


@register_model(DummyType)
class DummyTypeModel(models.StructModel):
    def __init__(self, dmm, fe_type):
        members = [
            ('data', fe_type.data),
        ]
        super().__init__(dmm, fe_type, members)


make_attribute_wrapper(DummyType, 'data', '_data')


@intrinsic
def init_dummy(typingctx, data):
    def codegen(context, builder, sig, args):
        typ = sig.return_type
        data, = args
        dummy = cgutils.create_struct_proxy(typ)(context, builder)
        dummy.data = data

        if context.enable_nrt:
            context.nrt.incref(builder, sig.args[0], data)

        return dummy._getvalue()

    ret_typ = DummyType(data)
    sig = signature(ret_typ, data)

    return sig, codegen


@overload(Dummy, inline='always')
def dummy_overload(data):
    def ctor(data):
        return init_dummy(data)

    return ctor


@overload_method(DummyType, 'div', inline='always', jit_options={'error_model': 'numpy'})
def div_overload(self, other):
    def impl(self, other):
        return self._data / other._data

    return impl


@numba.njit(parallel=True)
def test_impl(data, other_data):
    dummy = Dummy(data)
    other = Dummy(other_data)

    return dummy.div(other)


data = 1
other_data = 0
res = test_impl(data, other_data)
print("TEST2: ", res)
```


**_Output:_**
TEST1:  inf

Traceback (most recent call last):
  File "repr.py", line 98, in <module>
    res = test_impl(data, other_data)
ZeroDivisionError: division by zero

user: Rubtsowa
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_5790: state: open
title: Support for EMM context managers
body: From @jakirkham:

> How complex would it be to have a context manager in EMM, `using_memory_manager`, analogous to `using_allocator` in CuPy? https://docs-cupy.chainer.org/en/stable/reference/generated/cupy.cuda.using_allocator.html

> There has been some discussion about different allocators RMM supplies. So if we exposed this to Python, it may be handy to switch to a faster/more optimized allocator for blocks with optimized Numba kernels (if that makes sense)

> Priority: medium

I think this is a possibility - I'd need to experiment a bit to work out if there are any gotchas to get a good idea of how complex it would be.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_5789: state: open
title: support for np.putmask
body: This is a small PR that adds support for np.putmask. I believe it reproduces numpy's behavior. [WIP] is mostly for Travis CI and a question since this is my first PR: I put it in ``numba/np/arraymath.py`` with the element-wise operations (It felt similar to np.where). Is there a better spot for it? Thanks

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
mailing list https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: arthurfeeney
issue_5785: state: open
title: Implement np.tile
body: Add basic support for np.tile, limited to when the first input (the tiles) have at most 1 dimension. Includes documentation and tests.

I'd like to support higher-dimensional inputs, but I spent a while trying to figure out how to dynamically allocate a new tuple at runtime for the output shape with little success (the number of dimensions needs to be equal to `max(len(reps), a.ndim)`. It seems like the only option is `context.make_tuple` using the `lower_builtin` API, but that didn't seem like a great idea. A possible workaround is using a list/array for the shape, but unfortunately that's not yet supported by `np.reshape` or `array.reshape`.

Fixes #2327
Fixes #3456

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
mailing list https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: AndrewEckart
issue_5784: state: open
title: missing lowering for static_setitem with slice on char array 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

This works:
```
from numba import njit
import numpy as np

values_dtype = np.dtype([
    ('one', 'U10'),
    ('two', 'f8')
])


def my_test():
    values = np.zeros(2, dtype=values_dtype)
    values['two'][:] = 1.234
    values['one'][:] = 'test'
    return values
result = my_test()
print(result)
```

But when jitting the function, it throws an error:
```
from numba import njit
import numpy as np

values_dtype = np.dtype([
    ('one', 'U10'),
    ('two', 'f8')
])

@njit
def my_test():
    values = np.zeros(2, dtype=values_dtype)
    values['two'][:] = 1.234
    values['one'][:] = 'test'
    return values
result = my_test()
print(result)
```
`NotImplementedError: No definition for lowering static_setitem(unaligned array([unichr x 10], 1d, A), slice, [unichr x 10]) -> none`

Note that setting a column equal to a float works as expected, but when setting a string it doesn't.

Thanks

numba: 0.49.1
numpy: 1.18.4
python: 3.7.1

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: marnixhoh
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_5780: state: open
title: Setting a datetime value on a Numpy structured array throws an error
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

This works:
```
from numba import njit
import numpy as np

values_dtype = np.dtype([
    ('one', 'U10'),
    ('two', 'f8'),
    ('three', 'M8[us]'),
])


def my_test():
    values = np.empty(2, dtype=values_dtype)
    values['three'][:] = np.datetime64('2005-02-25')
    return values
result = my_test()
print(result)
```

But when jitting it, it throws an error:

```
from numba import njit
import numpy as np

values_dtype = np.dtype([
    ('one', 'U10'),
    ('two', 'f8'),
    ('three', 'M8[us]'),
])

@njit
def my_test():
    values = np.empty(2, dtype=values_dtype)
    values['three'][:] = np.datetime64('2005-02-25')
    return values
result = my_test()
print(result)
```
`Invalid use of Function() with argument(s) of type(s): (unaligned array(datetime64[us], 1d, A), slice, datetime64[])`

Any suggestions for a workaround are highly appreciated!

Thanks

numba: 0.49.1
numpy: 1.18.4
python: 3.7.1
<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: marnixhoh
issue_5777: state: open
title: Printing a Numpy structured array containing a string column throws an error
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

This works:

```
from numba import njit
import numpy as np

values_dtype = np.dtype([
    ('one', 'U10'),
    ('two', 'f8')
])

def my_test():
    values = np.empty(2, dtype=values_dtype)
    values['one'][0] = 'test'
    print(values['one'][0])
    return values
result = my_test()
print(result)
```

But when jitting the function, it doesn't:

```
from numba import njit
import numpy as np

values_dtype = np.dtype([
    ('one', 'U10'),
    ('two', 'f8')
])

@njit
def my_test():
    values = np.empty(2, dtype=values_dtype)
    values['one'][0] = 'test'
    print(values['one'][0])
    return values
result = my_test()
print(result)
```

Note that the error is thrown by the `print` statement:
`UnicodeDecodeError: 'utf-32-le' codec can't decode bytes in position 0-3: code point not in range(0x110000)`


numba: 0.49.1
numpy: 1.18.4
python: 3.7.1

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: marnixhoh
issue_5775: state: open
title: Additional work needed on the new inliner
body: https://github.com/numba/numba/pull/5673 implements a new inliner in an attempt to abstract out the interface more cleanly in comparison to the original, which, with time has evolved to become overly complicated and hard to verify. In addition to the changes in #5673 it'd be a good idea to also add back in the methods removed in this patch: https://github.com/numba/numba/pull/5673/commits/bc5fcd1a4b921c11f68e0a55fee9d3d644842d54, namely:

* `InlineWorker::inline_closure` - helps with inlining a closure
* `InlineWorker::convert_code_object_to_function` - this might need renaming, it actually extracts the `__code__` and `__closure__` from a closure and creates a function with the same body as the closure but binds the freevars/cell etc as local vars.

It'd also be useful to add to the `InlineWorker` class, or even just pull out into another class, the ability to do the recursive inlining behaviour that appears in numerous places in the code base, for example here:
https://github.com/numba/numba/blob/70f7b687bf7bc25a025a71aed5d74551f380fa5a/numba/core/inline_closurecall.py#L79-L101
and here:
https://github.com/numba/numba/blob/70f7b687bf7bc25a025a71aed5d74551f380fa5a/numba/core/typed_passes.py#L493-L511

There's the start of some of this work here: https://github.com/stuartarchibald/numba/commits/fix/5476_5_cont
user: stuartarchibald
issue_5770: state: open
title: List populated during multiple loops does not convert to array correctly. 
body: I am not sure if this is intended behaviour or if there is some obvious pitfall that I am missing but when I create a function where values are appended to a list in more than one loop and this list is converted to an array, only the values appended  during the last loop get returned. Here is what I expect: 

```python
def foo():
    result = []
    for i in range(5):
        result.append(i)
    for j in range(5,10):
        result.append(j)
    return np.array(result)
```
```python
>>>foo()
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
```
but when I define the function with `@jit(cache=True, nopython=True)` I get this result:
```python
>>>foo()
array([5, 6, 7, 8, 9])
```
In the case where I return the list without converting to an array the full list of values is returned as expected. Strangely, if I print the list before converting to an array, the full array is also returned. 

I am on numba 0.49.1, numpy 1.18.1 and Python 3.8.1.

user: exe0cdc
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_5769: state: open
title: Compiler explorer for Numba
body: The compiler explorer (see https://godbolt.org/) provides a very useful functionality
for C++ users. We can see what the C++ (but also Rust, Go and many other) is going
to be in the assembly.

Could we have a similar functionality for NUMBA? We could show up the assembly
but also maybe the NUMBA IR or any other information.

That would help everyone have a better understanding of what NUMBA can do.

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: MathieuDutSik
issue_5766: state: open
title: PyPy support
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request
As title. According to  scikit-learn/scikit-learn#17364, scikit-learn (and PyData/Sparse) cannot support PyPy because Numba doesn't support it. Are there plans to support PyPy, and if not, are there reasons behind it?

I realize this may be a big undertaking as Numba operates on Python bytecode and I assume that bytecode is different with PyPy.

user: hameerabbasi
issue_5762: state: open
title: Adding get_memory_manager
body: ## Feature request

Currently Numba supplies [`set_memory_manager`]( http://numba.pydata.org/numba-doc/latest/cuda/external-memory.html#numba.cuda.set_memory_manager ), which allows the user to swap in an external memory manage for Numba. It would be useful to have a `get_memory_manager` to access the underlying memory manager.
user: jakirkham
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_5760: state: open
title: literal_unroll: allow setitem in loop; also allow zip, enumerate, et al. w/ literal_unroll?
body: ## Feature request

In the end, it would be nice to be able to dynamically assign values arbitrary fields of a struct in a structured array (records array / record array). See, e.g., issue #5756. Another way to solve this problem is hinted at in the docs, where `literal_unroll` is used to unpack field names in  a struct array, but this only works for `getitem` while it fails for `setitem`. E.g., one could imagine an alternate code to what @marnixhoh would read as:

```python
from numba import njit, literal_unroll
import numpy as np

struct_dtype = np.dtype([
    ('one', np.float64),
    ('two', np.float64)])

columns = struct_dtype.names  # note: tuple, so legal to use w/ literal_unroll

@njit
def my_test():
    struct_array = np.empty((2, 1), dtype=struct_dtype)
    for column in literal_unroll(columns):
        struct_array[column][0] = 1234
    return struct_array

result = my_test()
print(result)
```

This currently fails, with
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function getitem>) with argument(s) of type(s): (unaligned array(Record(one[type=float64;offset=0],two[type=float64;offset=8];16;False), 2d, C), Literal[str](one))
```

It would further help to make code more dynamic and concise (and avoid ugly code-generation type solutions) if that could be encapsulated in the function itself:

```python
@njit
def my_test():
    struct_array = np.empty((2, 1), dtype=struct_dtype)
    for column in literal_unroll(struct_dtype.names):
        struct_array[column][0] = 1234
    return struct_array
```

One common issue I have is populating a structured array's fields with individual values that come from outside such a structured array (i.e., not with the structured array's same dtype). This is solve-able in plain python/numpy via

```python
import numpy as np

struct_dtype = np.dtype([
    ('one', np.float64),
    ('two', np.float64)])

def my_test():
    struct_array = np.empty((2, 1), dtype=struct_dtype)
    values = (0, 1)  # e.g., values = get_from_another_func()
    for column, val in zip(struct_dtype.names, values):
        struct_array[column][0] = val
    return struct_array

result = my_test()
print(result)
```

and might look like the following, using `zip` with `literal_unroll` to make it concise in Numba:

```python
from numba import njit, literal_unroll
import numpy as np

struct_dtype = np.dtype([
    ('one', np.float64),
    ('two', np.float64)])

@njit
def my_test():
    struct_array = np.empty((2, 1), dtype=struct_dtype)
    values = (0, 1)  # e.g., values = get_from_another_func()
    for column, val in zip(literal_unroll(struct_dtype.names), values):
        struct_array[column][0] = val
    return struct_array

result = my_test()
print(result)
```

Using `zip` can be avoided via a counter that is manually incremented in the loop, but this is more error-prone, takes more lines of code, and is less Pythonic.

One "basic but practical" use case that has arisen for me is selectively copying particular values from one array to another. The following pure Python/numpy example works as desired:

```python
import numpy as np
from numba import njit, literal_unroll

def select_and_populate(input_array, output_array, x_thresh):
    for input_row, output_row in zip(input_array, output_array):
        if input_row['x'] >= x_thresh:
            for field in ('x', 'z'):
                output_row[field] = input_row[field]

dtype = np.dtype([('x', np.float32), ('y', np.float32), ('z', np.float32)])

input_array = np.ones(10, dtype=dtype)
input_array["x"] = np.arange(10)

output_array = np.zeros(10, dtype=dtype)

select_and_populate(input_array, output_array, x_thresh=5)
print(output_array)
```

while something analogous with `literal_unroll` might look like:

```python
import numpy as np
from numba import njit, literal_unroll

@njit
def select_and_populate(input_array, output_array, x_thresh):
    for input_row, output_row in zip(input_array, output_array):
        if input_row['x'] >= x_thresh:
            for field in literal_unroll(('x', 'z')):
                output_row[field] = input_row[field]

dtype = np.dtype([('x', np.float32), ('y', np.float32), ('z', np.float32)])

input_array = np.ones(10, dtype=dtype)
input_array["x"] = np.arange(10)

output_array = np.zeros(10, dtype=dtype)

select_and_populate(input_array, output_array, x_thresh=5)
print(output_array)
```

Obviously that is simple to solve in advance with an extra line of code writing values to specific field names, but being able to more dynamically define which field names are assigned to and not having to write 100 lines of code to assign to 100 fields is where a fix to this becomes a "big deal."
user: jllanfranchi
labels: discussion: An issue requiring discussion
issue_5755: state: open
title: @vectorize-decorated functions are not found by sphinx
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I use `sphinx` with the `apidoc` extension to have a reference documentation generated automatically.
For functions decorated with `njit` this works without any complications, for `vectorize` however, the function disappears from the docs, indicating that apidoc either cannot find it or decides not to include it. (Sorry for the lack of better info).

Since this is sphinx related I am not sure how to include a minimal example, but if it would help and I find some time I can try to set up a mini-repository.

user: HPLegion
labels: good second issue: A good issue for second time contributors
issue_5754: state: open
title: Using shared memory in Numba with Cupy functions 
body: ##  Feature request

I tried to execute a Cupy function with shared memory arrays and cuda.jit, but it seems it is not possible at the moment. Currently, I need to write numpy/cupy functions by myself if I want to use shared memory arrays.

user: Mitko88
labels: CUDA: CUDA related issue/PR
issue_5753: state: open
title: Declaring Numpy structured array dtypes throws TypeError
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->
This works fine:
```
def my_test():
    struct_dtype = np.dtype([
        ('one', np.float64),
        ('two', np.float64)])
    struct_array = np.array([
        (1.0, 1.1),
        (2.0, 2.1)
    ], dtype=struct_dtype)
    return struct_array


result = my_test()
print(result)
```

But when jitting it:
```
@njit
def my_test():
    struct_dtype = np.dtype([
        ('one', np.float64),
        ('two', np.float64)])
    struct_array = np.array([
        (1.0, 1.1),
        (2.0, 2.1)
    ], dtype=struct_dtype)
    return struct_array


result = my_test()
print(result)
```

A TypeError is thrown:
`TypeError: unknown dtype descriptor: list(Tuple(unicode_type, class(float64)))`

numba: 0.49.1
numpy: 1.18.4
python: 3.7.1
<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: marnixhoh
issue_5750: state: open
title: meta discussion: jitclass inferred constructor 
body: This is a discussion thread for exploring ideas for inferred contructor for jitclass.

Thus, making the following code or variant of the following possible:


```python
@numba.jitclass   # no need for type spec.
class Shrubbery:
    def __init__(self, x, y):
        self.x = x
        self.y = y
```

To help start the discussion, it seems likely that we can `@overload(Shrubbery)` as a callable to make it return a specialized version of `Shrubbery` instances. For instance, the typing logic in the `overload` can be analyzing the type needed for attributes `x` and `y`.

Another possibility is to require a special method to help with typing, something that is like `__new__()`:

```python
@numba.jitclass
class Herring:
    def __infer__(cls : numba.types.Type, x: numba.types.Type, y: numba.types.Type):
        return specialize_herring_type_for(x, y) # -> Herring type instance

    def __init__(self, x, y):
        ...
```
user: sklam
labels: discussion: An issue requiring discussion
issue_5749: state: open
title: Using Exceptions to trigger continue in loops fails
body: using the latest version (v0.49.1), would expect this to work without an error - it's not particularly urgent though
```
from numba import njit
import numpy as np
a=np.arange(10)
@njit
def foo(a):
         for _ in a:
            try:
               raise Exception
            except Exception:
               continue
 foo(a)     
```         
Traceback (most recent call last):
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\IPython\core\interactiveshell.py", line 3331, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-5-e48c672f35a5>", line 11, in <module>
    foo(a)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\dispatcher.py", line 404, in _compile_for_args
    error_rewrite(e, 'unsupported_error')
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\dispatcher.py", line 342, in error_rewrite
    raise e
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\dispatcher.py", line 794, in compile
    cres = self._compiler.compile(args, return_type)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler.py", line 568, in compile_extra
    return pipeline.compile_extra(func)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler.py", line 339, in compile_extra
    return self._compile_bytecode()
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler.py", line 401, in _compile_bytecode
    return self._compile_core()
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler.py", line 381, in _compile_core
    raise e
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler.py", line 372, in _compile_core
    pm.run(self.state)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler_machinery.py", line 341, in run
    raise patched_exception
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler_machinery.py", line 332, in run
    self._runPass(idx, pass_inst, state)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler_machinery.py", line 291, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\compiler_machinery.py", line 264, in check
    mangled = func(compiler_state)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\untyped_passes.py", line 86, in run_pass
    func_ir = interp.interpret(bc)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\interpreter.py", line 116, in interpret
    flow.run()
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\byteflow.py", line 107, in run
    runner.dispatch(state)
  File "C:\Workdir\Programs\Anaconda2\envs\LTM\lib\site-packages\numba\core\byteflow.py", line 269, in dispatch
    raise UnsupportedError(msg, loc=self.get_debug_loc(inst.lineno))
numba.core.errors.UnsupportedError: Failed in nopython mode pipeline (step: analyzing bytecode)
Use of unsupported opcode (CONTINUE_LOOP) found
File "<ipython-input-5-e48c672f35a5>", line 10:
def foo(a):
    <source elided>
            except Exception:
                continue
                ^
Unsupported functionality was found in the code Numba was trying to compile.
If this functionality is important to you please file a feature request at:
https://github.com/numba/numba/issues/new
<!--


user: p-ortmann
issue_5747: state: open
title: Check if variable is None inside njitted function is neither True nor False with parallel=True
body: * [x]  I am using the latest released version of Numba (most recent is visible in
  the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
* [x]  I have included below a minimal working reproducer (if you are unsure how
  to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This problem is new in v0.49.x. It only occurs when using `parallel=True`.

I have two functions `test` and `test2` that are identical except for that `test` checks `if weight is not None` and `test2` checks `if weight is None`. 

`test` produces the correct result, i.e. it sums up the weights (=2.5). `test2` thinks that `weight is not None` is neither `True` nor `False` and returns 0.

```python
import numpy as np
from numba import njit, prange

@njit(parallel=True)
def test(y, weights):
    sum_weights = 0.0
    if weights is not None:
        for i in prange(len(y)):
            sum_weights += weights[i]
    else:
        for i in prange(len(y)):
            sum_weights += 1.0

    return sum_weights

@njit(parallel=True)  # `parallel=False` works!
def test2(y, weights):
    sum_weights = 0.0
    if weights is None:  # `if False:` works!
        for i in prange(len(y)):
            sum_weights += 1.0
    else:
    	for i in prange(len(y)):
            sum_weights += weights[i]

    return sum_weights

y = np.array([0.4] * 5)
weights = np.array([0.5] * 5)

print(test(y, weights))  # 2.5
print(test2(y, weights))  # 0.0
```

### Environments
I'm running this on Linux with the conda-forge versions of numba and numpy.
```
conda create -y -c conda-forge -n numba0490 numba=0.49.0
conda create -y -c conda-forge -n numba0491 numba=0.49.1
conda create -y -c conda-forge -n numba0480 numba=0.48.0
```
user: jtilly
labels: SSA: Problem due to SSA (or lack of)
bug - incorrect behavior: Bugs: incorrect behavior
issue_5742: state: open
title: Runtime measurements
body: Given the difficulties in having full support for cProfile and other similar tools, would it be possible to add some form of explicitly measuring the time spent on a portion of numba njit code? Something like a with block that measures the time spent inside it and reports it somewhere after the program is finished, or even native support for python's time modules so that it can be implemented by developers.

with numba.TimeIt("name"):
   ...


user: FilipeArcanjo
issue_5739: state: open
title: Bug using += (Add AND) with matrix transpose
body: I am using numba version '0.48.0'

Adding the transpose of a matrix to itself with += does not give the correct results, unless the matrix is explicitly copied first.

Example:
```
import numpy as np
from numba import njit

@njit
def add_and_transpose(x):
    y = x.copy()
    y += y.T
    return y

@njit
def add_and_transpose_copy(x):
    y = x.copy()
    y += y.T.copy()
    return y

x = np.arange(16).reshape((4,4))
print('using +=')
print( add_and_transpose(x) )

print('using += with copy')
print( add_and_transpose_copy(x) )
```

gives me
```
using +=
[[ 0  5 10 15]
 [ 9 10 15 20]
 [18 24 20 25]
 [27 33 39 30]]
using += with copy
[[ 0  5 10 15]
 [ 5 10 15 20]
 [10 15 20 25]
 [15 20 25 30]]
'''

user: walkerdray
issue_5735: state: open
title: failure to use Prange with @njit(parallel=True) on loop which can be parallelised
body: I am using a function func1 which is as follows :-

```
def func1(k, indexes, child0, child1, T_node, T_child0, T_child1, B_child0, B_child1):
    R_min, R_max = np.maximum(1, indexes-T_child0), np.minimum(T_child1, indexes-1)
    B_ret, R_ret = np.zeros((min(k, T_node)-1,)), np.zeros((min(k, T_node)-1,), dtype=np.int32)
    
    for i in prange(2, min(k, T_node)+1):

        B_right = B_child1[R_min[i-2]-1:R_max[i-2]]
        B_left = B_child0[i-R_max[i-2]-1:i-R_min[i-2]]
        B_left = B_left[::-1]

        B_node = B_right+B_left

        R_ret[i-2] = R_min[i-2]+np.argmax(B_node)
        B_ret[i-2] = B_node[R_ret[i-2]-R_min[i-2]]
        
    return B_ret, R_ret
```
The for loop can be parallelised and has no inter dependencies.
To compile this function, and to use a Numba  function for the same, I write 
```
numba_func = jit(nopython=True, parallel=True)(func1)
```
I call this numba_func inside another function. I am getting an error running this code as follows
```
TypeError: Failed in nopython mode pipeline (step: convert to parfors)
object of type 'NoneType' has no len()
```
Please suggest changes to fix this
user: ritvik06
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_5731: state: open
title: Bug? Variable np.searchsorted side argument
body: - [x] I am using the latest released version of Numba (0.49.1, current asof May 7, 2020)
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

The following works:
```python
def ixof(arr, val, closed=False):
    if closed:
        return np.searchsorted(arr, val, "left")
    else:
        return np.searchsorted(arr, val, "right")

ixof(np.arange(100), 10) # returns 11
njit(ixof)(np.arange(100), 10) # returns 11
```

The following fails:
```python
def ixof(arr, val, closed=False):
    side = "left" if closed else "right"
    return np.searchsorted(arr, val, side)

ixof(np.arange(100), 10) # returns 11
njit(ixof)(np.arange(100), 10) # error
```

With error:
```TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<function searchsorted at 0x7fc32c79b550>) with argument(s) of type(s): (array(int64, 1d, C), int64, unicode_type)
 * parameterized
In definition 0:
    ValueError: Invalid value given for 'side': unicode_type
    raised from /home/mtartre/.miniconda/envs/scratch/lib/python3.8/site-packages/numba/np/arraymath.py:3375
In definition 1:
    ValueError: Invalid value given for 'side': unicode_type
    raised from /home/mtartre/.miniconda/envs/scratch/lib/python3.8/site-packages/numba/np/arraymath.py:3375
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<function searchsorted at 0x7fc32c79b550>)
[2] During: typing of call at <ipython-input-17-29612a757df6> (3)


File "<ipython-input-17-29612a757df6>", line 3:
def ixof(arr, val, closed=False):
    <source elided>
    side = "left" if closed else "right"
    return np.searchsorted(arr, val, side)
    ^
```

My reading of the current implementation (https://github.com/numba/numba/blob/master/numba/np/arraymath.py#L3368) is that this might only work if the variable is defined at compile time? The above is a fine fix for me for now, but it seems considerably less than ideal.

Related PR: https://github.com/numba/numba/pull/2821
user: quantology
labels: good second issue: A good issue for second time contributors
issue_5728: state: open
title: Var error in parfors step
body: ## Reporting a bug
- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This bug has been confirmed in both 0.49.1 and 0.50.0 dev (b3d09ff64367e3b002c606789496b82023de59e9).

```python
import numpy as np
import numba as nb
from numba import stencil, njit, prange

@njit("intc(uint8[:], uint8[:])", parallel=True)
def search_sequence2(arr,seq):
    def search_kernel(x, y):
        for i in prange(x.size):
            if x[i] != y[i] and y[i] != '?':
                return 0
        return 1
        
    transf = stencil(search_kernel, neighborhood = ((0, seq.size),), standard_indexing=("y",))(arr, seq)
    return np.count_nonzero(transf) > 0

def convert_to_nparray(string):
    return np.fromiter(string, dtype='<U1')
    
if __name__ == '__main__':
    import time
    s1 = "".join(["AAAAACCTGGCCCC" for _ in range(1000)])
    a1 = convert_to_nparray(s1)
    q = convert_to_nparray("CCT?G")
    a = search_sequence2(a1, q)
```

It compiles and runs ok with python, but as soon as `@njit` is added, it fails compilation with the following:

```
  File "/usr/local/lib/python3.7/site-packages/numba-0.50.0.dev0+279.gb3d09ff64-py3.7-macosx-10.15-x86_64.egg/numba/parfors/array_analysis.py", line 2766, in _analyze_stencil
    arg in std_idx_arrs
TypeError: Failed in nopython mode pipeline (step: convert to parfors)
argument of type 'Var' is not iterable
```


https://gist.github.com/alcides/e102d6175b48e1682b47cfae9eafa25d
user: alcides
issue_5726: state: open
title: jitclass doesn't respect ndarray.flags.writeable flag
body: Related to https://github.com/numba/numba/issues/1229. 

Normal numba jit functions respect NumPy's writeable flags, but jitclass methods don't seem to. 

You can see in the example below that `a` should be read-only, however it's modified after it's passed into the jitclass. 

```python
import numba
import numpy as np

spec = [('x', numba.int64[:])]

@numba.jitclass(spec)
class TestClass:
    def __init__(self, x):
        self.x = x
    
    def modify(self):
        self.x[1] = 20


a = np.arange(5)
a.flags.writeable = False
test_class = TestClass(a)
test_class.modify()

print(a)
```

Prints this:
```[ 0 20  2  3  4]```

user: hcarlens
issue_5723: state: open
title: Overload float(), int() and str() to do number <-> string conversion
body: So currently all three of these jitted functions will fail

```python
@njit
def failed_str():
	str(1.2)
@njit
def failed_float():
	float("1.2")
@njit
def failed_int():
	int("1.2")
```
I've tried re-implementing these and overloading them.
Strings -> Numbers
```python
@njit
def str_to_posint(s):
	final_index, result = len(s) - 1, 0
	for i,v in enumerate(s):
		result += (ord(v) - 48) * (10 ** (final_index - i))
	return result

@njit
def str_to_int(s):
	neg = (s[0] == "-")
	if(neg): s = s[1:]
	result = str_to_posint(s)
	return -result if neg else result

@njit
def str_to_float(s):
	neg = (s[0] == "-")
	if(neg): s = s[1:]

	exp,dec_loc,exp_loc = 1,-1, len(s)
	for i,c in enumerate(s):
		if(c == "."): 
			dec_loc=i
		elif(c == "e"):
			exp_loc=i
			exp = str_to_int(s[exp_loc+1:])

	if(dec_loc != -1):
		result = str_to_posint(s[:dec_loc])
		result += float(str_to_posint(s[dec_loc+1:exp_loc])) / np.power(10,(exp_loc-dec_loc-1))
	else:
		result = str_to_posint(s)

	if(exp != 1):
		result *= 10.**exp

	if(neg): result = -result
	return result
``` 
Numbers -> Strings
```python
@overload(str)
def _str(x):
	if isinstance(x,types.Integer):
		def int_to_str(x):
			isneg = int(x < 0.0)
			x = np.abs(x)
			l = 0 
			_x = x
			while _x > 0:
				_x = _x // 10
				l += 1
			s = _empty_string(PY_UNICODE_1BYTE_KIND,l+isneg)
			if(isneg): _set_code_point(s,0,DASH)
			for i in range(l):
				digit = x % 10
				_set_code_point(s,isneg+l-i-1,digit + DIGITS_START)
				x = x // 10
			return s
		return int_to_str
	elif isinstance(x,types.Float):
		def float_to_str(x):
			if(x == np.inf):
				return 'inf'
			elif(x == -np.inf):
				return '-inf'

			isneg = int(x < 0.0)
			x = np.abs(x)
			l1,l2 = 0,-1
			_x = x
			while _x > 0:
				_x = _x // 10
				l1 += 1
			_x = x % 10 
			while _x > 1e-10:
				_x = (_x * 10) % 10
				l2 += 1

			l2 = max(1,l2)
			l = l1+l2+1

			_x = x-np.floor(x)
			s = _empty_string(PY_UNICODE_1BYTE_KIND,l+isneg)
			if(isneg): _set_code_point(s,0,DASH)


			_x = x
			for i in range(l1):
				digit = int(_x % 10)
				# print('a',digit,(isneg+l1)-i-1)
				_set_code_point(s,(isneg+l1)-i-1,digit + DIGITS_START)
				_x = _x // 10

			# if(l2 > 0):
			_set_code_point(s,l1+isneg,DOT)

			_x = x % 10 
			for i in range(l2):
				_x = (_x * 10) % 10
				digit = int(_x)  
				# print('here',i,digit)
				# print('b',digit,(isneg+l1)+i+1)
				_set_code_point(s,(isneg+l1)+i+1,digit + DIGITS_START)
			return s
		return float_to_str
```

But it seems that just letting numba loop lift the native python is pretty consistently faster than anything that I can write.

```python
import timeit
N=1000
def time_ms(f):
		f() #warm start
		return " %0.6f ms" % (1000.0*(timeit.timeit(f, number=N)/float(N)))

@njit
def numba_to_str(x):
	return str(x)

def py_to_str(x):
	return str(x)

from warnings import catch_warnings

with catch_warnings(record=True) as w:
	@jit
	def nb_lotsa_strings():
		for i in range(1000):
			numba_to_str(14.58)

	@jit
	def nb_lotsa_strings_int():
		for i in range(1000):
			numba_to_str(14)

	@jit
	def py_lotsa_strings():
		for i in range(1000):
			py_to_str(14.58)

	@jit
	def py_lotsa_strings_int():
		for i in range(1000):
			py_to_str(14)

	print("nb_to_str",time_ms(nb_lotsa_strings))
	print("nb_int_to_str",time_ms(nb_lotsa_strings_int))
	print("py_to_str",time_ms(py_lotsa_strings))
	print("py_int_to_str",time_ms(py_lotsa_strings_int))
```
```bash
----numba---
nb_to_str  1.287220 ms
nb_int_to_str  0.047568 ms
---python---
py_to_str  0.424743 ms
py_int_to_str  0.246021 ms

```

So my feature request is can str(int/float), float(str) and int(str) just be overloaded to grab the GIL and just call native python? Or might there be a way for these to just call out directly to the cpython implementations?

This is related to #5650 and #4758
user: DannyWeitekamp
issue_5720: state: open
title: vectorize(target="parallel") breaks type resolution
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).


The following piece of code runs fine and returns the expected result:
```python
import numba
from numba.core.types import int64

@numba.vectorize(
    [int64(int64)],
    # target="parallel",
    nopython=True
)
def square(x):
    return x*x

@numba.njit()
def caller(n):
    return square(n)

print(caller(10))
```
```
100
```

However, activating the ```target="parallel"``` flag breaks the compilation
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'square': cannot determine Numba type of <class 'numpy.ufunc'>

File "parallel_vector_breaks.py", line 14:
def caller(n):
    return square(n)
    ^
```

Calling the same vectorized function from a non-jitted context works fine, with and without the parallel target.
user: HPLegion
issue_5715: state: open
title: Implement `in`/`operator.contains` consistently.
body: `operator.contains` should be overloaded to call `__contains__` on the type.

See: https://gitter.im/numba/numba?at=5ebfda9af3ce603074c10494

Related: https://github.com/numba/numba/issues/5536
user: stuartarchibald
issue_5713: state: open
title: List() and Dict() always recompile _getitem,_setitem, _length, etc. every time; maybe should cache?
body: - [ x] I am using the latest released version of Numba: 0.49.1
- [ x] I have included below a minimal working reproducer 

Something that has been bothering me is that for the typed List() and Dict() types every time I use a new type outside of a jitted function it will recompile all of the primitive functions I use with it. For example this simple example:

```python
import numba
from numba.types import f8,u8,i8
from numba.typed import Dict,List
import time

start = time.time()
for t1 in [f8,u8,i8]:
	l = List.empty_list(t1)
	l.append(0)
	v = l[0]
	for t2 in [f8,u8,i8]:
		d = Dict.empty(t1,t2)
		d[0] = 1
		v = d[0]
		for x in d:
			pass
end = time.time()
print("Time elapsed: %.2f" % (end - start))
```
Takes about 5 secs to run. Note that that is a ton of time since its only doing like 9 total iterations.

But when I just change all of the @njits in typedlist.py and typeddict.py to @njit(cache=True) this same script takes just 0.12 seconds, which is at least a reasonable amount of time to wait for my script to start up.

This bug is pretty frustrating because I'm trying to speed up my code with numba, but there is this annoying sunk cost whenever i want to fill a List which gets worse for every additional type I use. And, yes I am aware that with these particular types at least for the Lists() I could just instead use an np.array() instead. Unfortunately my use case requires a lot of strings, and arrays aren't particularly amenable to strings at the moment.

I'm also wondering if this might have something to do with #4584



user: DannyWeitekamp
labels: performance: performance related issue
issue_5712: state: open
title: Greater support of thread specific arrays
body: Currently Numba supports thread specific arrays, in the form of the local.array, but only to a very limited extent. You cannot initialize an array with values even if the input is compile time known (ex: local.array([0,1,2,3]), you cannot return the array from device functions, and you cannot perform vectorized operations on the array (I mean this in the most simple context like array + scalar and array + array where both are the same length). It would be very useful if the above were supported.
user: uchytilc
labels: CUDA: CUDA related issue/PR
issue_5706: state: open
title: Please add support for Metal as GPU accelerator
body: ## Support Metal as GPU accelerator

It would be great to add support for Metal as GPU accelerator for Numba to speed up Python on macOS machines. 
user: robinhad
issue_5703: state: open
title: Nested tuples with numba.prange cause LoweringError
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Using nested named tuples together with ```numba.prange``` throws LoweringError

```python
import numba
from collections import namedtuple
import numpy as np

Tup = namedtuple("Tup", "a")
NestedTup = namedtuple("NestedTup", "field")

@numba.njit(parallel=True)
def pfun(arr, tup, nested_tup):
    for n in numba.prange(arr.size):
        arr[n] = n + tup.a + nested_tup.field.a
    return arr

tup = Tup(1)
nested_tup = NestedTup(Tup(2))

print(pfun(np.zeros(10), tup, nested_tup))
```

results in

```
numba.core.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
scalar type Tup(int64 x 1) given for non scalar argument #2

File "prange_nested_tuple.py", line 10:
def pfun(arr, tup, nested_tup):
    for n in numba.prange(arr.size):
    ^

[1] During: lowering "id=0[LoopNest(index_variable = parfor_index.2, range = (0, $10load_attr.3, 1))]{18: <ir.Block at prange_nested_tuple.py (10)>}Var(parfor_index.2, prange_nested_tuple.py:10)" at prange_nested_tuple.py (10)
```

(Initially reported on [Gitter](https://gitter.im/numba/numba?at=5ebd12cf2ac6ef4e88c6363e))
user: HPLegion
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_5696: state: open
title: Too slow jit compilation of a function
body: I needed to apply a fairly complex dynamic (user-provided) filter expression to a fairly large dataframe, so in hope to speed up this operation I was trying to use Numba to jit compile dynamically-generated (from the Python source code string) filtering function.

Though, the problem is, that compilation takes too much time (about 100 seconds) on my fairly performant laptop (Intel® Core™ i7-8750H CPU @ 2.20GHz × 12, 32Gb RAM)

Thus, this is a kind of deoptimization for me, as non-jitted function takes less than 60 seconds to apply.

I initially tried to unroll (inline) is_in() function to a number of comparisons, but in this case compilation took even longer than 10 minutes.

While this is not a bug strictly speaking, my assumption is, that for any reasonably optimized compiler it wouldn't take more than a second to compile a function of such a complexity.

Assuming that the core reason the Numba ever exists is a performance improvement,  I decided to report this issue as a bug. 

Below is the real function I tried to jit, I only mangled column names for privacy reasons. 

Also, any suggestions of how to radically speed up compilation time are welcome. Unfortunately, caching is not an option yet, as function body is generated dynamically on the fly.

I'm thinking about separating the logic from the data, ie passing a list of comparison clauses as a parameter to a statically compiled function, but Numba is really bad in supporting of complex variable sized structures. 

I'd probably suggest to consider supporting Arrow data structures and apis to get rid of this limitation, maybe even instead of Numpy arrays, if supporting both is not feasible / too complex, as Arrow arrays can be relatively easy converted to Numpy arrays without memory re-allocation / copying.

```Python
@nb.njit
def is_in(elem, *list):
    return elem in list

@nb.njit('void(u4[:], u4[:], f8[:], u4[:], u4[:], u4[:], b1[:,:])', parallel=True, nogil=True)
def dyn_filter(a_a, b_a, c_a, d_a, e_a, f_a, result):
    size = a_a.size
    for i in nb.prange(size):
        a, b, c, d, e, f = a_a[i], b_a[i], c_a[i], d_a[i], e_a[i], f_a[i]

        result[i][0] = (not (is_in(d, 3966))) and (is_in(b, 2211,41113,41114,41111) or not is_in(d, 255349621)) and (is_in(b, 41114) or not is_in(d, 184)) and (is_in(b, 41113,41114) or not is_in(d, 75,146,182,186,289,326,109,110,111)) and (is_in(f, 1,0))
        result[i][1] = (is_in(b, 41112,41113)) and (is_in(f, 1))
        result[i][2] = (is_in(b, 41112,41113)) and (is_in(f, 0))
        result[i][3] = (not (is_in(d, 1727714,62197706,62197705,62197669,62197677,48135,1732861,62382996,48134,1732825,62381700,62380409,62380405,62380408,141301,5086837,183126133,183126141,141307,5087053,183133908,141306,5087017,183132613,183132614,183132615,183132617,183131317,183131318,183131319,6911642,248819112,6911641,248819076,191991,6911677,248820372,193177,6954373,250357429,250357430))) and (is_in(b, 41112,41113,41115,41114))
        result[i][4] = (is_in(f, 1,2) or not is_in(d, 48027)) and (is_in(b, 41112,41113)) and (is_in(b, 41114) or not is_in(d, 184))
        result[i][5] = (is_in(f, 0)) and (is_in(b, 41113,41111,41114))
        result[i][6] = (is_in(b, 41113,411131,41114,41115)) and (is_in(f, 0))
        result[i][7] = (not (is_in(d, 3499309))) and (is_in(b, 41112,41113,41114))
        result[i][8] = (not (is_in(d, 3499309))) and (is_in(b, 41112,41113,41114)) and (is_in(f, 1) or not is_in(d, 6589,326,6625,148,149))
        result[i][9] = (is_in(f, 1,2)) and (is_in(b, 41112,41113,41114,41115,518) or not is_in(d, 183131320)) and (is_in(b, 41112,41113,41114))
        result[i][10] = (is_in(b, 41113,41115)) and (is_in(f, 0))
        result[i][11] = (is_in(b, 41115,41114) or not is_in(d, 241094,5365)) and (not c or 10000000 <= c <= 486000000000 or not is_in(d, 184)) and (not e or 25 <= e <= 20000000 or not is_in(d, 184))
        result[i][12] = (not (is_in(d, 142705,3964))) and (is_in(b, 41113,411131,41115,41114)) and (is_in(f, 0))
        result[i][13] = (is_in(b, 41113,411131,41115,41114)) and (is_in(f, 0))
        result[i][14] = (is_in(b, 41115))
        result[i][15] = (is_in(b, 41114)) and (not e or 2 <= e <= 18500000)
        result[i][16] = (not (is_in(d, 374656,13487617,485554212,374654,13487545,485551629,485551622,485551621,374655,13487581,485552917,485552925,485552918,374661,13487805,485560980,13487799,485560764,13487800,485560800,13487797,485560692,13487798,485560728))) and (is_in(b, 41114))
        result[i][17] = (is_in(b, 41114))
        result[i][18] = (not (is_in(d, 235989))) and (is_in(b, 41114)) and (not e or 2 <= e <= 18500000 or not is_in(d, 238501))
        result[i][19] = (is_in(b, 41115))
        result[i][20] = (is_in(b, 41115))
        result[i][21] = (not (is_in(d, 374656,13487617,485554212,374654,13487545,485551629,485551622,485551621,374655,13487581,485552917,485552925,485552918,374661,13487805,485560980,13487799,485560764,13487800,485560800,13487797,485560692,13487798,485560728))) and (is_in(b, 41114))
        result[i][22] = (is_in(b, 41114))
        result[i][23] = (is_in(b, 41114)) and (not e or 2 <= e <= 18500000)
        result[i][24] = (is_in(b, 41115))
        result[i][25] = (is_in(b, 41115))
        result[i][26] = (not (is_in(d, 282566,10172377,366205572,282568,10172449,366208164,10172457,366208460,366208455,366208454,366208453,282567,10172413,366206868,10172414,366206904,10172415,366206940,10172416,366206976,10172421,366207165,366207157,366209462,282573,10172637,366214941,366214933,10172629,366214644,282603,10173709,366253524,282637,10174933,366297588,282639,10175005,366300181,366300182,282645,10175229,366308244,7852,282673,10176229,366344244,10176230,366344280,10176237,366344532,282675,10176301,366346836,282674,10176265,366345540,10176266,366345577,366345585,10176267,366345612,282676,10176337,366348132,184996263,184996264))) and (is_in(b, 41113,41112,41114,41115)) and (is_in(f, 0))
        result[i][27] = (not (is_in(d, 141302,5086875,183127500,5086874,183127468,183127469,183127465,5086873,183127429,183127430,183127431,141301,5086837,183126133,183126141,5087126,183136536,183136609,183136501,5087133,183136789,183136797,183135244,5087091,183135276,141307,5087053,183133908,141306,5087017,183132613,183132614,183132615,183132617,141305,5086981,183131317,183131318,183131319,183131320,5086982,183131352,141304,5086946,183130057,183130058,183130059,5086945,183130021,183130022,183128869,5086909,183128727,183128728,189364,238503))) and (is_in(b, 41113,41112,41114,41115)) and (is_in(f, 0))
        result[i][28] = (not (is_in(d, 142749))) and (is_in(b, 41114,41113) or not is_in(d, 184,218)) and (is_in(b, 41111,41112,411131,41113) or not is_in(d, 146,289,75,37,186,73,109,110,111)) and (is_in(f, 0))
        result[i][29] = (is_in(b, 41115)) and (is_in(f, 0))
        result[i][30] = (not (is_in(d, 142749))) and (is_in(b, 41111,411131,41113,41114)) and (is_in(f, 0))
        result[i][31] = (not (is_in(d, 5182780))) and (is_in(b, 41111,41113,41114,411131)) and (is_in(f, 0))
        result[i][32] = (is_in(b, 41113,41114,41115,41112)) and (is_in(f, 0))
        result[i][33] = (is_in(b, 41113,41115,41114)) and (is_in(f, 0))
        result[i][34] = (not (is_in(d, 143894,3997,143931,3998,5181733,143937,5184181,144005,4000,189331,5259,146,238503,6625,184,238504,241137,6698,186,422533,11737,326,422569,11738,109,110,111,152,153))) and (is_in(b, 411131,41113)) and (is_in(f, 2,0))
        result[i][35] = (not (is_in(d, 3503170,126253800,3503171,126299160,126299124,126309780,3503163,126345996,126346068,126253764,3503164,126299196,6625,184,186,422533,11737,326,3508309))) and (is_in(b, 41115) or not is_in(d, 75)) and (is_in(b, 41114,41115) or not is_in(d, 182)) and (is_in(b, 41114) or not is_in(d, 184,312460596)) and (is_in(b, 41114))
        result[i][36] = (is_in(b, 41113,411131,41115,41114)) and (is_in(f, 1,0))
        result[i][37] = (not (is_in(d, 97310,3499309,142745,3965,142821,3967,143931,3998,5259,146,189329,6625,184,238506,218,422677,11741,326,109,110,111))) and (is_in(b, 41112,41113,41114)) and (is_in(f, 1) or not is_in(d, 6589,326,6625,148,149))
        result[i][38] = (not (is_in(d, 4000,4005,189328,5259,146,10172341,282565,7849,218,7850,109,110,111))) and (is_in(b, 41112,41113) or not is_in(d, 146,109,110,111)) and (is_in(b, 41114) or not is_in(d, 218))
        result[i][39] = (not (is_in(d, 424992133,327925,11805309,424991124,11805302,424990872,11805303,424990908,11805301,424990836,327928,11805409,424994724,327929,11805445,424996020,9110,327961,11806599,425037564,11806597,425037492,11806598,425037528,11806605,425037780,327998,11807929,425085444,11807937,425085732,327997,11807894,425084184,11807893,425084148,237205,6589,183,237207,8679529,241098,6697,186,241099,241101))) and (is_in(b, 41113,41115))
        result[i][40] = (is_in(b, 41112,41113,41114)) and (is_in(f, 0))
        result[i][41] = (not (is_in(d, 3966))) and (is_in(b, 2211,41113,41114,41111) or not is_in(d, 255349621)) and (is_in(b, 41114) or not is_in(d, 184)) and (is_in(b, 41113,41114) or not is_in(d, 75,146,182,186,289,326,109,110,111)) and (is_in(f, 1,0))
        result[i][42] = (is_in(b, 411131,41113,41115)) and (is_in(f, 0))
        result[i][43] = (is_in(b, 41113,41111)) and (is_in(f, 0))
        result[i][44] = (is_in(b, 41115,41114)) and (is_in(f, 0))
        result[i][45] = (is_in(b, 411131,41113)) and (is_in(f, 0))
        result[i][46] = (is_in(b, 41113,411131,41111,41114)) and (is_in(f, 0))
        result[i][47] = (is_in(b, 41113,41112,41114)) and (is_in(f, 1))
        result[i][48] = (is_in(b, 41112,41113,518,41114)) and (is_in(f, 0))
        result[i][49] = (is_in(f, 0)) and (is_in(b, 41113,41115,41114))
        result[i][50] = (not (is_in(d, 6815774,245367864,6815775,245367900,6815781,245368116,182))) and (is_in(b, 41112,41113,41114)) and (is_in(f, 0))
        result[i][51] = (is_in(b, 41115,41114)) and (is_in(f, 0))
        result[i][52] = (not (is_in(d, 8496657))) and (is_in(f, 0)) and (is_in(b, 41115,41114,41118))
        result[i][53] = (is_in(b, 41113,411131,41115,41114)) and (is_in(f, 1,0))
        result[i][54] = (not (is_in(d, 6911642,248819112,6911641,248819076))) and (is_in(b, 41113,41114,41111))
        result[i][55] = (not (is_in(d, 141301,5086837,183126133,183126141,141307,5087053,183133908,5086981,183131317,183131318,183131319,183131320))) and (is_in(b, 41113,41114,41115,518))
        result[i][56] = (is_in(b, 411131,41113)) and (is_in(f, 2,0))
        result[i][57] = (is_in(b, 41115,41114)) and (not e or 25 <= e <= 2200000 or not is_in(d, 184)) and (not c or 10000000 <= c <= 476000000000 or not is_in(d, 184))
        result[i][58] = (is_in(b, 41113,411131,41114,23111)) and (is_in(f, 0))
        result[i][59] = (is_in(b, 41112,41114)) and (is_in(f, 0))
        result[i][60] = (is_in(f, 0)) and (is_in(b, 41112,518,41113))
        result[i][61] = (is_in(b, 41115,41114))
        result[i][62] = (is_in(b, 41112,41113,41115,41114)) and (is_in(f, 0))
        result[i][63] = (is_in(b, 41112,41113,41114))
        result[i][64] = (is_in(b, 411131,41113)) and (is_in(f, 2))
        result[i][65] = (is_in(b, 41113,41114)) and (is_in(f, 0))
        result[i][66] = (is_in(f, 0,2)) and (is_in(b, 41113,41114))
        result[i][67] = (is_in(b, 41111,41113,41114)) and (is_in(f, 0))
        result[i][68] = (is_in(b, 41112,41113,411131,41114)) and (is_in(f, 2))
        result[i][69] = (is_in(b, 518,41112,41113,41115)) and (is_in(f, 0))
        result[i][70] = (is_in(b, 41112,41113,411131,41114)) and (is_in(f, 0))
        result[i][71] = (is_in(b, 41114,41115)) and (not c or 10000000 <= c <= 486000000000 or not is_in(d, 238502,238501)) and (not e or 25 <= e <= 20000000 or not is_in(d, 238501,238502))
        result[i][72] = (is_in(b, 41115,41114))
        result[i][73] = (not (is_in(d, 8497910,305924760,8497917,305925012))) and (is_in(f, 1)) and (is_in(b, 41115,41114))
        result[i][74] = (is_in(f, 0)) and (is_in(b, 41113,41111))
        result[i][75] = (is_in(b, 41114,41115)) and (not c or 10000000 <= c <= 486000000000 or not is_in(d, 184)) and (not e or 25 <= e <= 20000000 or not is_in(d, 184)) and (is_in(f, 0)) and (is_in(b, 41114) or not is_in(d, 184))
        result[i][76] = (not (is_in(d, 144077,5186773,186723828,144076,5186737,186722541,186722537,186722536,186722535,186722534,186722533,186719943,144081,5186925,186729309,186729302,186729301,144078,5186809,186725126,186725125,5480))) and (is_in(f, 1)) and (is_in(b, 41113))
        result[i][77] = (is_in(b, 41115,41113,41112,41114)) and (is_in(f, 0))
        result[i][78] = (is_in(b, 41115,41114)) and (not e or 25 <= e <= 2200000 or not is_in(d, 238501,238502)) and (not c or 10000000 <= c <= 476000000000 or not is_in(d, 238502,238501)) and (is_in(f, 1) or not is_in(d, 109,110,111))
        result[i][79] = (is_in(b, 41112,41114))
        result[i][80] = (is_in(b, 41113,41112,41111,411131,41114)) and (is_in(f, 1))
        result[i][81] = (is_in(b, 41114,41115,41113)) and (is_in(f, 1))
        result[i][82] = (not (is_in(d, 8446072,304058592,8446077,304058781,304058773))) and (is_in(b, 41115,41114,41113))
        result[i][83] = (is_in(b, 41112,41113,41114)) and (is_in(f, 0))
        result[i][84] = (is_in(b, 41115,41114)) and (is_in(f, 2,0)) and (is_in(f, 2) or not is_in(d, 109,110,111))
        result[i][85] = (not (is_in(d, 6697,186))) and (is_in(b, 41115,41114)) and (not e or 35 <= e <= 2300000)
        result[i][86] = (is_in(b, 41112,41114,518,41113))
        result[i][87] = (is_in(b, 41112,41114,41115,41113))
        result[i][88] = (is_in(b, 41113,41112,41115)) and (is_in(f, 0))
        result[i][89] = (is_in(b, 41115))
        result[i][90] = (is_in(b, 41113,41111,41114)) and (is_in(f, 1))
        result[i][91] = (not (is_in(d, 6906458,248632496,248632490,6906494,248633784))) and (is_in(b, 41113,41115,41112,518,41114))
        result[i][92] = (is_in(f, 0)) and (is_in(b, 41115,41113,41114,41112))
        result[i][93] = (is_in(b, 411131,41114,41115,41112,41113))
        result[i][94] = (is_in(b, 41113,41111,41114,41112)) and (is_in(f, 0))
        result[i][95] = (is_in(b, 41114,41115)) and (not c or 10000000 <= c <= 486000000000 or not is_in(d, 184)) and (not e or 25 <= e <= 20000000 or not is_in(d, 184))
```
user: pragmasoft-ua
issue_5693: state: open
title: Issue boxing tuple of dispatcher
body: > actually the aim of the example is loop a tuple of functions via `literal_unroll`, not with first-class functions

I believe this cannot be done without first-class functions.

For instance, with numba-0.48.0 the example fails with:
```
>>> baz(np.zeros((5, 10)), funcs)
TypeError: cannot convert native type(CPUDispatcher(<function foo2 at 0x7f2b5bfb2c10>)) to Python object

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: CPUDispatcher(<function baz at 0x7f2b5bf24310>) returned a result with an error set
```

_Originally posted by @pearu in https://github.com/numba/numba/issues/5685#issuecomment-626036337_
user: sklam
issue_5688: state: open
title: Segfault when executing a cached lexsort implementation
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).

```bash
$ pip freeze
llvmlite==0.32.1
numba==0.49.1
numpy==1.18.4
```
 
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).


`numba.literal_unroll` seems like it would make a lexsort implementation easy. I had a go and it mostly worked! So thanks for `numba.literal_unroll`!

However, when I try to put ``cache=True`` into the ``generated_jit`` decorator, the lexsort function is successful on the initial run, but segfaults on subsequent runs:

```python
from numba import njit, generated_jit, literal_unroll, gdb
import numba.core.types as types
import numba
import numpy as np

@njit
def cmp_fn(l, r, *arrays):
    for a in literal_unroll(arrays):
        if a[l] < a[r]:
            return -1  # less than
        elif a[l] > a[r]:
            return 1   # greater than

    return 0  # equal


@njit
def quicksort(index, L, R, *arrays):
    l, r = L, R
    pivot = index[(l + r) // 2]

    while True:
        while l < R and cmp_fn(index[l], pivot, *arrays) == -1:
            l += 1
        while r >= L and cmp_fn(pivot, index[r], *arrays) == -1:
            r -= 1

        if l >= r:
            break

        index[l], index[r] = index[r], index[l]
        l += 1
        r -= 1

        if L < r:
            quicksort(index, L, r, *arrays)

        if l < R:
            quicksort(index, l, R, *arrays)

@njit(nogil=True, cache=True, debug=True)
def lexsort(arrays):
    print("starting lexsort")

    if len(arrays) == 0:
        return np.empty((), dtype=np.intp)

    if len(arrays) == 1:
        return np.argsort(arrays[0])


    for a in literal_unroll(arrays[1:]):
        if a.shape != arrays[0].shape:
            raise ValueError("lexsort array shapes don't match")

    n = arrays[0].shape[0]
    index = np.arange(n)

    quicksort(index, 0, n - 1, *arrays)

    print("ending lexsort")
    return index

a = np.array([2, 1, 4, 3, 0], dtype=np.int32)
b = np.array([1, 2, 3, 4, 5], dtype=np.float64)

print("before lexsort")
print(lexsort((a, b)))
print("after lexsort")
```

I considered out of bounds access in my quicksort implementation, but that's never reached. I tried running this through gdb, and "starting quicksort" isn't printed.

```gdb
$ gdb -ex r --args python test_literal_unroll.py 
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...Reading symbols from /usr/lib/debug/.build-id/5f/4de7b7974f514b4d5baf54bc956904a450c144.debug...done.
done.
Starting program: /home/sperkins/venv/numba/bin/python test_literal_unroll.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee395700 (LWP 20316)]
[New Thread 0x7fffebb94700 (LWP 20317)]
[New Thread 0x7fffe9393700 (LWP 20318)]
[New Thread 0x7fffe8b92700 (LWP 20319)]
[New Thread 0x7fffe4391700 (LWP 20320)]
[New Thread 0x7fffe1b90700 (LWP 20321)]
[New Thread 0x7fffe138f700 (LWP 20322)]
[Thread 0x7fffe138f700 (LWP 20322) exited]
[Thread 0x7fffe1b90700 (LWP 20321) exited]
[Thread 0x7fffe4391700 (LWP 20320) exited]
[Thread 0x7fffe8b92700 (LWP 20319) exited]
[Thread 0x7fffe9393700 (LWP 20318) exited]
[Thread 0x7fffebb94700 (LWP 20317) exited]
[Thread 0x7fffee395700 (LWP 20316) exited]
before lexsort
starting lexsort
ending lexsort
[4 1 0 3 2]
after lexsort
[Inferior 1 (process 20309) exited normally]
(gdb) r
Starting program: /home/sperkins/venv/numba/bin/python test_literal_unroll.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee395700 (LWP 20327)]
[New Thread 0x7fffebb94700 (LWP 20328)]
[New Thread 0x7fffeb393700 (LWP 20329)]
[New Thread 0x7fffe8b92700 (LWP 20330)]
[New Thread 0x7fffe4391700 (LWP 20332)]
[New Thread 0x7fffe1b90700 (LWP 20333)]
[New Thread 0x7fffdf38f700 (LWP 20334)]
[Thread 0x7fffdf38f700 (LWP 20334) exited]
[Thread 0x7fffe1b90700 (LWP 20333) exited]
[Thread 0x7fffe4391700 (LWP 20332) exited]
[Thread 0x7fffe8b92700 (LWP 20330) exited]
[Thread 0x7fffeb393700 (LWP 20329) exited]
[Thread 0x7fffebb94700 (LWP 20328) exited]
[Thread 0x7fffee395700 (LWP 20327) exited]
before lexsort

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7fe8715 in cpython::__main__::lexsort$241(Tuple<Array<int, 1, C, mutable, aligned>, Array<double, 1, C, mutable, aligned> >) ()
#2  0x00007fffeb98d5d9 in call_cfunc (self=self@entry=0x7fffda0f0660, cfunc=cfunc@entry=0x7fffd9d80ee8, args=args@entry=0x7ffff7e66f28, 
    kws=kws@entry=0x0, locals=locals@entry=0x0) at numba/_dispatcher.c:353
#3  0x00007fffeb98d910 in compile_and_invoke (self=self@entry=0x7fffda0f0660, args=args@entry=0x7ffff7e66f28, kws=kws@entry=0x0, locals=locals@entry=0x0)
    at numba/_dispatcher.c:376
#4  0x00007fffeb98dace in Dispatcher_call (self=0x7fffda0f0660, args=0x7ffff7e66f28, kws=<optimised out>) at numba/_dispatcher.c:591
#5  0x00000000005a9cbc in _PyObject_FastCallDict (kwargs=<optimised out>, nargs=1, args=0xae0410, func=0x7fffda0f0660) at ../Objects/tupleobject.c:131
#6  _PyObject_FastCallKeywords () at ../Objects/abstract.c:2496
#7  0x000000000050a5c3 in call_function.lto_priv () at ../Python/ceval.c:4875
#8  0x000000000050bfb4 in _PyEval_EvalFrameDefault () at ../Python/ceval.c:3335
#9  0x0000000000507d64 in PyEval_EvalFrameEx (throwflag=0, f=0xae0288) at ../Python/ceval.c:754
#10 _PyEval_EvalCodeWithName.lto_priv.1820 () at ../Python/ceval.c:4166
#11 0x000000000050ae13 in PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, 
    locals=<optimised out>, globals=<optimised out>, _co=<optimised out>) at ../Python/ceval.c:4187
#12 PyEval_EvalCode (co=<optimised out>, globals=<optimised out>, locals=<optimised out>) at ../Python/ceval.c:731
#13 0x0000000000634c82 in run_mod () at ../Python/pythonrun.c:1025
#14 0x0000000000634d37 in PyRun_FileExFlags () at ../Python/pythonrun.c:978
#15 0x00000000006384ef in PyRun_SimpleFileExFlags () at ../Python/pythonrun.c:419
#16 0x00000000006386c5 in PyRun_AnyFileExFlags () at ../Python/pythonrun.c:81
#17 0x0000000000639091 in run_file (p_cf=0x7fffffffd70c, filename=<optimised out>, fp=<optimised out>) at ../Modules/main.c:340
---Type <return> to continue, or q <return> to quit---```
user: sjperkins
labels: caching: Issue involving caching
issue_5687: state: open
title: Segfault in jitted class when deleting and appending list elements
body: The following code causes a segfault for me (on a plain AWS ubuntu EC2 instance):
```
import numba
@numba.experimental.jitclass([('L', numba.types.List(numba.types.Set(numba.types.int64))),
                              ('D', numba.types.DictType(numba.types.int64, numba.types.int64))])
class ListnDict(object):
    def __init__(self):
        self.L       = [set([0])]
        del self.L[0]
        self.L.append(set([0]))
        self.D       = {0:0};
x = ListnDict()
x.D
```
Here is my python session:
```
Python 3.6.9 (default, Apr 18 2020, 01:56:04) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numba
>>> @numba.experimental.jitclass([('L', numba.types.List(numba.types.Set(numba.types.int64))),
...                               ('D', numba.types.DictType(numba.types.int64, numba.types.int64))])
... class ListnDict(object):
...     def __init__(self):
...         self.L       = [set([0])]
...         del self.L[0]
...         self.L.append(set([0]))
...         self.D       = {0:0};
... 
>>> x = ListnDict()
>>> x.L
[{0}]
>>> x.D
Segmentation fault (core dumped)
```
I did not try all possible combinations of arguments, but when I removed the field `D` or changed it to an `int64`, I did not experience the segfault.  The segfault also does not occur if I do the `del` in the python session rather than a jitted method:
```
>>> import numba
>>> @numba.experimental.jitclass([('L', numba.types.List(numba.types.Set(numba.types.int64))),
...                               ('D', numba.types.DictType(numba.types.int64, numba.types.int64))])
... class ListnDict(object):
...     def __init__(self):
...         self.L       = [set([0])]
...         self.D       = {0:0};
... 
>>> x = ListnDict()
>>> x.L
[{0}]
>>> x.D
DictType[int64,int64]({0: 0})
>>> del x.L[0]
>>> x.D
DictType[int64,int64]({0: 0})
>>> x.L.append([set([0])])
>>> x.L
[{0}]
>>> x.D
DictType[int64,int64]({0: 0})
```
I am not sure whether I should be using `numba.types.ListType` as an argument to `@jitclass` instead of `numba.types.List`.  When I do that, the compilation does not like the line `self.L = [set([0])]`:
```
... Cannot cast list(set(int64)) to ListType[set(int64)] ...
```
I think I should fix this compilation error by creating an empty list like:
```
self.L = numba.typed.List.empty_list(numba.types.Set(numba.types.int64))
```
But this has the compilation error
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'Set' of type Module(<module 'numba.core.types' from '/usr/local/lib/python3.6/dist-packages/numba/core/types/__init__.py'>)
```
It is completely plausible to me that I am handling something incorrectly with the types, but I think I should get some error other than a segfault.
user: aldenwalker
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_5679: state: open
title: printf that can be called from Numba jit-decorated function
body: ## Feature request

Having the following implementation
```
from numba import extending, cgutils, types
@extending.intrinsic
def printf(typingctx, format_type, *args):
    """printf that can be called from Numba jit-decorated functions.
    """
    if isinstance(format_type, types.StringLiteral):
        sig = nb_types.void(format_type, types.BaseTuple.from_types(args))
        def codegen(context, builder, signature, args):
            cgutils.printf(builder, format_type.literal_value, *args[1:]) 
        return sig, codegen
```
one can call `printf` from a jit-decorated function. For instance,
```
from numba import njit
@njit
def foo(a, b):
    c = 1.3
    printf("in foo, a=%p, b=%i, c=%e\n", a, b, c)
```
and then
```
>>> foo(1, 2)
in foo, a=0x1, b=2, c=1.300000e+00
```

I have found it useful for debugging. If there is interest, where such a codelet should land in numba?

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: pearu
issue_5670: state: open
title: AOT compilation fails with "unresolved external symbol __svml_log2_ha"
body: I'm trying to do AOT compilation for a Python module but keep running into the follow or similar errors:

```
error LNK2001: unresolved external symbol __svml_log2_ha
fatal error LNK1120: 1 unresolved externals
```

I also get similar errors but with log4, exp2, and exp4 in my project. There seems to be something missing in my build environment such that the SVML functions can't be found. I have tried changing cpu_target, adding intel and numba channels to conda, installing Parallel Studio from Intel etc.

Here's a minimal reproducible example:

```python
import setuptools

import numpy as np
from numba.pycc import CC

cc = CC("min_ex")

@cc.export("foo", "f8[:]()")
def foo():
    z = np.ones(10_000_000)
    return np.log(z)

setuptools.setup(
    name="min-example", packages=setuptools.find_packages(), ext_modules=[cc.distutils_extension()]
)
```

My `meta.yml` file is as follow:

```
package:
  name: min-example
  version: "0.1"

source:
  path: .

requirements:
  build:
    - {{ compiler('c') }}
    - {{ compiler('cxx') }}

  host:
    - python>=3.7
    - setuptools
    - numpy>=1.14.6
    - scipy
    - numba==0.49

  run:
    - python
```

System Information:
Window 10
Anaconda (fresh install)
Intel® Xeon® Processor E3-1245 v5 
VS Build Tools installed
user: hnra
labels: AOT: ahead of time compilation issue
issue_5667: state: open
title: Numba leaks compilation objects when overload is used
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

**Update:**

Numba seems to leak compilation objects anytime overload is used:

```python
import numba


def g():
    def f1():
        pass

    @numba.extending.overload(f1)
    def f1_overload():
        return lambda: None

    @numba.njit
    def f():
        f1()
    
    f()


g()
del g
del numba
from pympler import muppy, summary
import objgraph
import gc
gc.collect()


all_objects = muppy.get_objects()

import numba
cres = [a for a in all_objects if isinstance(a, numba.core.registry.CPUDispatcher) and a.signatures]
print(cres)
print(len(cres))

objs = [cres[-1]]

del numba
del cres
del all_objects
gc.collect()

objgraph.show_backrefs(objs, 10, too_many=3, filename='../disp_graph2.png')
```

**original post:**

Numba with parallel=True seems to leak significant amount of compilation objects. The code below shows that a CPUDispatcher object is leaked, which holds references to lots of other objects. For example, `CompileResult` has a reference to `TypeAnnotation`, which has a reference to all basic blocks (maybe some cases like overload compile don't need type annotations?). Numba without parallel=True doesn't leak CPUDispatcher in this case (but doesn't seem to be totally innocent, memory grows over time when something is compiled and thrown away in a loop). These leaks can be quite large with large code bases.

```python
import numba
import numpy as np


def g():
    @numba.njit(parallel=True)
    def f():
        return np.random.ranf(100).sum()
    
    f()


g()
del g
del np
del numba
from pympler import muppy, summary
import objgraph
import gc
gc.collect()


all_objects = muppy.get_objects()

import numba
cres = [a for a in all_objects if isinstance(a, numba.core.registry.CPUDispatcher) and a.signatures]
print(len(cres))

obj = cres[0]

del numba
del cres
del all_objects
gc.collect()

objgraph.show_backrefs([obj], 20, too_many=3, filename='../disp_graph.png')

```
user: ehsantn
labels: bug - memory leak: Memory leak
issue_5661: state: open
title: numba 0.49 crashes when parameter is either number or None
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This code works correctly in numba 0.48:

```
$ cat fail_numba.py 
from numba import njit


@njit
def foo(a, b=None):
    if b is None:
        b = 1
    elif b < a:
        b += 1

    return a + b


if __name__ == "__main__":
    import numba
    print(numba.__version__)
    print(foo(1, 2))
    print(foo(2, 1))
    print(foo(1))
$ python fail_numba.py 
0.48.0
3
4
2
$ NUMBA_DISABLE_JIT=1 python fail_numba.py 
0.48.0
3
4
2
```

However, numba 0.49 chokes on the last function call:

```
$ python fail_numba.py
0.49.0
3
4
Traceback (most recent call last):
  File "fail_numba.py", line 19, in <module>
    print(foo(1))
  File "/home/juanlu/.pyenv/versions/poliastro38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/juanlu/.pyenv/versions/poliastro38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "/home/juanlu/.pyenv/versions/poliastro38/lib/python3.8/site-packages/numba/core/utils.py", line 79, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function lt>) with argument(s) of type(s): (none, int64)
Known signatures:
 * (bool, bool) -> bool
 * (int8, int8) -> bool
 * (int16, int16) -> bool
 * (int32, int32) -> bool
 * (int64, int64) -> bool
 * (uint8, uint8) -> bool
 * (uint16, uint16) -> bool
 * (uint32, uint32) -> bool
 * (uint64, uint64) -> bool
 * (float32, float32) -> bool
 * (float64, float64) -> bool
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
In definition 10:
    All templates rejected with literals.
In definition 11:
    All templates rejected without literals.
In definition 12:
    All templates rejected with literals.
In definition 13:
    All templates rejected without literals.
In definition 14:
    All templates rejected with literals.
In definition 15:
    All templates rejected without literals.
In definition 16:
    All templates rejected with literals.
In definition 17:
    All templates rejected without literals.
In definition 18:
    All templates rejected with literals.
In definition 19:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of intrinsic-call at fail_numba.py (8)

File "fail_numba.py", line 8:
def foo(a, b=None):
    <source elided>
        b = 1
    elif b < a:
    ^

```

Full output with `NUMBA_DEBUG=1`:

<details>

```
$ NUMBA_DEBUG=1 python fail_numba.py
/home/juanlu/.pyenv/versions/poliastro38/lib/python3.8/site-packages/numba/__init__.py:273: UserWarning: SVML was not found/could not be loaded.
  warnings.warn("SVML was not found/could not be loaded.")
================================================================================
--------------------------FUNCTION OPTIMIZED DUMP nrt---------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.140289276597312 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.140289276597312, i32 0, i32 0), i32 102 }
@.const.pickledata.140289276597312 = internal constant [102 x i8] c"\80\05\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

define i64 @nrt_atomic_add(i64* %.1) {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

define i64 @nrt_atomic_sub(i64* %.1) {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = sub i64 %.4, 1
  ret i64 %.5
}

define i32 @nrt_atomic_cas(i64* %.1, i64 %.2, i64 %.3, i64* %.4) {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

define i8* @NRT_MemInfo_data_fast(i8* %.1) {
.3:
  %.4 = bitcast i8* %.1 to { i64, i8*, i8*, i8*, i64 }*
  %.5 = getelementptr { i64, i8*, i8*, i8*, i64 }, { i64, i8*, i8*, i8*, i64 }* %.4, i32 0, i32 3
  %.6 = load i8*, i8** %.5
  ret i8* %.6
}

; Function Attrs: noinline
define void @NRT_incref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.8 = call i64 @nrt_atomic_add(i64* %.7)
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) #0 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif.if, %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.9 = call i64 @nrt_atomic_sub(i64* %.8)
  %.10 = icmp eq i64 %.9, 0
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  call void @NRT_MemInfo_call_dtor(i8* %.1)
  br label %.3.if
}

declare void @NRT_MemInfo_call_dtor(i8*)

define i32 @nrt_unresolved_abort(i8** %.1, { i8*, i32 }** %.2) {
.4:
  store { i8*, i32 }* @.const.picklebuf.140289276597312, { i8*, i32 }** %.2
  ret i32 1
}

attributes #0 = { noinline }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
-------------------------------OPTIMIZED DUMP nrt-------------------------------
; ModuleID = 'nrt'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.const.picklebuf.140289276597312 = internal constant { i8*, i32 } { i8* getelementptr inbounds ([102 x i8], [102 x i8]* @.const.pickledata.140289276597312, i32 0, i32 0), i32 102 }
@.const.pickledata.140289276597312 = internal constant [102 x i8] c"\80\05\95[\00\00\00\00\00\00\00\8C\08builtins\94\8C\0CRuntimeError\94\93\94\8C6numba jitted function aborted due to unresolved symbol\94\85\94N\87\94."

; Function Attrs: norecurse nounwind
define i64 @nrt_atomic_add(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw add i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, 1
  ret i64 %.5
}

; Function Attrs: norecurse nounwind
define i64 @nrt_atomic_sub(i64* nocapture %.1) local_unnamed_addr #0 {
.3:
  %.4 = atomicrmw sub i64* %.1, i64 1 monotonic
  %.5 = add i64 %.4, -1
  ret i64 %.5
}

; Function Attrs: norecurse nounwind
define i32 @nrt_atomic_cas(i64* nocapture %.1, i64 %.2, i64 %.3, i64* nocapture %.4) local_unnamed_addr #0 {
.6:
  %.7 = cmpxchg i64* %.1, i64 %.2, i64 %.3 monotonic monotonic
  %.8 = extractvalue { i64, i1 } %.7, 0
  %.9 = extractvalue { i64, i1 } %.7, 1
  store i64 %.8, i64* %.4, align 8
  %.11 = zext i1 %.9 to i32
  ret i32 %.11
}

; Function Attrs: norecurse nounwind readonly
define i8* @NRT_MemInfo_data_fast(i8* nocapture readonly %.1) local_unnamed_addr #1 {
.3:
  %.5 = getelementptr i8, i8* %.1, i64 24
  %0 = bitcast i8* %.5 to i8**
  %.6 = load i8*, i8** %0, align 8
  ret i8* %.6
}

; Function Attrs: noinline norecurse nounwind
define void @NRT_incref(i8* %.1) local_unnamed_addr #2 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3
  ret void

.3.endif:                                         ; preds = %.3
  %.7 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw add i64* %.7, i64 1 monotonic
  ret void
}

; Function Attrs: noinline
define void @NRT_decref(i8* %.1) local_unnamed_addr #3 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !0

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !0

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: norecurse nounwind writeonly
define i32 @nrt_unresolved_abort(i8** nocapture readnone %.1, { i8*, i32 }** nocapture %.2) local_unnamed_addr #4 {
.4:
  store { i8*, i32 }* @.const.picklebuf.140289276597312, { i8*, i32 }** %.2, align 8
  ret i32 1
}

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #5

attributes #0 = { norecurse nounwind }
attributes #1 = { norecurse nounwind readonly }
attributes #2 = { noinline norecurse nounwind }
attributes #3 = { noinline }
attributes #4 = { norecurse nounwind writeonly }
attributes #5 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}

================================================================================
================================================================================
----------------------------------ASSEMBLY nrt----------------------------------
        .text
        .file   "<string>"
        .globl  nrt_atomic_add
        .p2align        4, 0x90
        .type   nrt_atomic_add,@function
nrt_atomic_add:
        movl    $1, %eax
        lock            xaddq   %rax, (%rdi)
        addq    $1, %rax
        retq
.Lfunc_end0:
        .size   nrt_atomic_add, .Lfunc_end0-nrt_atomic_add

        .globl  nrt_atomic_sub
        .p2align        4, 0x90
        .type   nrt_atomic_sub,@function
nrt_atomic_sub:
        movq    $-1, %rax
        lock            xaddq   %rax, (%rdi)
        addq    $-1, %rax
        retq
.Lfunc_end1:
        .size   nrt_atomic_sub, .Lfunc_end1-nrt_atomic_sub

        .globl  nrt_atomic_cas
        .p2align        4, 0x90
        .type   nrt_atomic_cas,@function
nrt_atomic_cas:
        movq    %rsi, %rax
        xorl    %esi, %esi
        lock            cmpxchgq        %rdx, (%rdi)
        sete    %sil
        movq    %rax, (%rcx)
        movl    %esi, %eax
        retq
.Lfunc_end2:
        .size   nrt_atomic_cas, .Lfunc_end2-nrt_atomic_cas

        .globl  NRT_MemInfo_data_fast
        .p2align        4, 0x90
        .type   NRT_MemInfo_data_fast,@function
NRT_MemInfo_data_fast:
        movq    24(%rdi), %rax
        retq
.Lfunc_end3:
        .size   NRT_MemInfo_data_fast, .Lfunc_end3-NRT_MemInfo_data_fast

        .globl  NRT_incref
        .p2align        4, 0x90
        .type   NRT_incref,@function
NRT_incref:
        testq   %rdi, %rdi
        je      .LBB4_1
        lock            addq    $1, (%rdi)
        retq
.LBB4_1:
        retq
.Lfunc_end4:
        .size   NRT_incref, .Lfunc_end4-NRT_incref

        .globl  NRT_decref
        .p2align        4, 0x90
        .type   NRT_decref,@function
NRT_decref:
        .cfi_startproc
        testq   %rdi, %rdi
        je      .LBB5_2
        #MEMBARRIER
        lock            subq    $1, (%rdi)
        je      .LBB5_3
.LBB5_2:
        retq
.LBB5_3:
        #MEMBARRIER
        movabsq $NRT_MemInfo_call_dtor, %rax
        jmpq    *%rax
.Lfunc_end5:
        .size   NRT_decref, .Lfunc_end5-NRT_decref
        .cfi_endproc

        .globl  nrt_unresolved_abort
        .p2align        4, 0x90
        .type   nrt_unresolved_abort,@function
nrt_unresolved_abort:
        movabsq $.const.picklebuf.140289276597312, %rax
        movq    %rax, (%rsi)
        movl    $1, %eax
        retq
.Lfunc_end6:
        .size   nrt_unresolved_abort, .Lfunc_end6-nrt_unresolved_abort

        .type   .const.picklebuf.140289276597312,@object
        .section        .rodata,"a",@progbits
        .p2align        3
.const.picklebuf.140289276597312:
        .quad   .const.pickledata.140289276597312
        .long   102
        .zero   4
        .size   .const.picklebuf.140289276597312, 16

        .type   .const.pickledata.140289276597312,@object
        .p2align        4
.const.pickledata.140289276597312:
        .ascii  "\200\005\225[\000\000\000\000\000\000\000\214\bbuiltins\224\214\fRuntimeError\224\223\224\2146numba jitted function aborted due to unresolved symbol\224\205\224N\207\224."
        .size   .const.pickledata.140289276597312, 102


        .section        ".note.GNU-stack","",@progbits

================================================================================
0.49.0
----------------------------------IR DUMP: foo----------------------------------
label 0:
    a = arg(0, name=a)                       ['a']
    b = arg(1, name=b)                       ['b']
    $const4.1 = const(NoneType, None)        ['$const4.1']
    $6compare_op.2 = b is $const4.1          ['$6compare_op.2', '$const4.1', 'b']
    branch $6compare_op.2, 10, 16            ['$6compare_op.2']
label 10:
    $const10.0 = const(int, 1)               ['$const10.0']
    b = $const10.0                           ['$const10.0', 'b']
    jump 32                                  []
label 16:
    $20compare_op.2 = b < a                  ['$20compare_op.2', 'a', 'b']
    branch $20compare_op.2, 24, 32           ['$20compare_op.2']
label 24:
    $const26.1 = const(int, 1)               ['$const26.1']
    $28inplace_add.2 = inplace_binop(fn=<built-in function iadd>, immutable_fn=<built-in function add>, lhs=b, rhs=$const26.1, static_lhs=Undefined, static_rhs=Undefined) ['$28inplace_add.2', '$const26.1', 'b']
    b = $28inplace_add.2                     ['$28inplace_add.2', 'b']
    jump 32                                  []
label 32:
    $36binary_add.2 = a + b                  ['$36binary_add.2', 'a', 'b']
    $38return_value.3 = cast(value=$36binary_add.2) ['$36binary_add.2', '$38return_value.3']
    return $38return_value.3                 ['$38return_value.3']

----------------------------------IR DUMP: foo----------------------------------
label 0:
    a = arg(0, name=a)                       ['a']
    b = arg(1, name=b)                       ['b']
    $const4.1 = const(NoneType, None)        ['$const4.1']
    $6compare_op.2 = b is $const4.1          ['$6compare_op.2', '$const4.1', 'b']
    branch $6compare_op.2, 10, 16            ['$6compare_op.2']
label 10:
    $const10.0 = const(int, 1)               ['$const10.0']
    b = $const10.0                           ['$const10.0', 'b']
    jump 32                                  []
label 16:
    $20compare_op.2 = b < a                  ['$20compare_op.2', 'a', 'b']
    branch $20compare_op.2, 24, 32           ['$20compare_op.2']
label 24:
    $const26.1 = const(int, 1)               ['$const26.1']
    $28inplace_add.2 = inplace_binop(fn=<built-in function iadd>, immutable_fn=<built-in function add>, lhs=b, rhs=$const26.1, static_lhs=Undefined, static_rhs=Undefined) ['$28inplace_add.2', '$const26.1', 'b']
    b = $28inplace_add.2                     ['$28inplace_add.2', 'b']
    jump 32                                  []
label 32:
    $36binary_add.2 = a + b                  ['$36binary_add.2', 'a', 'b']
    $38return_value.3 = cast(value=$36binary_add.2) ['$36binary_add.2', '$38return_value.3']
    return $38return_value.3                 ['$38return_value.3']

-----------------------------------propagate------------------------------------
---- type variables ----
[$20compare_op.2 := bool,
 $28inplace_add.2 := int64,
 $36binary_add.2 := int64,
 $38return_value.3 := int64,
 $6compare_op.2 := bool,
 $const10.0 := Literal[int](1),
 $const26.1 := Literal[int](1),
 $const4.1 := none,
 a := int64,
 arg.a := int64,
 arg.b := int64,
 b := int64,
 b.1 := Literal[int](1),
 b.2 := int64,
 b.3 := int64]
-----------------------------------propagate------------------------------------
---- type variables ----
[$20compare_op.2 := bool,
 $28inplace_add.2 := int64,
 $36binary_add.2 := int64,
 $38return_value.3 := int64,
 $6compare_op.2 := bool,
 $const10.0 := Literal[int](1),
 $const26.1 := Literal[int](1),
 $const4.1 := none,
 a := int64,
 arg.a := int64,
 arg.b := int64,
 b := int64,
 b.1 := Literal[int](1),
 b.2 := int64,
 b.3 := int64]
---------------------------------Variable types---------------------------------
{'$20compare_op.2': bool,
 '$28inplace_add.2': int64,
 '$36binary_add.2': int64,
 '$38return_value.3': int64,
 '$6compare_op.2': bool,
 '$const10.0': Literal[int](1),
 '$const26.1': Literal[int](1),
 '$const4.1': none,
 'a': int64,
 'arg.a': int64,
 'arg.b': int64,
 'b': int64,
 'b.1': Literal[int](1),
 'b.2': int64,
 'b.3': int64}
----------------------------------Return type-----------------------------------
int64
-----------------------------------Call types-----------------------------------
{a + b.3: (int64, int64) -> int64,
 b < a: (int64, int64) -> bool,
 b is $const4.1: (int64, none) -> bool,
 inplace_binop(fn=<built-in function iadd>, immutable_fn=<built-in function add>, lhs=b, rhs=$const26.1, static_lhs=Undefined, static_rhs=Undefined): (int64, int64) -> int64}
--------------------LLVM DUMP <function descriptor 'foo$1'>---------------------
; ModuleID = "foo$1"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"

@"_ZN08NumbaEnv8__main__7foo$241Exx" = common global i8* null
define i32 @"_ZN8__main__7foo$241Exx"(i64* noalias nocapture %"retptr", {i8*, i32}** noalias nocapture %"excinfo", i64 %"arg.a", i64 %"arg.b")
{
entry:
  %"a" = alloca i64
  store i64 0, i64* %"a"
  %"b" = alloca i64
  store i64 0, i64* %"b"
  %"$const4.1" = alloca i8*
  store i8* null, i8** %"$const4.1"
  %"$6compare_op.2" = alloca i1
  store i1 0, i1* %"$6compare_op.2"
  %"$const10.0" = alloca i64
  store i64 0, i64* %"$const10.0"
  %"b.1" = alloca i64
  store i64 0, i64* %"b.1"
  %"b.3" = alloca i64
  store i64 0, i64* %"b.3"
  %"$20compare_op.2" = alloca i1
  store i1 0, i1* %"$20compare_op.2"
  %"$const26.1" = alloca i64
  store i64 0, i64* %"$const26.1"
  %"$28inplace_add.2" = alloca i64
  store i64 0, i64* %"$28inplace_add.2"
  %"b.2" = alloca i64
  store i64 0, i64* %"b.2"
  %"$36binary_add.2" = alloca i64
  store i64 0, i64* %"$36binary_add.2"
  %"$38return_value.3" = alloca i64
  store i64 0, i64* %"$38return_value.3"
  br label %"B0"
B0:
  %".7" = load i64, i64* %"a"
  store i64 %"arg.a", i64* %"a"
  %".10" = load i64, i64* %"b"
  store i64 %"arg.b", i64* %"b"
  %".13" = load i8*, i8** %"$const4.1"
  store i8* null, i8** %"$const4.1"
  %".15" = load i64, i64* %"b"
  %".16" = load i8*, i8** %"$const4.1"
  %".18" = load i1, i1* %"$6compare_op.2"
  store i1 0, i1* %"$6compare_op.2"
  %".20" = load i8*, i8** %"$const4.1"
  store i8* null, i8** %"$const4.1"
  %".22" = load i1, i1* %"$6compare_op.2"
  br i1 %".22", label %"B10", label %"B16"
B10:
  %".24" = load i64, i64* %"b"
  store i64 0, i64* %"b"
  %".26" = load i1, i1* %"$6compare_op.2"
  store i1 0, i1* %"$6compare_op.2"
  %".29" = load i64, i64* %"$const10.0"
  store i64 1, i64* %"$const10.0"
  %".31" = load i64, i64* %"$const10.0"
  %".33" = load i64, i64* %"b.1"
  store i64 %".31", i64* %"b.1"
  %".35" = load i64, i64* %"$const10.0"
  store i64 0, i64* %"$const10.0"
  %".37" = load i64, i64* %"b.1"
  %".39" = load i64, i64* %"b.3"
  store i64 1, i64* %"b.3"
  %".41" = load i64, i64* %"b.1"
  store i64 0, i64* %"b.1"
  br label %"B32"
B16:
  %".44" = load i1, i1* %"$6compare_op.2"
  store i1 0, i1* %"$6compare_op.2"
  %".46" = load i64, i64* %"b"
  %".47" = load i64, i64* %"b.3"
  store i64 %".46", i64* %"b.3"
  %".49" = load i64, i64* %"b"
  %".50" = load i64, i64* %"a"
  %".51" = icmp slt i64 %".49", %".50"
  %".53" = load i1, i1* %"$20compare_op.2"
  store i1 %".51", i1* %"$20compare_op.2"
  %".55" = load i1, i1* %"$20compare_op.2"
  br i1 %".55", label %"B24", label %"B32"
B24:
  %".57" = load i1, i1* %"$20compare_op.2"
  store i1 0, i1* %"$20compare_op.2"
  %".60" = load i64, i64* %"$const26.1"
  store i64 1, i64* %"$const26.1"
  %".62" = load i64, i64* %"b"
  %".63" = load i64, i64* %"$const26.1"
  %".64" = add nsw i64 %".62", 1
  %".66" = load i64, i64* %"$28inplace_add.2"
  store i64 %".64", i64* %"$28inplace_add.2"
  %".68" = load i64, i64* %"b"
  store i64 0, i64* %"b"
  %".70" = load i64, i64* %"$const26.1"
  store i64 0, i64* %"$const26.1"
  %".72" = load i64, i64* %"$28inplace_add.2"
  %".74" = load i64, i64* %"b.2"
  store i64 %".72", i64* %"b.2"
  %".76" = load i64, i64* %"$28inplace_add.2"
  store i64 0, i64* %"$28inplace_add.2"
  %".78" = load i64, i64* %"b.2"
  %".79" = load i64, i64* %"b.3"
  store i64 %".78", i64* %"b.3"
  %".81" = load i64, i64* %"b.2"
  store i64 0, i64* %"b.2"
  br label %"B32"
B32:
  %".84" = load i64, i64* %"b"
  store i64 0, i64* %"b"
  %".86" = load i1, i1* %"$20compare_op.2"
  store i1 0, i1* %"$20compare_op.2"
  %".88" = load i64, i64* %"a"
  %".89" = load i64, i64* %"b.3"
  %".90" = add nsw i64 %".88", %".89"
  %".92" = load i64, i64* %"$36binary_add.2"
  store i64 %".90", i64* %"$36binary_add.2"
  %".94" = load i64, i64* %"b.3"
  store i64 0, i64* %"b.3"
  %".96" = load i64, i64* %"a"
  store i64 0, i64* %"a"
  %".98" = load i64, i64* %"$36binary_add.2"
  %".100" = load i64, i64* %"$38return_value.3"
  store i64 %".98", i64* %"$38return_value.3"
  %".102" = load i64, i64* %"$36binary_add.2"
  store i64 0, i64* %"$36binary_add.2"
  %".104" = load i64, i64* %"$38return_value.3"
  store i64 %".104", i64* %"retptr"
  ret i32 0
}

================================================================================
================================================================================
--------------------------FUNCTION OPTIMIZED DUMP foo---------------------------
; ModuleID = 'foo'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__7foo$241Exx" = common global i8* null
@.const.foo = internal constant [4 x i8] c"foo\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@_Py_NoneStruct = external global i8
@PyExc_StopIteration = external global i8
@PyExc_SystemError = external global i8
@".const.unknown error when calling native function" = internal constant [43 x i8] c"unknown error when calling native function\00"
@".const.<numba.core.cpu.CPUContext object at 0x7f979fe45e80>" = internal constant [53 x i8] c"<numba.core.cpu.CPUContext object at 0x7f979fe45e80>\00"
@".const.unknown error when calling native function.1" = internal constant [43 x i8] c"unknown error when calling native function\00"

define i32 @"_ZN8__main__7foo$241Exx"(i64* noalias nocapture %retptr, { i8*, i32 }** noalias nocapture %excinfo, i64 %arg.a, i64 %arg.b) {
entry:
  br i1 false, label %B10, label %B16

B10:                                              ; preds = %entry
  br label %B32

B16:                                              ; preds = %entry
  %.51 = icmp slt i64 %arg.b, %arg.a
  br i1 %.51, label %B24, label %B32

B24:                                              ; preds = %B16
  %.64 = add nsw i64 %arg.b, 1
  br label %B32

B32:                                              ; preds = %B24, %B16, %B10
  %b.3.0 = phi i64 [ 1, %B10 ], [ %.64, %B24 ], [ %arg.b, %B16 ]
  %.90 = add nsw i64 %arg.a, %b.3.0
  store i64 %.90, i64* %retptr
  ret i32 0
}

define i8* @"_ZN7cpython8__main__7foo$241Exx"(i8* %py_closure, i8* %py_args, i8* %py_kws) {
entry:
  %.5 = alloca i8*
  %.6 = alloca i8*
  %.7 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.const.foo, i32 0, i32 0), i64 2, i64 2, i8** %.5, i8** %.6)
  %.8 = icmp eq i32 %.7, 0
  %.53 = alloca i64
  store i64 0, i64* %.53
  %excinfo = alloca { i8*, i32 }*
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo
  br i1 %.8, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif.endif.endif.endif.if.if, %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif, %entry.endif.endif.endif.e...if, %entry.endif.endif.endif.e...endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.12 = load i8*, i8** @"_ZN08NumbaEnv8__main__7foo$241Exx"
  %.13 = ptrtoint i8* %.12 to i64
  %.14 = add i64 %.13, 16
  %.15 = inttoptr i64 %.14 to i8*
  %.17 = icmp eq i8* null, %.12
  br i1 %.17, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i32 0, i32 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.21 = load i8*, i8** %.5
  %.24 = call i8* @PyNumber_Long(i8* %.21)
  %.25 = icmp ne i8* null, %.24
  br i1 %.25, label %entry.endif.endif.if, label %entry.endif.endif.endif, !prof !1

entry.endif.endif.if:                             ; preds = %entry.endif.endif
  %.27 = call i64 @PyLong_AsLongLong(i8* %.24)
  call void @Py_DecRef(i8* %.24)
  br label %entry.endif.endif.endif

entry.endif.endif.endif:                          ; preds = %entry.endif.endif.if, %entry.endif.endif
  %.22.0 = phi i64 [ %.27, %entry.endif.endif.if ], [ 0, %entry.endif.endif ]
  %.32 = call i8* @PyErr_Occurred()
  %.33 = icmp ne i8* null, %.32
  br i1 %.33, label %entry.if, label %entry.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  %.37 = load i8*, i8** %.6
  %.40 = call i8* @PyNumber_Long(i8* %.37)
  %.41 = icmp ne i8* null, %.40
  br i1 %.41, label %entry.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif, !prof !1

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.43 = call i64 @PyLong_AsLongLong(i8* %.40)
  call void @Py_DecRef(i8* %.40)
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif
  %.38.0 = phi i64 [ %.43, %entry.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif ]
  %.48 = call i8* @PyErr_Occurred()
  %.49 = icmp ne i8* null, %.48
  br i1 %.49, label %entry.if, label %entry.endif.endif.endif.endif.endif.endif, !prof !0

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  store i64 0, i64* %.53
  %.57 = call i32 @"_ZN8__main__7foo$241Exx"(i64* %.53, { i8*, i32 }** %excinfo, i64 %.22.0, i64 %.38.0)
  %.58 = load { i8*, i32 }*, { i8*, i32 }** %excinfo
  %.59 = icmp eq i32 %.57, 0
  %.60 = icmp eq i32 %.57, -2
  %.63 = or i1 %.59, %.60
  %.65 = icmp sge i32 %.57, 1
  %.67 = load i64, i64* %.53
  switch i32 %.57, label %entry.endif.endif.endif.endif.endif.endif.endif [
    i32 -2, label %entry.endif.endif.endif.endif.endif.endif.if
    i32 0, label %entry.endif.endif.endif.endif.endif.endif.if
  ]

entry.endif.endif.endif.endif.endif.endif.if:     ; preds = %entry.endif.endif.endif.endif.endif.endif, %entry.endif.endif.endif.endif.endif.endif
  br i1 %.60, label %entry.endif.endif.endif.endif.endif.endif.if.if, label %entry.endif.endif.endif.endif.endif.endif.if.endif

entry.endif.endif.endif.endif.endif.endif.endif:  ; preds = %entry.endif.endif.endif.endif.endif.endif
  br i1 %.65, label %entry.endif.endif.endif.endif.endif.endif.endif.if, label %entry.endif.endif.endif.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif.endif.if.if:  ; preds = %entry.endif.endif.endif.endif.endif.endif.if
  call void @Py_IncRef(i8* @_Py_NoneStruct)
  ret i8* @_Py_NoneStruct

entry.endif.endif.endif.endif.endif.endif.if.endif: ; preds = %entry.endif.endif.endif.endif.endif.endif.if
  %.74 = call i8* @PyLong_FromLongLong(i64 %.67)
  ret i8* %.74

entry.endif.endif.endif.endif.endif.endif.endif.if: ; preds = %entry.endif.endif.endif.endif.endif.endif.endif
  call void @PyErr_Clear()
  %.81 = load { i8*, i32 }, { i8*, i32 }* %.58
  %.82 = extractvalue { i8*, i32 } %.81, 0
  %.84 = extractvalue { i8*, i32 } %.81, 1
  %.85 = call i8* @numba_unpickle(i8* %.82, i32 %.84)
  %.86 = icmp ne i8* null, %.85
  br i1 %.86, label %entry.endif.endif.endif.endif.endif.endif.endif.if.if, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif.endif.endif.endif: ; preds = %entry.endif.endif.endif.endif.endif.endif.endif
  switch i32 %.57, label %entry.endif.endif.endif.e...endif.endif [
    i32 -3, label %entry.endif.endif.endif.e...if
    i32 -1, label %entry.if
  ]

entry.endif.endif.endif.endif.endif.endif.endif.if.if: ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.if
  call void @numba_do_raise(i8* %.85)
  br label %entry.if

entry.endif.endif.endif.e...if:                   ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif
  call void @PyErr_SetNone(i8* @PyExc_StopIteration)
  br label %entry.if

entry.endif.endif.endif.e...endif.endif:          ; preds = %entry.endif.endif.endif.endif.endif.endif.endif.endif
  call void @PyErr_SetString(i8* @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function", i32 0, i32 0))
  br label %entry.if
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...)

declare void @PyErr_SetString(i8*, i8*)

declare i8* @PyNumber_Long(i8*)

declare i64 @PyLong_AsLongLong(i8*)

declare void @Py_DecRef(i8*)

declare i8* @PyErr_Occurred()

declare void @Py_IncRef(i8*)

declare i8* @PyLong_FromLongLong(i64)

declare void @PyErr_Clear()

declare i8* @numba_unpickle(i8*, i32)

declare void @numba_do_raise(i8*)

declare void @PyErr_SetNone(i8*)

define i64 @"cfunc._ZN8__main__7foo$241Exx"(i64 %.1, i64 %.2) {
entry:
  %.4 = alloca i64
  store i64 0, i64* %.4
  %excinfo = alloca { i8*, i32 }*
  store { i8*, i32 }* null, { i8*, i32 }** %excinfo
  %.8 = call i32 @"_ZN8__main__7foo$241Exx"(i64* %.4, { i8*, i32 }** %excinfo, i64 %.1, i64 %.2)
  %.9 = load { i8*, i32 }*, { i8*, i32 }** %excinfo
  %.10 = icmp eq i32 %.8, 0
  %.11 = icmp eq i32 %.8, -2
  %.14 = or i1 %.10, %.11
  %.15 = xor i1 %.14, true
  %.16 = icmp sge i32 %.8, 1
  %.18 = load i64, i64* %.4
  %.20 = alloca i32
  store i32 0, i32* %.20
  br i1 %.15, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry
  call void @numba_gil_ensure(i32* %.20)
  br i1 %.16, label %entry.if.if, label %entry.if.endif

entry.endif:                                      ; preds = %.23, %entry
  ret i64 %.18

.23:                                              ; preds = %entry.if.endif, %entry.if.if, %entry.if.if.if, %entry.if.endif.endif.endif, %entry.if.endif.if
  %.43 = call i8* @PyUnicode_FromString(i8* getelementptr inbounds ([53 x i8], [53 x i8]* @".const.<numba.core.cpu.CPUContext object at 0x7f979fe45e80>", i32 0, i32 0))
  call void @PyErr_WriteUnraisable(i8* %.43)
  call void @Py_DecRef(i8* %.43)
  call void @numba_gil_release(i32* %.20)
  br label %entry.endif

entry.if.if:                                      ; preds = %entry.if
  call void @PyErr_Clear()
  %.26 = load { i8*, i32 }, { i8*, i32 }* %.9
  %.27 = extractvalue { i8*, i32 } %.26, 0
  %.29 = extractvalue { i8*, i32 } %.26, 1
  %.30 = call i8* @numba_unpickle(i8* %.27, i32 %.29)
  %.31 = icmp ne i8* null, %.30
  br i1 %.31, label %entry.if.if.if, label %.23, !prof !1

entry.if.endif:                                   ; preds = %entry.if
  switch i32 %.8, label %entry.if.endif.endif.endif [
    i32 -3, label %entry.if.endif.if
    i32 -1, label %.23
  ]

entry.if.if.if:                                   ; preds = %entry.if.if
  call void @numba_do_raise(i8* %.30)
  br label %.23

entry.if.endif.if:                                ; preds = %entry.if.endif
  call void @PyErr_SetNone(i8* @PyExc_StopIteration)
  br label %.23

entry.if.endif.endif.endif:                       ; preds = %entry.if.endif
  call void @PyErr_SetString(i8* @PyExc_SystemError, i8* getelementptr inbounds ([43 x i8], [43 x i8]* @".const.unknown error when calling native function.1", i32 0, i32 0))
  br label %.23
}

declare void @numba_gil_ensure(i32*)

declare i8* @PyUnicode_FromString(i8*)

declare void @PyErr_WriteUnraisable(i8*)

declare void @numba_gil_release(i32*)

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
-------------------------------OPTIMIZED DUMP foo-------------------------------
; ModuleID = 'foo'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@"_ZN08NumbaEnv8__main__7foo$241Exx" = common local_unnamed_addr global i8* null
@.const.foo = internal constant [4 x i8] c"foo\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"

; Function Attrs: norecurse nounwind writeonly
define i32 @"_ZN8__main__7foo$241Exx"(i64* noalias nocapture %retptr, { i8*, i32 }** noalias nocapture readnone %excinfo, i64 %arg.a, i64 %arg.b) local_unnamed_addr #0 {
entry:
  %.51 = icmp slt i64 %arg.b, %arg.a
  %.64 = zext i1 %.51 to i64
  %b.3.0 = add i64 %arg.b, %arg.a
  %.90 = add i64 %b.3.0, %.64
  store i64 %.90, i64* %retptr, align 8
  ret i32 0
}

define i8* @"_ZN7cpython8__main__7foo$241Exx"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.const.foo, i64 0, i64 0), i64 2, i64 2, i8** nonnull %.5, i8** nonnull %.6)
  %.8 = icmp eq i32 %.7, 0
  br i1 %.8, label %entry.if, label %entry.endif, !prof !0

entry.if:                                         ; preds = %entry.endif.endif.endif.endif.endif, %entry.endif.endif.endif, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.12 = load i8*, i8** @"_ZN08NumbaEnv8__main__7foo$241Exx", align 8
  %.17 = icmp eq i8* %.12, null
  br i1 %.17, label %entry.endif.if, label %entry.endif.endif, !prof !0

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.21 = load i8*, i8** %.5, align 8
  %.24 = call i8* @PyNumber_Long(i8* %.21)
  %.25 = icmp eq i8* %.24, null
  br i1 %.25, label %entry.endif.endif.endif, label %entry.endif.endif.if, !prof !0

entry.endif.endif.if:                             ; preds = %entry.endif.endif
  %.27 = call i64 @PyLong_AsLongLong(i8* nonnull %.24)
  call void @Py_DecRef(i8* nonnull %.24)
  br label %entry.endif.endif.endif

entry.endif.endif.endif:                          ; preds = %entry.endif.endif, %entry.endif.endif.if
  %.22.0 = phi i64 [ %.27, %entry.endif.endif.if ], [ 0, %entry.endif.endif ]
  %.32 = call i8* @PyErr_Occurred()
  %.33 = icmp eq i8* %.32, null
  br i1 %.33, label %entry.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif.endif
  %.37 = load i8*, i8** %.6, align 8
  %.40 = call i8* @PyNumber_Long(i8* %.37)
  %.41 = icmp eq i8* %.40, null
  br i1 %.41, label %entry.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.if, !prof !0

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.43 = call i64 @PyLong_AsLongLong(i8* nonnull %.40)
  call void @Py_DecRef(i8* nonnull %.40)
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif, %entry.endif.endif.endif.endif.if
  %.38.0 = phi i64 [ %.43, %entry.endif.endif.endif.endif.if ], [ 0, %entry.endif.endif.endif.endif ]
  %.48 = call i8* @PyErr_Occurred()
  %.49 = icmp eq i8* %.48, null
  br i1 %.49, label %entry.endif.endif.endif.endif.endif.endif, label %entry.if, !prof !1

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.51.i = icmp slt i64 %.38.0, %.22.0
  %.64.i = zext i1 %.51.i to i64
  %b.3.0.i = add i64 %.38.0, %.22.0
  %.90.i = add i64 %b.3.0.i, %.64.i
  %.74 = call i8* @PyLong_FromLongLong(i64 %.90.i)
  ret i8* %.74
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i8* @PyNumber_Long(i8*) local_unnamed_addr

declare i64 @PyLong_AsLongLong(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyLong_FromLongLong(i64) local_unnamed_addr

; Function Attrs: norecurse nounwind readnone
define i64 @"cfunc._ZN8__main__7foo$241Exx"(i64 %.1, i64 %.2) local_unnamed_addr #1 {
entry:
  %.51.i = icmp slt i64 %.2, %.1
  %.64.i = zext i1 %.51.i to i64
  %b.3.0.i = add i64 %.2, %.1
  %.90.i = add i64 %b.3.0.i, %.64.i
  ret i64 %.90.i
}

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #2

attributes #0 = { norecurse nounwind writeonly }
attributes #1 = { norecurse nounwind readnone }
attributes #2 = { nounwind }

!0 = !{!"branch_weights", i32 1, i32 99}
!1 = !{!"branch_weights", i32 99, i32 1}

================================================================================
================================================================================
----------------------------------ASSEMBLY foo----------------------------------
        .text
        .file   "<string>"
        .globl  _ZN8__main__7foo$241Exx
        .p2align        4, 0x90
        .type   _ZN8__main__7foo$241Exx,@function
_ZN8__main__7foo$241Exx:
        xorl    %eax, %eax
        cmpq    %rdx, %rcx
        setl    %al
        addq    %rdx, %rcx
        addq    %rax, %rcx
        movq    %rcx, (%rdi)
        xorl    %eax, %eax
        retq
.Lfunc_end0:
        .size   _ZN8__main__7foo$241Exx, .Lfunc_end0-_ZN8__main__7foo$241Exx

        .globl  _ZN7cpython8__main__7foo$241Exx
        .p2align        4, 0x90
        .type   _ZN7cpython8__main__7foo$241Exx,@function
_ZN7cpython8__main__7foo$241Exx:
        .cfi_startproc
        pushq   %r15
        .cfi_def_cfa_offset 16
        pushq   %r14
        .cfi_def_cfa_offset 24
        pushq   %r12
        .cfi_def_cfa_offset 32
        pushq   %rbx
        .cfi_def_cfa_offset 40
        subq    $24, %rsp
        .cfi_def_cfa_offset 64
        .cfi_offset %rbx, -40
        .cfi_offset %r12, -32
        .cfi_offset %r14, -24
        .cfi_offset %r15, -16
        movq    %rsi, %rdi
        movabsq $.const.foo, %rsi
        movabsq $PyArg_UnpackTuple, %rbx
        leaq    16(%rsp), %r8
        leaq    8(%rsp), %r9
        movl    $2, %edx
        movl    $2, %ecx
        xorl    %eax, %eax
        callq   *%rbx
        testl   %eax, %eax
        je      .LBB1_1
        movabsq $_ZN08NumbaEnv8__main__7foo$241Exx, %rax
        cmpq    $0, (%rax)
        je      .LBB1_4
        movq    16(%rsp), %rdi
        movabsq $PyNumber_Long, %r15
        callq   *%r15
        testq   %rax, %rax
        je      .LBB1_6
        movq    %rax, %rbx
        movabsq $PyLong_AsLongLong, %rax
        movq    %rbx, %rdi
        callq   *%rax
        movq    %rax, %r14
        movabsq $Py_DecRef, %rax
        movq    %rbx, %rdi
        callq   *%rax
        movabsq $PyErr_Occurred, %r12
        callq   *%r12
        testq   %rax, %rax
        jne     .LBB1_1
.LBB1_9:
        movq    8(%rsp), %rdi
        callq   *%r15
        testq   %rax, %rax
        je      .LBB1_10
        movq    %rax, %r15
        movabsq $PyLong_AsLongLong, %rax
        movq    %r15, %rdi
        callq   *%rax
        movq    %rax, %rbx
        movabsq $Py_DecRef, %rax
        movq    %r15, %rdi
        callq   *%rax
        callq   *%r12
        testq   %rax, %rax
        jne     .LBB1_1
.LBB1_13:
        xorl    %eax, %eax
        cmpq    %r14, %rbx
        setl    %al
        addq    %r14, %rbx
        addq    %rax, %rbx
        movabsq $PyLong_FromLongLong, %rax
        movq    %rbx, %rdi
        callq   *%rax
.LBB1_2:
        addq    $24, %rsp
        .cfi_def_cfa_offset 40
        popq    %rbx
        .cfi_def_cfa_offset 32
        popq    %r12
        .cfi_def_cfa_offset 24
        popq    %r14
        .cfi_def_cfa_offset 16
        popq    %r15
        .cfi_def_cfa_offset 8
        retq
.LBB1_4:
        .cfi_def_cfa_offset 64
        movabsq $PyExc_RuntimeError, %rdi
        movabsq $".const.missing Environment", %rsi
        movabsq $PyErr_SetString, %rax
        callq   *%rax
.LBB1_1:
        xorl    %eax, %eax
        jmp     .LBB1_2
.LBB1_6:
        xorl    %r14d, %r14d
        movabsq $PyErr_Occurred, %r12
        callq   *%r12
        testq   %rax, %rax
        je      .LBB1_9
        jmp     .LBB1_1
.LBB1_10:
        xorl    %ebx, %ebx
        callq   *%r12
        testq   %rax, %rax
        je      .LBB1_13
        jmp     .LBB1_1
.Lfunc_end1:
        .size   _ZN7cpython8__main__7foo$241Exx, .Lfunc_end1-_ZN7cpython8__main__7foo$241Exx
        .cfi_endproc

        .globl  cfunc._ZN8__main__7foo$241Exx
        .p2align        4, 0x90
        .type   cfunc._ZN8__main__7foo$241Exx,@function
cfunc._ZN8__main__7foo$241Exx:
        xorl    %ecx, %ecx
        cmpq    %rdi, %rsi
        setl    %cl
        leaq    (%rsi,%rdi), %rax
        addq    %rcx, %rax
        retq
.Lfunc_end2:
        .size   cfunc._ZN8__main__7foo$241Exx, .Lfunc_end2-cfunc._ZN8__main__7foo$241Exx

        .type   _ZN08NumbaEnv8__main__7foo$241Exx,@object
        .comm   _ZN08NumbaEnv8__main__7foo$241Exx,8,8
        .type   .const.foo,@object
        .section        .rodata,"a",@progbits
.const.foo:
        .asciz  "foo"
        .size   .const.foo, 4

        .type   ".const.missing Environment",@object
        .p2align        4
".const.missing Environment":
        .asciz  "missing Environment"
        .size   ".const.missing Environment", 20


        .section        ".note.GNU-stack","",@progbits

================================================================================
3
4
----------------------------------IR DUMP: foo----------------------------------
label 0:
    a = arg(0, name=a)                       ['a']
    b = arg(1, name=b)                       ['b']
    $const4.1 = const(NoneType, None)        ['$const4.1']
    $6compare_op.2 = b is $const4.1          ['$6compare_op.2', '$const4.1', 'b']
    branch $6compare_op.2, 10, 16            ['$6compare_op.2']
label 10:
    $const10.0 = const(int, 1)               ['$const10.0']
    b = $const10.0                           ['$const10.0', 'b']
    jump 32                                  []
label 16:
    $20compare_op.2 = b < a                  ['$20compare_op.2', 'a', 'b']
    branch $20compare_op.2, 24, 32           ['$20compare_op.2']
label 24:
    $const26.1 = const(int, 1)               ['$const26.1']
    $28inplace_add.2 = inplace_binop(fn=<built-in function iadd>, immutable_fn=<built-in function add>, lhs=b, rhs=$const26.1, static_lhs=Undefined, static_rhs=Undefined) ['$28inplace_add.2', '$const26.1', 'b']
    b = $28inplace_add.2                     ['$28inplace_add.2', 'b']
    jump 32                                  []
label 32:
    $36binary_add.2 = a + b                  ['$36binary_add.2', 'a', 'b']
    $38return_value.3 = cast(value=$36binary_add.2) ['$36binary_add.2', '$38return_value.3']
    return $38return_value.3                 ['$38return_value.3']

----------------------------------IR DUMP: foo----------------------------------
label 0:
    a = arg(0, name=a)                       ['a']
    b = arg(1, name=b)                       ['b']
    $const4.1 = const(NoneType, None)        ['$const4.1']
    $6compare_op.2 = b is $const4.1          ['$6compare_op.2', '$const4.1', 'b']
    branch $6compare_op.2, 10, 16            ['$6compare_op.2']
label 10:
    $const10.0 = const(int, 1)               ['$const10.0']
    b = $const10.0                           ['$const10.0', 'b']
    jump 32                                  []
label 16:
    $20compare_op.2 = b < a                  ['$20compare_op.2', 'a', 'b']
    branch $20compare_op.2, 24, 32           ['$20compare_op.2']
label 24:
    $const26.1 = const(int, 1)               ['$const26.1']
    $28inplace_add.2 = inplace_binop(fn=<built-in function iadd>, immutable_fn=<built-in function add>, lhs=b, rhs=$const26.1, static_lhs=Undefined, static_rhs=Undefined) ['$28inplace_add.2', '$const26.1', 'b']
    b = $28inplace_add.2                     ['$28inplace_add.2', 'b']
    jump 32                                  []
label 32:
    $36binary_add.2 = a + b                  ['$36binary_add.2', 'a', 'b']
    $38return_value.3 = cast(value=$36binary_add.2) ['$36binary_add.2', '$38return_value.3']
    return $38return_value.3                 ['$38return_value.3']

-----------------------------------propagate------------------------------------
---- type variables ----
[$28inplace_add.2 := <undecided>,
 $36binary_add.2 := int64,
 $38return_value.3 := int64,
 $6compare_op.2 := bool,
 $const10.0 := Literal[int](1),
 $const26.1 := Literal[int](1),
 $const4.1 := none,
 a := int64,
 arg.a := int64,
 arg.b := omitted(default=None),
 b := none,
 b.1 := Literal[int](1),
 b.2 := <undecided>,
 b.3 := OptionalType(int64) i.e. the type 'int64 or None']
-----------------------------------propagate------------------------------------
---- type variables ----
[$28inplace_add.2 := <undecided>,
 $36binary_add.2 := int64,
 $38return_value.3 := int64,
 $6compare_op.2 := bool,
 $const10.0 := Literal[int](1),
 $const26.1 := Literal[int](1),
 $const4.1 := none,
 a := int64,
 arg.a := int64,
 arg.b := omitted(default=None),
 b := none,
 b.1 := Literal[int](1),
 b.2 := <undecided>,
 b.3 := OptionalType(int64) i.e. the type 'int64 or None']
Traceback (most recent call last):
  File "fail_numba.py", line 19, in <module>
    print(foo(1))
  File "/home/juanlu/.pyenv/versions/poliastro38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/juanlu/.pyenv/versions/poliastro38/lib/python3.8/site-packages/numba/core/dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "/home/juanlu/.pyenv/versions/poliastro38/lib/python3.8/site-packages/numba/core/utils.py", line 79, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function lt>) with argument(s) of type(s): (none, int64)
Known signatures:
 * (bool, bool) -> bool
 * (int8, int8) -> bool
 * (int16, int16) -> bool
 * (int32, int32) -> bool
 * (int64, int64) -> bool
 * (uint8, uint8) -> bool
 * (uint16, uint16) -> bool
 * (uint32, uint32) -> bool
 * (uint64, uint64) -> bool
 * (float32, float32) -> bool
 * (float64, float64) -> bool
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
In definition 10:
    All templates rejected with literals.
In definition 11:
    All templates rejected without literals.
In definition 12:
    All templates rejected with literals.
In definition 13:
    All templates rejected without literals.
In definition 14:
    All templates rejected with literals.
In definition 15:
    All templates rejected without literals.
In definition 16:
    All templates rejected with literals.
In definition 17:
    All templates rejected without literals.
In definition 18:
    All templates rejected with literals.
In definition 19:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of intrinsic-call at fail_numba.py (8)

File "fail_numba.py", line 8:
def foo(a, b=None):
    <source elided>
        b = 1
    elif b < a:
    ^

```
</details>
user: astrojuanlu
labels: SSA: Problem due to SSA (or lack of)
issue_5655: state: open
title: Respect PEP 3102 keyword-only arguments in nopython mode
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Keyword-only arguments work fine in nopython mode:

```
In [1]: from numba import njit                                                                                                                                                                                                                

In [2]: def f(a, *, b): 
   ...:     return a * b 
   ...:                                                                                                                                                                                                                                       

In [3]: f(1, b=2)                                                                                                                                                                                                                             
Out[3]: 2

In [4]: f(1, 2)                                                                                                                                                                                                                               
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-c9c271413adf> in <module>
----> 1 f(1, 2)

TypeError: f() takes 1 positional argument but 2 were given

In [5]: nf = njit(f)                                                                                                                                                                                                                          

In [6]: nf(1, b=2)                                                                                                                                                                                                                            
Out[6]: 2
```

However, I expected `nf(1, 2)` to fail in the same way as `f(1, 2)`, but it doesn't:

```
In [7]: nf(1, 2)                                                                                                                                                                                                                              
Out[7]: 2
```

(perhaps related to #2994?)
user: astrojuanlu
issue_5654: state: open
title: can not use numpy.max as funtion parameter
body: _

```
import numpy as np
from numba import typeof, types, njit, jit

@njit()
def as_rolling_apply(fun, array, w):
    r = np.empty(array.shape)
    r.fill(np.nan)
    for i in range(w - 1, array.shape[0]):
        for j in range(array.shape[1]):
            r[i][j] = fun(array[(i-w+1):i+1, j])
    return r

arrayUse = np.random.random([250,3000])
as_rolling_apply(np.max, arrayUse, 5)
```

_


**when I use np.max as the first parameter, I get the Error**


```
>   File "<ipython-input-13-dc6174d8fde4>", line 1, in <module>
>     as_rolling_apply(np.max, arrayUse, 5)
> 
>   File "C:\ProgramData\Anaconda2\envs\py_36\lib\site-packages\numba\core\dispatcher.py", line 401, in _compile_for_args
>     error_rewrite(e, 'typing')
> 
>   File "C:\ProgramData\Anaconda2\envs\py_36\lib\site-packages\numba\core\dispatcher.py", line 344, in error_rewrite
>     reraise(type(e), e, None)
> 
>   File "C:\ProgramData\Anaconda2\envs\py_36\lib\site-packages\numba\core\utils.py", line 79, in reraise
>     raise value.with_traceback(tb)
> 
> TypingError: non-precise type pyobject
> [1] During: typing of argument at ***.py (40)
```

user: kukuwa
issue_5650: state: open
title: Create integer from unicode string with int()
body: I am trying to convert a unicode string to an integer like this:

```
import numba

@numba.jit(nopython=True)
def str_to_int(str_date):
	return int(str_date[0:4])

print(str_to_int("2016 foo bar"))
```

and receive the following error:

```
Invalid use of Function(<class 'int'>) with argument(s) of type(s): (unicode_type)
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<class 'int'>)
[2] During: typing of call at numba-bug.py (5)


File "numba-bug.py", line 5:
def str_to_int(str_date):
	return int(str_date[0:4])
```


I have also tried to replace the `int(str_date[0:4])` with `int(str_date[0]) * 1000 + int(str_date[1]) * 100 + int(str_date[2]) * 10 + int(str_date[3])` but the same error appears.

Is this a real bug or am I using the library wrong? Unfortunately I was unable to find more info on substring handling in the docs. Thank you!
user: bf
issue_5641: state: open
title: About enabling jit-decorated functions as first-class functions when using in sequences
body: Currently, the jit-decorated functions are not treated as first-class functions when used in Python sequences such as tuple. The feature was disabled in PR #5473 to fix a regression #5470 .

After some thought, I think the regression is effective only for jit-decorated functions that are passed to a jitted function via namespace scoping but not for functions that are passed in via the function arguments.

So, if there would exist a reliable way to tell if a function is an argument rather than a global variable inside https://github.com/numba/numba/blob/1873621f1a4a53520c5e8b9f6604e7c55bdf90da/numba/core/utils.py#L475 or in the scope of calling the function `unified_function_type` then it should be possible to enable the first-class function support for jit-decorated functions in the argument passing cases.
user: pearu
issue_5640: state: open
title: guvectorize-CUDA broadcast fail
body: v0.49.0

A guvectorized function fails to broadcast when the target is CUDA but works as expected when the target is CPU.

```python
from numba import guvectorize
import numpy as np

def dot(a, b, result):
    x = 0

    for i in range(len(a)):
        x += a[i] * b[i]

    result[0] = x


args = "int64[:], int64[:], int64[:]", "(n),(n)->()"
dot_cuda = guvectorize(*args, target="cuda")(dot)
dot_cpu = guvectorize(*args)(dot)

a = np.arange(6).reshape(3, 1, 2)
b = np.arange(8).reshape(1, 4, 2)

dot_cuda(a, b)
```
```
ValueError                                Traceback (most recent call last)
<ipython-input-5-2b6f351e5aeb> in <module>
----> 1 dot_cuda(a, b)

~/miniconda/envs/x/lib/python3.8/site-packages/numba/np/ufunc/deviceufunc.py in __call__(self, *args, **kws)
    648                                      args, kws)
    649         callsteps.prepare_inputs()
--> 650         indtypes, schedule, outdtype, kernel = self._schedule(
    651             callsteps.norm_inputs, callsteps.output)
    652         callsteps.adjust_input_types(indtypes)

~/miniconda/envs/x/lib/python3.8/site-packages/numba/np/ufunc/deviceufunc.py in _schedule(self, inputs, out)
    661     def _schedule(self, inputs, out):
    662         input_shapes = [a.shape for a in inputs]
--> 663         schedule = self.engine.schedule(input_shapes)
    664 
    665         # find kernel

~/miniconda/envs/x/lib/python3.8/site-packages/numba/np/ufunc/deviceufunc.py in schedule(self, ishapes)
    610                 else:
    611                     fmt = "arg #%d: outer dimension mismatch"
--> 612                     raise ValueError(fmt % (i + 1,))
    613 
    614         return GUFuncSchedule(self, inner_shapes, oshapes, loopdims, pinned)

ValueError: arg #1: outer dimension mismatch
```
numba.np.ufunc.deviceufunc.GUFuncEngine.schedule locals:
```python
{'self': <numba.np.ufunc.deviceufunc.GUFuncEngine object at 0x7f9c10c11400>,
 'ishapes': [(3, 1, 2), (1, 4, 2)],
 'symbolmap': {'n': 2},
 'outer_shapes': [(3, 1), (1, 4)],
 'inner_shapes': [(2,), (2,)],
 'argn': 2,
 'shape': (1, 4, 2),
 'symbols': ('n',),
 'inner_ndim': 1,
 'fmt': 'arg #%d: outer dimension mismatch',
 'inner_shape': (2,),
 'outer_shape': (1, 4),
 'axis': 2,
 'dim': 2,
 'sym': 'n',
 'oshapes': [()],
 'outsig': (),
 'oshape': [],
 'sizes': [3, 4],
 'largest_i': 1,
 'loopdims': (1, 4),
 'pinned': [False, False],
 'i': 0,
 'd': (3, 1)}
```
Works as expected when the target is CPU:
```python
dot_cpu(a, b)
```
```
array([[ 1,  3,  5,  7],
       [ 3, 13, 23, 33],
       [ 5, 23, 41, 59]])
```
user: nre
labels: CUDA: CUDA related issue/PR
issue_5621: state: open
title: Nested prange regression in 0.49
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Here is the script to demonstrate the regression:
``` python3
import numba as nb
import numpy as np

@nb.njit(parallel=True)
def make_row(a, b, row_data):
    for col in nb.prange(len(b)):
        row_data[col] = a * b[col]

@nb.njit(parallel=True)
def make_product(a, b):
    matrix = np.zeros((len(a), len(b)))
    for row in nb.prange(len(a)):
        make_row(a[row], b, matrix[row])
    return matrix

if __name__ == '__main__':
    a = np.random.random(1000000)
    b = np.random.random(100)
    m = make_product(a, b)
```
In command line I set environment variable `NUMBA_NUM_THREADS=2` to limit the number of thread to 2. When I run the script it pegs all 6 cores for 276 seconds. It seems the multithreading doesn't honor the `NUMBA_NUM_THREADS` environment variable. I run the same code with numba 0.48 and it finishes in 2.26 seconds using 2 cores, which is expected.

I have several related observations too, hope they could help a bit:

* If I "inline" the `make_row` by copy-paste the code into the call site, the code runs fast (no performance regression comparing to 0.48).
* If I flip the `a` and `b` in the call to `make_product`, the code runs fast.
* If I set `NUMBA_NUM_THREADS=1`, the code runs fast but it takes about 3x the time comparing to 0.48.

I run the code in a Ubuntu 18.04 VM. I use conda environments to run the code. One has numba 0.49 and the other has numba 0.48. I have tbb package in both environments. Python version is 3.7.7.
user: wenjuno
labels: threading: Issue involving the threading layers
performance - run time: Performance issue occurring at run time.
issue_5611: state: open
title: Control flow graph algorithm error when using many ternary operations
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
```python
from numba import njit
import numpy as np


def generate_code(count):
    base_code = """
    dependency_{index} = 1 if True else 0
    value_{index} = x if dependendency_{index} else 0"""

    code = """
@njit
def template(x):"""
    for i in range(count):
        code += base_code.format(**{'index': i})
    return code

if __name__ == '__main__':
    import sys
    import time

    count = int(sys.argv[1])

    exec(generate_code(count), globals(), locals())
    start = time.time()
    template(32)
    end = time.time()
    print(end - start, 'elapsed')
```
When running the above code with count > 200, the growth in compilation time appears to grow exponentially based on the control flow graph search.  @stuartarchibald suggested that the recursive algorithm would likely need to be replaced with an iterative one as "the amount of time it takes to analyse the CFG would be to some degree proportional to the number of [if] blocks."  When run with sufficiently large count > 10000, the following error is produced:

```python
  File "/***/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 420, in _compile_for_args
    raise e
  File "/***/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/***/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 794, in compile
    cres = self._compiler.compile(args, return_type)
  File "/***/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/***/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/***/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 104, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 568, in compile_extra
    return pipeline.compile_extra(func)
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 339, in compile_extra
    return self._compile_bytecode()
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 401, in _compile_bytecode
    return self._compile_core()
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 381, in _compile_core
    raise e
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler.py", line 372, in _compile_core
    pm.run(self.state)
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 341, in run
    raise patched_exception
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 332, in run
    self._runPass(idx, pass_inst, state)
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 291, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/***/.local/lib/python3.8/site-packages/numba/core/compiler_machinery.py", line 264, in check
    mangled = func(compiler_state)
  File "/***/.local/lib/python3.8/site-packages/numba/core/untyped_passes.py", line 86, in run_pass
    func_ir = interp.interpret(bc)
  File "/***/.local/lib/python3.8/site-packages/numba/core/interpreter.py", line 116, in interpret
    flow.run()
  File "/***/.local/lib/python3.8/site-packages/numba/core/byteflow.py", line 141, in run
    self._build_cfg(runner.finished)
  File "/***/.local/lib/python3.8/site-packages/numba/core/byteflow.py", line 158, in _build_cfg
    graph.process()
  File "/***/.local/lib/python3.8/site-packages/numba/core/controlflow.py", line 125, in process
    self._find_topo_order()
  File "/***/.local/lib/python3.8/site-packages/numba/core/controlflow.py", line 537, in _find_topo_order
    _dfs_rec(self._entry_point)
  File "/***/.local/lib/python3.8/site-packages/numba/core/controlflow.py", line 534, in _dfs_rec
    _dfs_rec(dest)
  File "/***/.local/lib/python3.8/site-packages/numba/core/controlflow.py", line 534, in _dfs_rec
    _dfs_rec(dest)
  File "/***/.local/lib/python3.8/site-packages/numba/core/controlflow.py", line 534, in _dfs_rec
    _dfs_rec(dest)
  [Previous line repeated 970 more times]
  File "/***/.local/lib/python3.8/site-packages/numba/core/controlflow.py", line 531, in _dfs_rec
    seen.add(node)
RecursionError: Failed in nopython mode pipeline (step: analyzing bytecode)
maximum recursion depth exceeded while calling a Python object
```
user: lespaul
issue_5608: state: open
title: Typecode drift
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

From https://github.com/numba/numba/pull/5579#issuecomment-617371499

Reproducer:

```python
from numba import njit, types, typeof


@njit
def foo1(x):
    return x + 1

@njit
def foo2(x):
    return x + 2


c1 = typeof((foo1, foo2))._code
c2 = typeof((foo1, foo2))._code

assert c1 == c2
```

user: sklam
issue_5603: state: open
title: Numba List fails with differently named functions (even if signatures match)
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I am attempting to use the first-class function support which I believe is included in the latest release.

In the following case, I can create a `numba` `List` containing two copies (duplicate) of a function and all works as intended.

Once I try the same with two differently named functions -- but with the same signature -- it no longer works and typing issues are thrown:

```python
from numba import njit
from numba.typed import List

@njit('float64(float64, float64)')
def funcA(a, b):
    return a + b

@njit('float64(float64, float64)')
def funcB(a, b):
    return a - b

@njit
def wrap():
    a = 10
    b = 5
    print('params', a, b)
    # adding duplicates of the same function to the list works
    l1 = List()
    l1.append(funcA)
    l1.append(funcA)
    for f in l1:
        r = f(a, b)
        print('returns', r)
    # adding two different functions, but with matching signatures, fails:
    l2 = List()
    l2.append(funcA)
    l2.append(funcB)
    for f in l2:
        r = f(a, b)
        print('returns', r)

wrap()
``` 

Edited to add the error log:

```bash
tests/algos/test_centrality.py:12 (test_func_list)
def test_func_list():
        from numba import njit
        from numba.typed import List
    
        @njit('float64(float64, float64)')
        def funcA(a, b):
            return a + b
    
        @njit('float64(float64, float64)')
        def funcB(a, b):
            return a - b
    
        @njit
        def wrap():
            a = 10
            b = 5
            print('params', a, b)
            # adding duplicates of the same function to the list works
            l1 = List()
            l1.append(funcA)
            l1.append(funcA)
            for f in l1:
                r = f(a, b)
                print('returns', r)
            # adding two different functions, but with matching signatures, fails:
            l2 = List()
            l2.append(funcA)
            l2.append(funcB)
            for f in l2:
                r = f(a, b)
                print('returns', r)
    
>       wrap()

test_centrality.py:45: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
../../venv/lib/python3.7/site-packages/numba/core/dispatcher.py:401: in _compile_for_args
    error_rewrite(e, 'typing')
../../venv/lib/python3.7/site-packages/numba/core/dispatcher.py:344: in error_rewrite
    reraise(type(e), e, None)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

tp = <class 'numba.core.errors.TypingError'>
value = TypingError('Failed in nopython mode pipeline (step: nopython frontend)\nInvalid use of Function(<function impl_append..., line 40:\n    def wrap():\n        <source elided>\n        l2.append(funcA)\n        l2.append(funcB)\n        ^\n')
tb = None

    def reraise(tp, value, tb=None):
        if value is None:
            value = tp()
        if value.__traceback__ is not tb:
>           raise value.with_traceback(tb)
E           numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
E           Invalid use of Function(<function impl_append at 0x11e9a7e60>) with argument(s) of type(s): (ListType[type(CPUDispatcher(<function test_func_list.<locals>.funcA at 0x11f0d0680>))], type(CPUDispatcher(<function test_func_list.<locals>.funcB at 0x11f413950>)))
E            * parameterized
E           In definition 0:
E               LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
E           Cannot cast type(CPUDispatcher(<function test_func_list.<locals>.funcB at 0x11f413950>)) to type(CPUDispatcher(<function test_func_list.<locals>.funcA at 0x11f0d0680>)): %".21" = load i8*, i8** %"item"
E           
E           File "../../venv/lib/python3.7/site-packages/numba/typed/listobject.py", line 597:
E               def impl(l, item):
E                   casteditem = _cast(item, itemty)
E                   ^
E           
E           [1] During: lowering "$8call_function.3 = call $2load_global.0(item, $6load_deref.2, func=$2load_global.0, args=[Var(item, listobject.py:597), Var($6load_deref.2, listobject.py:597)], kws=(), vararg=None)" at .../cityseer/venv/lib/python3.7/site-packages/numba/typed/listobject.py (597)
E               raised from .../cityseer/venv/lib/python3.7/site-packages/numba/core/utils.py:80
E           In definition 1:
E               LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
E           Cannot cast type(CPUDispatcher(<function test_func_list.<locals>.funcB at 0x11f413950>)) to type(CPUDispatcher(<function test_func_list.<locals>.funcA at 0x11f0d0680>)): %".21" = load i8*, i8** %"item"
E           
E           File "../../venv/lib/python3.7/site-packages/numba/typed/listobject.py", line 597:
E               def impl(l, item):
E                   casteditem = _cast(item, itemty)
E                   ^
E           
E           [1] During: lowering "$8call_function.3 = call $2load_global.0(item, $6load_deref.2, func=$2load_global.0, args=[Var(item, listobject.py:597), Var($6load_deref.2, listobject.py:597)], kws=(), vararg=None)" at .../cityseer/venv/lib/python3.7/site-packages/numba/typed/listobject.py (597)
E               raised from .../cityseer/venv/lib/python3.7/site-packages/numba/core/utils.py:80
E           This error is usually caused by passing an argument of a type that is unsupported by the named function.
E           [1] During: resolving callee type: BoundFunction((<class 'numba.core.types.containers.ListType'>, 'append') for ListType[type(CPUDispatcher(<function test_func_list.<locals>.funcA at 0x11f0d0680>))])
E           [2] During: typing of call at .../cityseer/tests/algos/test_centrality.py (40)
E           
E           
E           File "test_centrality.py", line 40:
E               def wrap():
E                   <source elided>
E                   l2.append(funcA)
E                   l2.append(funcB)
E                   ^

../../venv/lib/python3.7/site-packages/numba/core/utils.py:79: TypingError

Assertion failed

Assertion failed
```
user: songololo
issue_5596: state: open
title: cast via NumbaClass (i.e `np.intp`) incorrect for array input
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

from https://gitter.im/numba/numba?at=5e9dedd9471108620549b674

reproducer:

```python
@njit
def test_list():
    tau = np.intp([0.3,2.2,3.3])
    return tau

> array([0, 2, 3])

@njit
def test_array():
    tau = np.asarray([1.1,2.2,3.4])
    tau = np.intp(tau)
    return tau

>> Long long error ending with :
oweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast array(float64, 1d, C) to int64: %".237" = load {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}, {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}* %"tau"

File "<ipython-input-151-121eb0928502>", line 10:
def test_array():
    <source elided>
    tau = np.asarray([1.1,2.2,3.4])
    tau = np.intp(tau)
    ^

[1] During: lowering "$0.11 = call $0.9(tau, func=$0.9, args=[Var(tau, <ipython-input-151-121eb0928502>:9)], kws=(), vararg=None)" at <ipython-input-151-121eb0928502> (10)
```
user: sklam
issue_5595: state: open
title: CUDA: Provide memset (or memset-like) functionality as part of the public interface
body: `numba.cuda.cudadrv.driver` provides the [`device_memset`](https://github.com/numba/numba/blob/master/numba/cuda/cudadrv/driver.py#L2266) function that calls either `cuMemsetD8Async` or `cuMemsetD8` depending on whether a stream is supplied.

It might be nice to provide a more public interface for setting memory. One could expose a fairly raw interface, like:

```python
def memset(dst, val, itemsize, count, stream=0):
   """Memset on the device. Parameters:
    - dst: A device array or other CUDA memory object
    - val: Value to assign
    - itemsize: size in bytes of the assigned item - e.g. 4 for int32
    - count: Number of items to set
    - stream: An optional stream - a nonzero stream implies an asynchronous memset"""
```

Although this matches expectations of a `memset` interface coming from a C background, it may be safer to provide the same functionality by slice assignment, e.g.:

```python
x = cuda.device_array(1024, dtype=np.int32)
x[:] = 7
```

where the number of items and data type are automatically determined, and memsetting of a portion of a device array is achieved by slicing the array and then assigning to the whole slice. At present the syntax `x[:] = 7` does work, but is implemented in a fairly inefficient manner - when running with `NUMBA_CUDA_LOG_LEVEL=DEBUG`, it results in:

```
== CUDA [17788] DEBUG -- call driver api: cuCtxGetCurrent
== CUDA [17788] DEBUG -- call driver api: cuCtxGetDevice
== CUDA [17789] DEBUG -- call driver api: cuMemAlloc_v2
== CUDA [17790] DEBUG -- call driver api: cuMemcpyHtoD_v2
== CUDA [18035] DEBUG -- call driver api: cuLinkCreate_v2
== CUDA [18035] DEBUG -- call driver api: cuLinkAddData_v2
== CUDA [18035] DEBUG -- call driver api: cuLinkComplete
== CUDA [18035] DEBUG -- call driver api: cuModuleLoadDataEx
== CUDA [18036] DEBUG -- call driver api: cuModuleGetFunction
== CUDA [18036] DEBUG -- call driver api: cuFuncGetAttribute
== CUDA [18036] DEBUG -- call driver api: cuFuncGetAttribute
== CUDA [18036] DEBUG -- call driver api: cuFuncGetAttribute
== CUDA [18036] DEBUG -- call driver api: cuFuncGetAttribute
== CUDA [18036] DEBUG -- call driver api: cuFuncGetAttribute
== CUDA [18036] DEBUG -- call driver api: cuLinkDestroy
== CUDA [18036] DEBUG -- call driver api: cuOccupancyMaxPotentialBlockSize
== CUDA [18036] DEBUG -- call driver api: cuLaunchKernel
== CUDA [18037]  INFO -- add pending dealloc: cuMemFree_v2 8 bytes
```

because Numba creates and jits a kernel to assign the RHS, as well as copying the assigned scalar to the device, when it could have been done more efficiently with a call to `cuMemsetD32` for this particular example. So, implementing the second option comes down to optimising the implementation of [`DeviceNDArray._do_setitem()`](https://github.com/numba/numba/blob/master/numba/cuda/cudadrv/devicearray.py#L577) to use an appropriate `cudaMemset*` function wherre possible.
user: gmarkall
labels: CUDA: CUDA related issue/PR
performance: performance related issue
issue_5588: state: open
title: Make _get_thread_id() a public function
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

I maintain a package called [stumpy](https://github.com/TDAmeritrade/stumpy) that leverages Numba for parallel compute. One of the core functions of STUMPY takes a large n x n matrix and performs independent computations along the diagonal and also along all of the “off diagonals” (i.e., all traversals that are parallel to the main diagonal). Since these diagonal/off diagonal are completely independent of each other and there are of different lengths, we are leveraging `prange` along with the new `_get_thread_id()` to manage the computation and ensure that each thread has roughly the same amount of work and then a reduction is performed at the end. In fact, without the `_get_thread_id` function, it is not possible to ensure that all threads in `prange` are reading/writing to its own memory space.

I would like to request that `_get_thread_id` be made a public function.
user: seanlaw
issue_5582: state: open
title: Support generic attribute types for jitclass
body: ## Feature request

I have a jitclass with an array attribute, e.g.:

```
spec = [('value', optional(float64[:]))]

@jitclass(spec)
class Node(object):
    def __init__(self):
        self.value = None
```

The issue is that I need to specify the array type `float64` upfront, which limits the reusability of the class with other types of data. It would be ideal if I could specify `value` as `float[:]`, and at runtime the concrete type would be decided by some other data.

This feature request applies to scalars as well, e.g. generic int and float types.

Related question: https://stackoverflow.com/questions/50744775/does-numba-jitclass-support-generics


user: trianta2
issue_5566: state: open
title: RuntimeError: cannot cache function '__shear_dense' 
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [y] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [y] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

This numba issue while I'm importing librosa. so I suspect it would related to numba, since I didn't get any resolutions from librosa.

Error while importing librosa though all the required dependencies are installed properly.
Steps/Code to Reproduce

$ python --version
Python 3.8.2
$ python3 -c "import audioread"
$ python3 -c "import six"
$ python3 -c "import joblib"
$ python3 -c "import scipy"
$ python3 -c "import numpy"
$ python3 -c "import numba"
$ python3 -c "import resampy"
$ python3 -c "import sklearn"
$ python3 -c "import soundfile"
$ python3 -c "import librosa"
Traceback (most recent call last):
File "", line 1, in
File "usr/lib/python3.8/site-packages/librosa/init.py", line 12, in
File "usr/lib/python3.8/site-packages/librosa/core/init.py", line 125, in
File "usr/lib/python3.8/site-packages/librosa/core/time_frequency.py", line 11, in
File "usr/lib/python3.8/site-packages/librosa/util/init.py", line 77, in
File "usr/lib/python3.8/site-packages/librosa/util/utils.py", line 1825, in
File "usr/lib/python3.8/site-packages/numba/decorators.py", line 193, in wrapper
File "usr/lib/python3.8/site-packages/numba/dispatcher.py", line 679, in enable_caching
File "usr/lib/python3.8/site-packages/numba/caching.py", line 614, in init
File "usr/lib/python3.8/site-packages/numba/caching.py", line 348, in init
RuntimeError: cannot cache function '__shear_dense': no locator available for file 'usr/lib/python3.8/site-packages/librosa/util/utils.py'

Few versions I'm running on my system.

Linux-5.6.0-aarch64-with-glibc2.17
Python 3.8.2 (default, Apr 12 2020, 21:58:31)
[GCC 8.4.0]
NumPy 1.18.2
SciPy 1.4.1

Any help?

user: openedev
labels: caching: Issue involving caching
bug - incorrect behavior: Bugs: incorrect behavior
issue_5562: state: open
title: No performance improvement with Intel's SVML library
body: - [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Hello,

I am running Numba 0.48 (last version available in PyPi) on Windows 10 (64 bits) with Python 3.8.2 and I am not able to get better performance after installing Intel's icc_rt library. It seems that SVML libraries are detected by Numba, as it can be checked in `numba -s` output:

> __Time Stamp__
> 2020-04-15 10:02:04.120355
> 
> __Hardware Information__
> Machine                                       : AMD64
> CPU Name                                      : skylake
> CPU count                                     : 8
> CPU Features                                  :
> 64bit adx aes avx avx2 bmi bmi2 clflushopt cmov cx16 f16c fma fsgsbase invpcid
> lzcnt mmx movbe pclmul popcnt prfchw rdrnd rdseed sahf sgx sse sse2 sse3 sse4.1
> sse4.2 ssse3 xsave xsavec xsaveopt xsaves
> 
> __OS Information__
> Platform                                      : Windows-10-10.0.18362-SP0
> Release                                       : 10
> System Name                                   : Windows
> Version                                       : 10.0.18362
> OS specific info                              : 1010.0.18362SP0
> 
> __Python Information__
> Python Compiler                               : MSC v.1916 64 bit (AMD64)
> Python Implementation                         : CPython
> Python Version                                : 3.8.2
> Python Locale                                 : en_GB cp1252
> 
> __LLVM information__
> LLVM version                                  : 8.0.0
> 
> __CUDA Information__
> Found 1 CUDA devices
> id 0        b'GeForce MX150'                              [SUPPORTED]
>                       compute capability: 6.1
>                            pci device id: 0
>                               pci bus id: 1
> Summary:
>         1/1 devices are supported
> CUDA driver version                           : 10000
> CUDA libraries:
> Error: Probing CUDA failed (device and driver present, runtime problem?)
> 
> 
> __ROC Information__
> ROC available                                 : False
> Error initialising ROC due to                 : No ROC toolchains found.
> No HSA Agents found, encountered exception when searching:
> Error at driver init:
> 
> HSA is not currently supported on this platform (win32).
> :
> 
> __SVML Information__
> SVML state, config.USING_SVML                 : True
> SVML library found and loaded                 : True
> llvmlite using SVML patched LLVM              : True
> SVML operational                              : True
> 
> __Threading Layer Information__
> TBB Threading layer available                 : True
> OpenMP Threading layer available              : False
> +--> Disabled due to                          : Unknown import problem.
> Workqueue Threading layer available           : True
> 
> __Numba Environment Variable Information__
> None set.
> 
> __Conda Information__
> Conda not present/not working.
> Error was [WinError 2] The system cannot find the file specified

However, the following code takes the same amount of time to run with or without SVML libraries:

```
import numpy as np
import numba as nb

@nb.njit(fastmath={'nnan', 'ninf', 'nsz', 'arcp', 'contract'})
def foo(a, b):
    assert a.size == b.size

    error = 0.0
    for i in range(a.size):
        ratio = a[i] / b[i]

        magnitude_error = np.log10(np.abs(ratio))
        phase_error = ((np.angle(ratio) + np.pi) % (2.0 * np.pi)) - np.pi

        error += ((magnitude_error**2.0 + phase_error**2.0) / 2.0)

    return error

a = np.arange(1, 1000) + 1j * np.arange(1, 1000)
b = np.arange(1, 1000) + 1j * np.arange(1, 1000)

# Compile function
foo(a, b)

# Check performance
%timeit foo(a, b)
```

I tried to install Numba and icc_rt with conda and I get the same result. Shouldn't perform better with SVML libraries?

Thank you so much for your support.
user: cmartinezdem
labels: performance: performance related issue
issue_5554: state: open
title: [For discussion] Subtyping proposal
body: Hi,

In many cases it would be useful to treat some type as  a subtype of another one. In the gist below, I describe a proposal to get this working in Numba

https://gist.github.com/luk-f-a/9063ee1eea50166141a21ee852fb4812

I'm opening this issue for discussion. I am able to take care of the PR once an initial agreement is reached.

cc: @stuartarchibald 
user: luk-f-a
labels: discussion: An issue requiring discussion
issue_5552: state: open
title: Declarative Typing in overloads
body: Allow`@overload` to declare the supported function signature 
user: sklam
issue_5551: state: open
title: Function does not stop at SIGINT
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

```python
In [1]: import numba

In [2]: numba.__version__
Out[2]: '0.48.0'

In [3]: from numba import njit

In [4]: @njit
   ...: def S(e, x):
   ...:     S = 0
   ...:     k = 0
   ...:     while True:
   ...:         S_old = S
   ...:         S += (e - 1 / (2 * k + 3)) * x ** k
   ...:         k += 1
   ...:         if S == S_old:
   ...:             return S
   ...: 

In [5]: S(0.995, -0.0007)
Out[5]: 0.6611105839137097

In [6]: S(0.995, -0.1)
Out[6]: 0.589886277949347

In [7]: S(0.995, -1.0)  # Hangs
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C

```

With `NUMBA_DISABLE_JIT=1` one can stop the function, which will otherwise take a very long time:

```python
In [5]: S(0.995, -1.0)
^C---------------------------------------------------------------------------
KeyboardInterrupt                         Traceback (most recent call last)
<ipython-input-5-9499cc8a1c18> in <module>
----> 1 S(0.995, -1.0)

<ipython-input-1-8677963fd0a4> in S(e, x)
      8     while True:
      9         S_old = S
---> 10         S += (e - 1 / (2 * k + 3)) * x ** k
     11         k += 1
     12         if S == S_old:

KeyboardInterrupt:
```

On the other hand, if one forces a Python overflow:

```python
In [8]: S(0.995, -2.0)
---------------------------------------------------------------------------
OverflowError                             Traceback (most recent call last)
<ipython-input-8-1b2a088ebc3f> in <module>
----> 1 S(0.995, -2.0)

<ipython-input-1-8677963fd0a4> in S(e, x)
      8     while True:
      9         S_old = S
---> 10         S += (e - 1 / (2 * k + 3)) * x ** k
     11         k += 1
     12         if S == S_old:

OverflowError: (34, 'Numerical result out of range')
```

the `njit`-ted function gets stuck as well. And finally, it also happens with a NumPy overflow:

```python
In [3]: S(0.995, np.array(-2.0))
<ipython-input-1-8677963fd0a4>:10: RuntimeWarning: overflow encountered in power
  S += (e - 1 / (2 * k + 3)) * x ** k
<ipython-input-1-8677963fd0a4>:10: RuntimeWarning: invalid value encountered in double_scalars
  S += (e - 1 / (2 * k + 3)) * x ** k
^C---------------------------------------------------------------------------
KeyboardInterrupt                         Traceback (most recent call last)
<ipython-input-3-d0e625ea240a> in <module>
----> 1 S.py_func(0.995, np.array(-2.0))

<ipython-input-1-8677963fd0a4> in S(e, x)
      8     while True:
      9         S_old = S
---> 10         S += (e - 1 / (2 * k + 3)) * x ** k
     11         k += 1
     12         if S == S_old:

KeyboardInterrupt:
```

Code to copy-paste:

<details>

```python
import numpy as np
import numba
numba.__version__
from numba import njit
@njit
def S(e, x):
    S = 0
    k = 0
    while True:
        S_old = S
        S += (e - 1 / (2 * k + 3)) * x ** k
        k += 1
        if S == S_old:
            return S
            
S(0.995, -0.0007)
S(0.995, -0.1)
S(0.995, -1.0)  # Hangs
S(0.995, -2.0)  # Overflows
S(0.995, np.array(-2.0))  # NumPy-overflows
```
</details>
user: astrojuanlu
issue_5541: state: open
title: Fixed-size stack-allocated list
body: ## Feature request
I'd like to see support for a fixed-size stack-allocated mutable `list`.
user: hameerabbasi
issue_5536: state: open
title: Implement `str` correctly
body: The code base at present implements `str()` directly for each type via an overload, these are here:
```
numba/cpython/charseq.py:600:@overload(str)
numba/cpython/unicode.py:436:@overload(str)
```
it would be better if `str()` was implemented as per cpython https://docs.python.org/3/library/stdtypes.html#str whereby there's a single overload for `str()` which calls the argument's `.__str__` and if that's missing calls `repr(argument)`, `repr` also needs implementing in a similar way!
user: stuartarchibald
issue_5533: state: open
title: Comparison operators on dtypes
body: ```
@jit(nopython=True)
def delta_mat(m,d):

	size = m.size

	if size == 1:
		return np.full(fill_value=np.nan,shape=(1,1),dtype=np.float32)

	if m.dtype != np.float32:
		return np.full(fill_value=np.nan,shape=(1,1),dtype=np.float32)

	rowNum = m.shape[0]
	colNum = m.shape[1]
	
	if rowNum <= d + 20:
		return np.full(fill_value=np.nan,shape=(rowNum,colNum),dtype=np.float32)

	return m[d:] - m[:(rowNum-d)]
```

```
m1 = np.random.randn(400,4000).astype(np.float32)
ans = delta_mat(m1,10)
```

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function ne>) with argument(s) of type(s): (dtype(float32), class(float32))
Known signatures:
 * (bool, bool) -> bool
 * (int8, int8) -> bool
 * (int16, int16) -> bool
 * (int32, int32) -> bool
 * (int64, int64) -> bool
 * (uint8, uint8) -> bool
 * (uint16, uint16) -> bool
 * (uint32, uint32) -> bool
 * (uint64, uint64) -> bool
 * (float32, float32) -> bool
 * (float64, float64) -> bool
 * (complex64, complex64) -> bool
 * (complex128, complex128) -> bool
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
In definition 10:
    All templates rejected with literals.
In definition 11:
    All templates rejected without literals.
In definition 12:
    All templates rejected with literals.
In definition 13:
    All templates rejected without literals.
In definition 14:
    All templates rejected with literals.
In definition 15:
    All templates rejected without literals.
In definition 16:
    All templates rejected with literals.
In definition 17:
    All templates rejected without literals.
In definition 18:
    All templates rejected with literals.
In definition 19:
    All templates rejected without literals.
In definition 20:
    All templates rejected with literals.
In definition 21:
    All templates rejected without literals.
In definition 22:
    All templates rejected with literals.
In definition 23:
    All templates rejected without literals.
In definition 24:
    All templates rejected with literals.
In definition 25:
    All templates rejected without literals.
In definition 26:
    All templates rejected with literals.
In definition 27:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of intrinsic-call at <ipython-input-828-786c27396a32> (9)

File "<ipython-input-828-786c27396a32>", line 9:
def delta_mat(m,d):
    <source elided>

	if m.dtype != np.float32:
 ^
```
np.__version__  : '1.17.2'
numba.__version__:  '0.48.0'


user: isaac-you
issue_5531: state: open
title: Accessing generators from c extension
body: We are trying to access generators from a c extension but currently it is not well supported. Assume that I have the generator below and I want next to be called from c extension. Can pass the generated object to c extension, it's not a problem, but calling next on it without going via python layer doesn't seem to be supported. Consider the generator below:
```python
    @numba.njit()
    def counter():
         val = 0
         while True: 
             yield val
             val += 1
````
This works:
```python
x = counter()
v = next(x)
````
But if I want to create a numba function that would get the next value, it wouldn't work:
```python
x = counter()
@numba.njit
def get_next(o):
    return next(o)
get_next(x) # raises ValueError, if it didn't and I could wrap it in cfunc then problem is solved.
````
I have 2 questions/requests:

- Can anyone implement a support for calling next from within c code (assuming that it knows all the types of course and there should be some way of checking whether the generator is finished).
- Is there a way to do it with current numba (maybe using extensions in some smart way?)



user: smichael83
issue_5530: state: open
title: CUDA datetimes are only tested with `datetime[D]`, documentation not explicit
body: The CUDA datetime tests (`numba.cuda.tests.cudapy.test_datetime`) only test with `datetime[D]` - testing with other units would be a good idea.

I also can't find any reference to datetimes being supported on CUDA in the documentation - some explicit mention that they are supported would be helpful.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_5523: state: open
title: np.ravel does not preserve mutability for class attributes with @jitclass
body: The `np.ravel` function is supposed to make a mutable, flat view into some array. When used with `@jitclass` on a class attribute it does not seem to do this properly.

```python
In [53]: @jitclass([('a', int32[:,:])])
    ...: class test():
    ...:     def __init__(self):
    ...:         self.a = np.zeros((3,3), dtype=np.int32)
    ...: 
    ...:     def modify_a(self):
    ...:         b = self.a.ravel()
    ...:         b[0] += 1
    ...:         return b
    ...: 

In [54]: t = test()

In [55]: t.modify_a()
Out[55]: array([1, 0, 0, 0, 0, 0, 0, 0, 0])

In [56]: t.a
Out[56]: 
array([[0, 0, 0],
       [0, 0, 0],
       [0, 0, 0]])
```

The same issue is not apparent when using `np.ravel` in a normal function with `@jit`:
```python3
In [57]: @jit
    ...: def test():
    ...:     a = np.zeros((3,3), dtype=np.int32)
    ...:     b = a.ravel()
    ...:     b[0] += 1
    ...:     return a, b
    ...: 

In [58]: test()
Out[58]: 
(array([[1, 0, 0],
        [0, 0, 0],
        [0, 0, 0]]),
 array([1, 0, 0, 0, 0, 0, 0, 0, 0]))
```
user: zachmatson
issue_5520: state: open
title: OMP omp_set_nested deprecated warning in 0.49rc1
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
I see this warning when using `parallel=True` in 0.49rc1 but not 0.48 (haven't investigated much because it seems self-explanatory).
```python
>>> numba.njit(parallel=True)(lambda A: 2*A)(np.ones(3))
OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
array([2., 2., 2.])
```
user: ehsantn
issue_5514: state: open
title: Code generation for np.einsum
body: ## Aim of this Function

Numba is very good in compiling loops, but doesn't analyze (at least that I know) array sizes at compile time, even if this could be possible (JIT-compilation). I guess it will be quite hard to implement an overload, which optimizes the reduction path as np.einsum does if optimization is turned on.
This implementation isn't an overload, but simply translates a einsum function to Numba compile-able code.

[https://github.com/numba/numba/issues/5503#issue-593540730](url)
user: max9111
issue_5507: state: open
title: Record mutation is ignored
body: When creating an empty record array (but not when passing it in as a parameter), mutation is ignored in some cases. Looking at the numba IR code, the code is identical except for the expected difference of an extra `static_getitem` at the end. The LLVM IR looks quite different, I think the mutation is being optimized away.

```python
from numba import njit
import numpy as np
import numba
print(numba.__version__)
# 0.49.0rc1

a_b_type = np.dtype([('a', 'i8'), ('b', 'f8')], align=True)

@njit
def foo1():
    x = np.empty((1,), a_b_type)
    x[0]['a'] = 1
    x[0]['b'] = 2
    return x[0]

@njit
def foo2():
    x = np.empty((1,), a_b_type)
    x[0]['a'] = 1
    x[0]['b'] = 2
    return x

print(foo1(), foo2()[0]) 
# (-2387225703656530210, -9.86830992e+148) (1, 2.) 
```
user: luk-f-a
issue_5502: state: open
title: ZeroDivisionError if an empty array is passed to np.mean()
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
The following code raises ZeroDivisionError in nopython mode.

```python
from numba import njit
import numpy as np

@njit
def mean(arr):
    return np.mean(arr)

mean(np.asarray([]))
```
Without njit decorator, the function returns NaN

### Traceback

```
ZeroDivisionError                         Traceback (most recent call last)
<ipython-input-11-60946af0372d> in <module>
----> 1 mean(np.asarray([]))

ZeroDivisionError: division by zero
```
user: santhisenan
issue_5492: state: open
title: do not link unreferenced environments
body: For each jitted function numba emits a global variable that holds a pointer to the [environment](https://numba.pydata.org/numba-doc/dev/developer/environment.html).

Let's assume code of the following form:
```
@njit
def foo():
    # ...

@njit
def bar():
    foo()
```

The following IR is emitted:
```
@"_ZN08NumbaEnv8__main__9foo$244E" = common global i8* null
define i32 @"_ZN8__main__9foo$244E"(i8** noalias nocapture %"retptr", {i8*, i32}** noalias nocapture %"excinfo")
```

In this case however, the foo-environment is never used. The emitted llvm module contains no references to it.

Nevertheless the foo-environment gets allocated memory. This is caused by the `common` linkage.

This PR changes the linkage of environments to `linkonce` which satisfies the original author's goal of allowing multiple definitions of the global variable to be merged into a single definition when the modules are linked together. It does however also allow the optimizer to optimize away unused environments.

For a unit test, a separate llvm module would need to be compiled and checked if it still contains the bar-environment global variable after optimization. I am not sure how to write a test like this. 
user: ARF1
issue_5490: state: open
title: support for `with ... as ...` expression
body: Numba crashes when the expression `with ... as ...` is used.

```python
from numba import njit, objmode
from numba.core import errors, ir, ir_utils, sigutils, types
from numba.core.transforms import find_region_inout_vars
from numba.core.typing.typeof import typeof_impl
from numba.core.withcontexts import WithContext, _clear_blocks, _get_var_parent


class TestContext(WithContext):
    is_callable = True

    def mutate_with_body(self, func_ir, blocks, blk_start, blk_end,
                         body_blocks, dispatcher_factory, extra):
        # Determine variables that need forwarding
        vlt = func_ir.variable_lifetime
        inmap = {_get_var_parent(k): k for k in vlt.livemap[blk_start]}
        outmap = {_get_var_parent(k): k for k in vlt.livemap[blk_end]}
        forwardvars = {inmap[k]: outmap[k] for k in filter(bool, outmap)}
        # Transform the block
        node = [b for b in blocks.keys() if blk_start < b < blk_end][0]
        _bypass_with_context(blocks, blk_start, node, forwardvars)


def _bypass_with_context(blocks, blk_start, blk_end, forwardvars):
    sblk = blocks[blk_start]
    scope = sblk.scope
    loc = sblk.loc
    newblk = ir.Block(scope=scope, loc=loc)
    newblk.append(ir.Jump(target=blk_end, loc=loc))
    blocks[blk_start] = newblk


test_context = TestContext()


@njit
def test_numba():
    with test_context as a:
        pass


test_numba()
```

Output: 
```
numba.core.errors.NotDefinedError: Failed in nopython mode pipeline (step: analyzing bytecode)
Variable '$4setup_with.1' is not defined.
```
user: ARF1
issue_5474: state: open
title: Treat typing.cast as a no-op?
body: This is a minor feature request, but could make the life simpler for those who are using mypy - there's `typing.cast()` standard library function which is a no-op and only serves to change the typing (from mypy's perspective). Currently, numba will complain that it doesn't know this function:

```
Untyped global name 'cast': cannot determine Numba type of <class 'function'>
```

Could numba treat it as a no-op?
user: aldanor
issue_5472: state: open
title: literally with default values
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```python
import numba

@numba.extending.register_jitable
def literally_with_default(a='a'):
    print(numba.literally(a))

@numba.njit()
def f():
    literally_with_default()

f()
```

Output:
```
Traceback (most recent call last):
  File "./literally_with_default.py", line 11, in <module>
    f()
  File ".../numba/core/dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File ".../numba/core/dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File ".../numba/core/utils.py", line 79, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Cannot request literal type.
```

Numba version is 0a8b8118987944e82603bfa3c90d87b80ffe5d99
user: AlexanderKalistratov
issue_5468: state: open
title: typed.Dict.get return value has OptionalType when default value is provided
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Hi, 

Please take a look at the following issue with typed.Dict.get method for which the type of return value is inferred as OptionalType even when default argument is provided and is of the same type as dictionary's value_type.

Here's the reproducer:
```
import numba
from numba import types
from numba.typed import Dict, List

import unittest
import numpy as np

class TestSuite(unittest.TestCase):

    def test_numba_typed_dict_get_optional_type(self):

        def test_impl(A):
            res = np.empty(len(A), dtype=types.int64)
            group_to_count = List.empty_list(types.int64)
            key_to_group_number = {}

            total_keys = 0
            for i, value in enumerate(A):
                # the type of grp is inferred as OptionalType(int64)
                # even though default arg was provided and is not None
                grp = key_to_group_number.get(value, -1)
                if grp == -1:        # this line compiles OK
                    key_to_group_number[value] = total_keys
                    group_to_count.append(1)
                    res[i] = total_keys
                    total_keys += 1
                else:
                    group_to_count[grp] += 1   # but this won't
                    # a workaround is make explicit cast:
                    # group_to_count[types.int64(grp)] += 1
                    res[i] = grp

            return res, group_to_count
        jitted = numba.njit(test_impl)

        np.random.seed(0)
        n = 20
        A = np.random.choice(['a', 'b', 'c', 'd', 'e'], n)
        grouper, group_sizes = jitted(A)

        print(f'data: {A}')
        print(f'grouper: {grouper}')
        print(f'group_sizes: {group_sizes}')

if __name__ == "__main__":
    unittest.main()
```

Gives:
```
Traceback (most recent call last):
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\example_test.py", line 76,
in test_numba_typed_dict_get_optional_type
    grouper, group_sizes = jitted(A)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py",
line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\dispatcher.py",
line 344, in error_rewrite
    reraise(type(e), e, None)
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\numba\numba\core\utils.py", line
79, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
list indices must be integers or slices
[1] During: typing of intrinsic-call at C:\Users\akozlov\AppData\Local\Continuum\anaconda3\numba_master\n
umba\example_test.py (65)

File "example_test.py", line 65:
        def test_impl(A):
            <source elided>
                else:
                    group_to_count[grp] += 1   # but this won't
                    ^
```

If workaround is applied, inspect_types() shows grp is OptionalType:
```
                # --- LINE 21 ---
                #   $60load_method.6 = getattr(value=key_to_group_number, attr=get)  :: BoundFunction((<c
lass 'numba.core.types.containers.DictType'>, 'get') for DictType[[unichr x 1],int64])
                #   $const64.8 = const(int, -1)  :: Literal[int](-1)
                #   $66call_method.9 = call $60load_method.6(value, $const64.8, func=$60load_method.6, ar
gs=[Var(value, example_test.py:18), Var($const64.8, example_test.py:21)], kws=(), vararg=None)  :: ([unic
hr x 1], Literal[int](-1)) -> OptionalType(int64) i.e. the type 'int64 or None'
                #   del $const64.8
                #   del $60load_method.6
                #   grp = $66call_method.9  :: OptionalType(int64) i.e. the type 'int64 or None'
                #   del $66call_method.9

                grp = key_to_group_number.get(value, -1)
```

The issue is observed both on Numba 0.48 branch and master:
# Name                    Version                   Build  Channel
numba                     0.49.0.dev0+1043.g0a8b81189           dev_0    <develop>


Best Regards,
Alexey.

user: kozlov-alexey
issue_5462: state: open
title: Numba prange does not throw on size mismatch error
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```python
@njit(parallel=True)
def f():
    arr = np.zeros((100, 3))
    for i in prange(100):
        arr[i, :] = np.array([1.0, 2.0])
    return arr
arr = f()  # equals to np.zeros((100, 3))
```
while following code throws error as expected:
```python
@njit
def f():
    arr = np.zeros((100, 3))
    for i in range(100):  # prange --> range
        arr[i, :] = np.array([1.0, 2.0])
    return arr
arr = f()
```

**I am not using the latest version, I cloned the branch from https://github.com/IntelLabs/numba/tree/issue5442**
user: xuanqing94
issue_5461: state: open
title: Calling objectmode function from nopython mode
body: It's possible to call object-mode function from nopython-mode functions using `with objmode()`. But, all necessary information would have been available in the following case:

```python
@jit("int(unicode_type)", forceobj=True)
def do_objmode(name):
   ...
```

Currently, the following would work:
```python
@njit
def currently_working(name):
    with objmode(res='int'):
         res = do_objmode(name)
    return res
```

But, it's easier if it is:

```python
@njit
def does_not_work(name):
    return do_objmode(name)
```

That is, if we compile a function with a known type signature (with return type), numba has all the necessary information to elide the need for `with objmode`.

Also, this is interesting to think about in the context of first-class function. 
user: sklam
labels: discussion: An issue requiring discussion
issue_5460: state: open
title: Numba broadcast/ufunc mechanism is broken
body: Following up on a discussion on [#4610](https://github.com/numba/numba/pull/4610#discussion_r399481559). The numba broadcasting mechanism is broken and the ufunc is called when it shouldn't.

```python
In [1]: @numba.njit
    ...: def foo():
    ...:     return np.negative(np.ones(2), np.zeros(3))
    ...:

In [2]: foo()
Out[2]: array([-1.00000000e+000, -1.00000000e+000, -4.24425064e-314])

In [3]: np.negative(np.ones(2), np.zeros(3))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-102-b27ba6de5789> in <module>
----> 1 np.negative(np.ones(2), np.zeros(3))

ValueError: operands could not be broadcast together with shapes (2,) (3,)
```
user: guilhermeleobas
issue_5435: state: open
title: Support `order=` in ndarray bound function `reshape`.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I have written the following function, which works out a permutation I need for my code, it works well without `numba` but fails with it.

```
def permOfIkKkI2D(k1,k2,n1,n2):

  # First we need the permutation represented by matrix K in vector format
  permP = np.arange(n1*k2).reshape((n1, k2), order='F').ravel()

  # Now we work out the permutation obtained by the first kronecker product (i.e. I kron K)
  permKron1 = np.repeat(np.arange(k1),n1*k2)*n1*k2+np.tile(permP,k1)

  # Now we work out the final permutation by appplying the second kronecker product (i.e. I kron K kron I)
  p = np.repeat(permKron1,n2)*n2+np.tile(np.arange(n2),n1*k1*k2)

  # Return the permutation
  return(p)
```

With `numba` I get this error:

```
    perm = permOfIkKkI2D(n2,n1,n2,n1)
  File "/home/tommaullin/.local/lib/python3.6/site-packages/numba/dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/tommaullin/.local/lib/python3.6/site-packages/numba/dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "/home/tommaullin/.local/lib/python3.6/site-packages/numba/six.py", line 668, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.typeinfer.CallConstraint object at 0x7f0202c460f0>.
[1m[1m[1m[0m
[0m[1m[1] During: resolving callee type: BoundFunction(array.reshape for array(int64, 1d, C))[0m
[0m[1m[2] During: typing of call at /home/tommaullin/Documents/BLMM_creation/BLMM/lib/tools2d.py (409)
[0m
Enable logging at debug level for details.
[1m
File "../../lib/tools2d.py", line 409:[0m
[1mdef permOfIkKkI2D(k1,k2,n1,n2):
    <source elided>
  # First we need the permutation represented by matrix K in vector format
[1m  permP = np.arange(n1*k2).reshape((n1, k2), order='F').ravel()
[0m  [1m^[0m[0m
```
user: TomMaullin
issue_5433: state: open
title: Incompatible shape for array
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--



-->

I have written the following function below. 
```
# ============================================================================
#
# This function takes in a matrix and vectorizes it (i.e. transforms it
# to a vector of each of the columns of the matrix stacked on top of
# one another).
#
# ============================================================================
@jit(nopython=True)
def mat2vec2D(matrix):
  
  #Return vectorised matrix
  return(matrix.transpose().reshape(matrix.shape[0]*matrix.shape[1],1))
```

When I run it without `numba` it runs well and correctly. When I run it with `numba` it gives me this error:

```
NotImplementedError: incompatible shape for array
```

user: TomMaullin
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_5426: state: open
title: Fix a SystemError if unboxing fails in a ufunc
body: Previously the conversion function could be called while an error was in flight, which isn't legal.

Discovered by #5422 which made this mistake a lowering error.

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
mailing list https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

Output on master:
```
In [8]: f(arr, out)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-6-bcca0651d5c8> in __int__(self)
      2     def __int__(self):
----> 3         raise RuntimeError()
      4

RuntimeError:

The above exception was the direct cause of the following exception:

SystemError                               Traceback (most recent call last)
<ipython-input-8-ec85c84fdad7> in <module>
----> 1 f(arr, out)

<ipython-input-6-bcca0651d5c8> in __int__(self)
      1 class BadType:
      2     def __int__(self):
----> 3         raise RuntimeError()
      4
      5

SystemError: <class 'RuntimeError'> returned a result with an error set
```
With this patch, the `SystemError` no longer occurs and `RuntimeError` happens by itself.
user: eric-wieser
issue_5419: state: open
title: Reference leak for arguments to njit functions if partial type inference is used
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Looks like there is a reference leak for arguments to njit functions if:
1. A pipeline is used that has partial type inference
2. There are overloads that may fail during partial type inference

The minimal reproducer below demonstrates the issue:
```python
import numpy as np
import numba
import sys
import gc

from numba.untyped_passes import LiteralUnroll
from numba.typed_passes import PartialTypeInference
from numba.compiler_machinery import register_pass, FunctionPass
from numba.compiler import DefaultPassBuilder
from numba.extending import overload


class TestRefcountCompiler(numba.compiler.CompilerBase):
    """Compiler pipeline that just runs partial type inference then removes all IR
    nodes except "return None" to finish compilation
    """
    def define_pipelines(self):
        pm = DefaultPassBuilder.define_nopython_pipeline(self.state, "test_refcount")
        pm.add_pass_after(PartialTypeInference, LiteralUnroll)
        pm.add_pass_after(RemoveIR, PartialTypeInference)
        pm.finalize()
        return [pm]


@register_pass(mutates_CFG=True, analysis_only=False)
class RemoveIR(FunctionPass):
    """remove all IR nodes except "return None"
    """
    _name = "remove_ir"

    def __init__(self):
        FunctionPass.__init__(self)

    def run_pass(self, state):
        state.func_ir.blocks[0].body = state.func_ir.blocks[0].body[-4:]
        return True


def g():
    pass


@overload(g)
def overload_g():
    return lambda: unavailable_global  # <- implementation that can't be compiled


@numba.njit(pipeline_class=TestRefcountCompiler)
def f(A):
    g()


data = (np.ones(100),)
print("number of references before f():", sys.getrefcount(data))
f(data)
gc.collect()
print("number of references after  f():", sys.getrefcount(data))
```
Output with njit enabled:
```
number of references before f(): 2
number of references after  f(): 4
```
Output without njit:
```
number of references before f(): 2
number of references after  f(): 2
```
Looks like the reference to the tuple of arguments to the function is retained [here](https://github.com/numba/numba/blob/cc7e7c7cfa6389b54d3b5c2c95751c97eb531a96/numba/dispatcher.py#L353) if there are errors. Adding `del args` before returning the compiled function seems to be a workaround but there is probably a deeper problem.

user: ehsantn
labels: bug - memory leak: Memory leak
issue_5416: state: open
title: Type code attribute for `TypeRef`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Currently, `TypeRef`s are represented as `Dummy` in nopython. To implement  tagged union types (or similar) in Numba it would be helpful if  there was some sort of 'type code' attribute for `TypeRef`. Type code attributes should be of unifiable type accross all `TypeRef`s and should support comparison with `TypeRef`. At least for tagged unions, there is no requirement to be able to reconstruct the `TypeRef` from a type code.

See below for some pseudo-implementation of a tagged union (obviously to naive to generalize to mem-managed types etc):
```python
@register_model(TaggedUnionType)
class TaggedUnionModel(StructModel):
    def __init__(self, dmm, fe_typ):
        members = [
            ('type_code', type_code_type),
            ('payload', payload_type)
        ]
        super(TaggedUnionModel, self).__init__(dmm, fe_typ, members)

@generated_jit
def put_value(union, value):
    typeref = value

    def put_value_impl(union, value):
        union.type_code = typeref.type_code  # type codes need to unify such that they can be stored on an attribute
        union.payload = _pack_value(value)

    return put_value_impl

@jit
def get_value(union, type)
    if union.type_code != type  # need to be able to check TypeRef and type_code ref the same type
        raise TypeError('Requested type does not match stored type.')
    return _unpack(union.payload, type)
```

### Implementation challenges
As I am currently unaware of a basic-type invariant of `Type` that stays constant over time (the obvious candidates `Type._code` and hash won't) the key challenge seems to be caching. For an implementation of a type code you had to either find/construct a suitable invariant or somehow trigger re-compilation each time the type code changes.

  

user: asodeur
labels: discussion: An issue requiring discussion
issue_5412: state: open
title: literal_unroll problem unpacking induction variable
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Reported here: https://gitter.im/numba/numba?at=5e78f90ef985870ce942c013

This:
```python
from numba import njit, literal_unroll
import numpy as np

@njit
def simple_kernel():
    for x, y in literal_unroll(((1,2),(2,3),(3,4))):
        pass

simple_kernel()
```
does this:
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
failed to unpack int64

File "gi196.py", line 6:
def simple_kernel():
    for x,y in literal_unroll(((1,2),(2,3),(3,4))):
```
user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_5411: state: open
title: Avoid calling typers/overloads without literal types
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Type inference currently calls every typing template twice: once using literal types if available, and again without literal types. I believe the original purpose was backwards compatibility when literal types were introduced.

However, this can be confusing for developers. For example, if an overload expects a literal type but fails due to another reason, Numba tries again without literal types. The developer doesn't see the original error, and may be confused why the overload is called without literal types (our engineers have experienced these issues *many* times).

Ideally, all templates should handle literal types so Numba wouldn't need to have this behavior. In the short term, there could be an option for overloads (e.g. "literal_only=True").

user: ehsantn
issue_5404: state: open
title: Yielding numpy array results in segfault 
body: I stumbled into the following issue (apologies if this is already documented/reported, but I couldn't find it among the open issues) : 

```python
from numba import njit
import numpy as np


@njit
def generator():
    state = np.zeros(10)

    for i in range(10):
        state.fill(i)
        yield state


for g in generator():
    print(g)
```

expected result (without njit) would be something like 
```
[0. 0.]
[1. 1.]
[2. 2.]
[3. 3.]
````

however when running with njit this results in a segmentation fault after the second iteration 
```
[0. 0. 0. 0. 0. 0. 0. 0. 0. 0.]
[1. 1. 1. 1. 1. 1. 1. 1. 1. 1.]
Python(25110,0x1159fe5c0) malloc: *** error for object 0x7fd50b564b30: pointer being freed was not allocated
Python(25110,0x1159fe5c0) malloc: *** set a breakpoint in malloc_error_break to debug
``` 

I am using numba 0.48.0 and python 3.7.6 on MacOs under Conda. Same thing happens with numba 0.47.0 and python 3.7.4 without Conda. 

It might be related to #5350 



user: gcarleo
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_5395: state: open
title: Unable to define `cfunc` with scalar `bool*` and an `njit`ed UDF
body: ## Reporting a bug

My workflow of accepting a user-provided UDF and compiling as a `cfunc` with an explicit signature fails for boolean types at definition of the `cfunc` function.

For example, the following works fine:
```python
import numba
import numba.types as nt

@numba.njit
def udf_works(x):
    return 2 * x

@numba.cfunc(nt.void(nt.CPointer(nt.float32), nt.CPointer(nt.float32)), nopython=True)
def unary_wrapper(z, x):
    result = udf_works(x[0])
    z[0] = result
```
But the following fails:
```python
import numba
import numba.types as nt

@numba.jit
def udf_fails(x):
    return x > 0

@numba.cfunc(nt.void(nt.CPointer(nt.bool_), nt.CPointer(nt.float32)), nopython=False)
def unary_wrapper(z, x):
    result = udf_fails(x[0])
    z[0] = result
```
with the traceback
<details>

```python-traceback
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower_inst(self, inst)
    397             try:
--> 398                 impl = self.context.get_function('static_setitem', signature)
    399             except NotImplementedError:

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/targets/base.py in get_function(self, fn, sig, _firstcall)
    560             self.refresh()
--> 561             return self.get_function(fn, sig, _firstcall=False)
    562

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/targets/base.py in get_function(self, fn, sig, _firstcall)
    562
--> 563         raise NotImplementedError("No definition for lowering %s%s" % (key, sig))
    564

NotImplementedError: No definition for lowering static_setitem(bool*, int64, bool) -> none

During handling of the above exception, another exception occurred:

TypeError                                 Traceback (most recent call last)
~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    716     try:
--> 717         yield
    718     except NumbaError as e:

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    287                                    loc=self.loc, errcls_=defaulterrcls):
--> 288                 self.lower_inst(inst)
    289         self.post_block(block)

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower_inst(self, inst)
    400                 return self.lower_setitem(inst.target, inst.index_var,
--> 401                                           inst.value, signature)
    402             else:

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower_setitem(self, target_var, index_var, value_var, signature)
    507
--> 508         return impl(self.builder, (target, index, value))
    509

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/targets/base.py in __call__(self, builder, args, loc)
   1145     def __call__(self, builder, args, loc=None):
-> 1146         res = self._imp(self._context, builder, self._sig, args, loc=loc)
   1147         self._context.add_linking_libs(getattr(self, 'libs', ()))

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/targets/base.py in wrapper(*args, **kwargs)
   1175                 kwargs.pop('loc')     # drop unused loc
-> 1176                 return fn(*args, **kwargs)
   1177

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/targets/builtins.py in setitem_cpointer(context, builder, sig, args)
    146     elem_ptr = builder.gep(base_ptr, [idx])
--> 147     builder.store(val, elem_ptr)
    148

~/miniconda3/envs/numba/lib/python3.7/site-packages/llvmlite/ir/builder.py in store(self, value, ptr, align)
    739             raise TypeError("cannot store %s to %s: mismatching types"
--> 740                             % (value.type, ptr.type))
    741         st = instructions.StoreInstr(self.block, value, ptr)

TypeError: cannot store i1 to i8*: mismatching types

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-2-157d2c28e29c> in <module>
      4
      5
----> 6 @numba.cfunc(nt.void(nt.CPointer(nt.bool_), nt.CPointer(nt.float32)), nopython=False)
      7 def unary_wrapper(z, x):
      8     result = udf_fails(x[0])

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/decorators.py in wrapper(func)
    257         if cache:
    258             res.enable_caching()
--> 259         res.compile()
    260         return res
    261

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/ccallback.py in compile(self)
     68                                          self._targetdescr.target_context)
     69         if cres is None:
---> 70             cres = self._compile_uncached()
     71             self._cache.save_overload(self._sig, cres)
     72         else:

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/ccallback.py in _compile_uncached(self)
     82
     83         # Compile native function
---> 84         cres = self._compiler.compile(sig.args, sig.return_type)
     85         assert not cres.objectmode  # disabled by compiler above
     86         fndesc = cres.fndesc

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     75
     76     def compile(self, args, return_type):
---> 77         status, retval = self._compile_cached(args, return_type)
     78         if status:
     79             return retval

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/dispatcher.py in _compile_cached(self, args, return_type)
     89
     90         try:
---> 91             retval = self._compile_core(args, return_type)
     92         except errors.TypingError as e:
     93             self._failed_cache[key] = e

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/dispatcher.py in _compile_core(self, args, return_type)
    107                                       args=args, return_type=return_type,
    108                                       flags=flags, locals=self.locals,
--> 109                                       pipeline_class=self.pipeline_class)
    110         # Check typing error if object mode is used
    111         if cres.typing_error is not None and not flags.enable_pyobject:

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    549     pipeline = pipeline_class(typingctx, targetctx, library,
    550                               args, return_type, flags, locals)
--> 551     return pipeline.compile_extra(func)
    552
    553

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    329         self.state.lifted = ()
    330         self.state.lifted_from = None
--> 331         return self._compile_bytecode()
    332
    333     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    391         """
    392         assert self.state.func_ir is None
--> 393         return self._compile_core()
    394
    395     def _compile_ir(self):

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    371                 self.state.status.fail_reason = e
    372                 if is_final_pipeline:
--> 373                     raise e
    374         else:
    375             raise CompilerError("All available pipelines exhausted")

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    362             res = None
    363             try:
--> 364                 pm.run(self.state)
    365                 if self.state.cr is not None:
    366                     break

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler_machinery.py in run(self, state)
    345                     (self.pipeline_name, pass_desc)
    346                 patched_exception = self._patch_error(msg, e)
--> 347                 raise patched_exception
    348
    349     def dependency_analysis(self):

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler_machinery.py in run(self, state)
    336                 pass_inst = _pass_registry.get(pss).pass_inst
    337                 if isinstance(pass_inst, CompilerPass):
--> 338                     self._runPass(idx, pass_inst, state)
    339                 else:
    340                     raise BaseException("Legacy pass in use")

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler_machinery.py in _runPass(self, index, pss, internal_state)
    300             mutated |= check(pss.run_initialization, internal_state)
    301         with SimpleTimer() as pass_time:
--> 302             mutated |= check(pss.run_pass, internal_state)
    303         with SimpleTimer() as finalize_time:
    304             mutated |= check(pss.run_finalizer, internal_state)

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/compiler_machinery.py in check(func, compiler_state)
    273
    274         def check(func, compiler_state):
--> 275             mangled = func(compiler_state)
    276             if mangled not in (True, False):
    277                 msg = ("CompilerPass implementations should return True/False. "

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/typed_passes.py in run_pass(self, state)
    405
    406         # TODO: Pull this out into the pipeline
--> 407         NativeLowering().run_pass(state)
    408         lowered = state['cr']
    409         signature = typing.signature(state.return_type, *state.args)

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/typed_passes.py in run_pass(self, state)
    347                 lower = lowering.Lower(targetctx, library, fndesc, interp,
    348                                        metadata=metadata)
--> 349                 lower.lower()
    350                 if not flags.no_cpython_wrapper:
    351                     lower.create_cpython_wrapper(flags.release_gil)

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower(self)
    193         if self.generator_info is None:
    194             self.genlower = None
--> 195             self.lower_normal_function(self.fndesc)
    196         else:
    197             self.genlower = self.GeneratorLower(self)

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    246         # Init argument values
    247         self.extract_function_arguments()
--> 248         entry_block_tail = self.lower_function_body()
    249
    250         # Close tail of entry block

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower_function_body(self)
    271             bb = self.blkmap[offset]
    272             self.builder.position_at_end(bb)
--> 273             self.lower_block(block)
    274
    275         self.post_lower()

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    286             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    287                                    loc=self.loc, errcls_=defaulterrcls):
--> 288                 self.lower_inst(inst)
    289         self.post_block(block)
    290

~/miniconda3/envs/numba/lib/python3.7/contextlib.py in __exit__(self, type, value, traceback)
    128                 value = type()
    129             try:
--> 130                 self.gen.throw(type, value, traceback)
    131             except StopIteration as exc:
    132                 # Suppress StopIteration *unless* it's the same exception that

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    723         from numba import config
    724         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 725         six.reraise(type(newerr), newerr, tb)
    726
    727

~/miniconda3/envs/numba/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    667         if value.__traceback__ is not tb:
    668             raise value.with_traceback(tb)
--> 669         raise value
    670
    671 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
cannot store i1 to i8*: mismatching types

File "<ipython-input-2-157d2c28e29c>", line 9:
def unary_wrapper(z, x):
    <source elided>
    result = udf_fails(x[0])
    z[0] = result
    ^

[1] During: lowering "z[0] = result" at <ipython-input-2-157d2c28e29c> (9)
```
</details>

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).
user: eriknw
labels: good second issue: A good issue for second time contributors
issue_5393: state: open
title: Update Integer and _NPDatetimeBase classes  to use @property for bitwidth/signed & unit respectively
body: # Description
Issue #5246.
Makes `bitwidth` and `signed`  properties of the `Integer` class.
And `unit` for `_NPDatetimeBase` for `timedelta64` and `datetime64`.

# Testing
Added  unit tests to `numba/tests/test_types.py`

```
$ python -m numba.runtests  numba.tests.test_types
...............x......................
----------------------------------------------------------------------
Ran 38 tests in 0.791s

OK (expected failures=1)
```

Also showing behavior from the REPL:
```
$ python
Python 3.6.10 |Anaconda, Inc.| (default, Jan  7 2020, 15:01:53) 
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from numba.core import types
>>> int16 = types.Integer.from_bitwidth(16)
>>> int16.bitwidth # show getter
16
>>> int16.bitwidth = 32 # show error on setter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ssikdar1/numba/numba/core/types/scalars.py", line 50, in bitwidth
    raise Exception("Cannot re-define bitwidth of integer")
Exception: Cannot re-define bitwidth of integer
>>> 
>>> int16.signed # show getter
True
>>> int16.signed = False # show error on setter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ssikdar1/numba/numba/core/types/scalars.py", line 61, in signed
    raise Exception("Cannot re-define sign of integer")
Exception: Cannot re-define sign of integer
>>> 
```

```
>>> from numba.core import types
>>> ty = types.NPDatetime('s')
>>> ty.unit # getter
's'
>>> ty.unit = '' # setter exception
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ssikdar1/numba/numba/core/types/scalars.py", line 177, in unit
    raise Exception("Cannot redefine unit of _NPDatetimeBase")
Exception: Cannot redefine unit of _NPDatetimeBase
>>> 
>>> ty = types.NPTimedelta('s')
>>> ty.unit # getter
's'
>>> ty.unit = '' # setter exception
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ssikdar1/numba/numba/core/types/scalars.py", line 177, in unit
    raise Exception("Cannot redefine unit of _NPDatetimeBase")
Exception: Cannot redefine unit of _NPDatetimeBase
>>> 
```
user: ssikdar1
issue_5387: state: open
title: Prevent LLVM parsing errors arising from nonsensical code and literal_unroll
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Whilst looking at: https://gitter.im/numba/numba?at=5e6b22b6467c85423300be5e

I wrote this, which contains a mistake rendering it nonsensical because it's trying to index a tuple with a function:
```python
import numba
from numba import literal_unroll

@numba.njit(numba.float32())
def inner_function_1():
    return 1.0

@numba.njit(numba.float32())
def inner_function_2():
    return 2.0

@numba.njit
def outer_function(inner_function):
    return inner_function()

@numba.njit
def outer_function_iterable(inner_functions):
    result = 0.0
    for i in literal_unroll(inner_functions):
        result += inner_functions[i]()
    return result

a = (inner_function_1, inner_function_2)
outer_function_iterable(a)
```
without the JIT the error message reads:
```
    result += inner_functions[i]()
TypeError: tuple indices must be integers or slices, not function
```
with the JIT the error message is:
```
RuntimeError: Failed in nopython mode pipeline (step: nopython mode backend)
LLVM IR parsing error
<string>:589:10: error: switch condition must have integer type
  switch i8* %".324", label %"typed_switch.else.1" [i64 0, label %"typed_switch.0.1" i64 -2, label %"typed_switch.0.1" i64 1, label %"typed_switch.1.1" i64 -1, label %"typed_switch.1.1"]
```
i.e. Numba failed to assess that this is invalid, managed to generate some IR and then attempted to lower it.
user: stuartarchibald
labels: llvm: LLVM related issues
llvmlite: llvmlite related problem
issue_5378: state: open
title: Improvements to tuple_setitem
body: Improvements to `tuple_setitem`:
- Permit setting items of heterogeneous tuples
  (llvm requires constant index)
- sanity-checking inputs (boundscheck, type checks)
user: ARF1
issue_5377: state: open
title: Confirm support for try/except use in objmode block
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the ~latest released~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
This:
```python
from numba import njit, objmode
import numpy as np

@njit
def foo():
    with objmode():
        try:
            print('{}'.format("unsupported opcodes"))
        except:
            pass

foo()
```
does this:
```
$ python gi185.py 
Traceback (most recent call last):
  File "gi185.py", line 12, in <module>
    foo()
NameError: global name 'mark_try_block' is not defined
```
which either needs fixing, or a better error message should appear.
user: stuartarchibald
labels: objectmode: object mode related issue
bug - failure to compile: Bugs: failed to compile valid code
issue_5375: state: open
title: Deprecate record access by attr in CUDA target
body: In the CUDA target it is possible to access record items as attrs, for example:

```python
point_type = [('x', np.float64), ('y', np.float64)]
points = np.recarray(1, dtype=point_type)

@cuda.jit
def move_to_origin(point):
    point.x = 0
    point.y = 0

move_to_origin[1, 1](points[0])
```

This is not legal in normal Python / NumPy - removing the `@cuda.jit` would require the following syntactic change in `move_to_origin`:

```python
def move_to_origin(point):
    point['x'] = 0
    point['y'] = 0
```

The former syntax should be deprecated, for consistency with non-cuda-jitted Python code. Any code impacted by the deprecation can be fixed up by substituting the former syntax for the latter.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_5373: state: open
title: Numba Sort is Significantly Slower Than NumPy Sort
body: We are leveraging Numba in the STUMPY package and @mexxexx and I are seeing a significant difference in performance when sorting a NumPy array. The original profiling can be found [here](https://github.com/TDAmeritrade/stumpy/issues/135#issuecomment-596997032) but I'll paste the results below:

> I did some profiling regarding the sorting aspect (jupyter notebook in firefox, Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, 4 threads):

```
def sort_numpy(T, d, k):
    return np.sort(T, axis=0)

@njit(parallel=True, fastmath=True)
def sort_numba(T, d, k):
    for i in prange(k):
        # T[:,i] = np.sort(T[:, i]) ## no assignment as we don't want to actually sort T
        np.sort(T[:, i])

T = np.random.uniform(-100, 100, (d, k))
```

>I precompiled `sort_numba`. and got the following results:

`d=5`, `k=10000`:
```
>>> %timeit -n 1000 sort_numpy(T, d, k)
295 µs ± 10.1 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
>>> %timeit -n 100 sort_numba(T, d, k)
6.69 ms ± 30.4 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
```

`d=5`, `k=100000`:
```
>>> %timeit -n 1000 sort_numpy(T, d, k)
3.08 ms ± 60.8 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
>>> %timeit -n 100 sort_numba(T, d, k)
66.2 ms ± 82.7 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
```

`d=50`, `k=10000`:
```
>>> %timeit -n 1000 sort_numpy(T, d, k)
11.2 ms ± 81.4 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
>>> %timeit -n 1000 sort_numba(T, d, k)
6.58 ms ± 10.9 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

> So sorting with numpy is orders of magnitude faster for a small number of dimensions and long time serieses, the case that we usually have.

Is this expected or are we doing something wrong here?
user: seanlaw
labels: performance - run time: Performance issue occurring at run time.
issue_5372: state: open
title: Produce better error message for the unsupported case of iteration over an empty tuple/change empty tuple typing to UniTuple.
body: On the current master, iteration over an empty tuple fails:

```python
from numba import njit

indices = tuple()

@njit
def testnumba():
    for i in indices:
        print(i)
    else:
        print('iteration done')


testnumba()
```

Output:
```
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of getiter with parameters (Tuple())
 * parameterized
[1] During: typing of intrinsic-call at c:\Users\My User\Documents\numba\unroll.py (7)

File "unroll.py", line 7:
def testnumba():
    for i in indices:
    ^
```
user: ARF1
labels: good second issue: A good issue for second time contributors
issue_5367: state: open
title: SimpleIteratorType issues
body: As a side-note, I noticed that the `SimpleIteratorType` uses are just odd in the codebase. For example, `RangeType` is bypassing it's parent constructor to workaround the cyclic dependency problem being fixed here. That's something that should be addressed in a different PR.

_Originally posted by @sklam in https://github.com/numba/numba/pull/5361#issuecomment-596530285_
user: sklam
issue_5364: state: open
title: RuntimeError: missing environment when iterating over closure in intrinsic
body: On the current master, attempting to iterate over a closure variable in an intrinsic produces `RuntimeError: missing environment`. Wrapping the closure variable `indices` in `literal_unroll` fixes the problem. Not sure whether this is a bug.

```python
from numba import njit, literal_unroll
from numba.core import types, typing
from numba.extending import intrinsic


@intrinsic
def testintrinsic(typingctx, length):
    indices = tuple(range(length.literal_value))

    sig = types.NoneType('none')(length)

    def codegen(context, builder, signature, args):
        def impl():
            for i in indices:
                print(i)

        inner_argtypes = []
        inner_sig = typing.signature(types.NoneType('none'), *inner_argtypes)
        inner_args = []
        res = context.compile_internal(builder, impl, inner_sig, inner_args)
        return res

    return sig, codegen


@njit
def testnumba():
    testintrinsic(10)


testnumba()
```

Output:
```
  File "c:\Users\My User\Documents\numba\unroll.py", line 31, in <module>
    testnumba()
RuntimeError: missing Environment
```
user: ARF1
labels: bug - ice: Bugs: internal compiler error
issue_5363: state: open
title: Make is really obvious that the "dev" docs are for unrelease/development versions
body: It's not uncommon for users and search engines to find the dev docs and read them as "latest", the only real way to tell is the URL:
http://numba.pydata.org/numba-doc/dev/index.html
vs
http://numba.pydata.org/numba-doc/latest/index.html
i.e. `dev` vs. `latest` or that the release number is different, i.e. it's 0.49 vs 0.48 at present, however, unless you keep track of Numba development closely, that 0.49 isn't released yet is unlikely obvious.

Suggested fix: Make it really obvious that the "dev" version is for an unreleased version of Numba, perhaps add a header/banner to all pages expressing this and where to get dev builds and where the latest released version docs are?
user: stuartarchibald
issue_5354: state: open
title: numpy.take cannot compile with typed.List as indices parameter
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

-->

Hi,

Implementations of some numpy functions that can accept old reflected lists as parameters cannot compile in nopython mode when typed.List instances are provided. One of these functions is np.take, see the reproducer and error below:
 
```
    def test_numba_typed_list_as_arg_to_numpy(self):
        import numpy as np
        import numba
        from numba import types
        from numba.typed import Dict, List
        list_type1 = types.ListType(types.int64)

        def test_impl(n, take_pos):
            # Numba implementations of numpy functions support old reflected lists only
            arr = np.arange(n)
            a_list = List.empty_list(types.int64)
            a_list.extend(take_pos)

            res = np.take(arr, a_list)
            # workaround below:
#             res = np.take(arr, list(a_list))
            return res

        jitted = numba.njit(test_impl)

        n = 11
        good_elements_indexes = [5, 2, 1]
        print(jitted(n, good_elements_indexes))
```

Error:
```
======================================================================
ERROR: test_numba_typed_list_as_arg_to_numpy (sdc.tests.test_series.TestSeries)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\hpat\sdc\tests\test_series.py
", line 6802, in test_numba_typed_list_as_arg_to_numpy
    print(jitted(n, good_elements_indexes))
  File "c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\numba\disp
atcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\numba\disp
atcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\numba\six.
py", line 668, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<function take at 0x000002306BBDAEE0>) with argument(s) of type(
s): (array(int64, 1d, C), ListType[int64])
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the
 named function.
[1] During: resolving callee type: Function(<function take at 0x000002306BBDAEE0>)
[2] During: typing of call at C:\Users\akozlov\AppData\Local\Continuum\anaconda3\hpat\sd
c\tests\test_series.py (6793)


File "sdc\tests\test_series.py", line 6793:
        def test_impl(n, take_pos):
            <source elided>

            res = np.take(arr, a_list)
            ^


----------------------------------------------------------------------
Ran 1 test in 0.358s

FAILED (errors=1)
```

Tested on:
# Name                    Version                   Build  Channel
numba                     0.48.0                    dev_0    <develop>

Can you please fix that?

Best Regards,
Alexey.
user: kozlov-alexey
issue_5353: state: open
title: typed.List variables cannot be assigned from reflected_list
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Hi, 

On Numba 0.48.0 we experience a problem with typed.Lists which cannot be assigned from instances of normal or reflected list, probably due to the lack of implicit conversions, e.g. with both reproducers below compilation fails with errors similar to:

```
======================================================================
ERROR: test_numba_typed_vs_reflected_lists (sdc.tests.test_series.TestSeries)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\akozlov\AppData\Local\Continuum\anaconda3\hpat\sdc\tests\test_series.py
", line 6777, in test_numba_typed_vs_reflected_lists
    print(jitted(ref_list))
  File "c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\numba\disp
atcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\numba\disp
atcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\numba\six.
py", line 668, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function setitem>) with argument(s) of type(s): (DictT
ype[int64,ListType[int64]], Literal[int](3), reflected list(int32))
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast reflected list(int32) to ListType[int64]: %".51" = load {i8*, i8*}, {i8*, i8
*}* %"value"

File "..\numba_master\numba\numba\dictobject.py", line 683:
    def impl(d, key, value):
        <source elided>
        castedkey = _cast(key, keyty)
        castedval = _cast(value, valty)
        ^

[1] During: lowering "$18call_function.7 = call $12load_global.4(value, $16load_deref.6,
 func=$12load_global.4, args=[Var(value, dictobject.py:682), Var($16load_deref.6, dictob
ject.py:683)], kws=(), vararg=None)" at c:\users\akozlov\appdata\local\continuum\anacond
a3\numba_master\numba\numba\dictobject.py (683)
    raised from c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\nu
mba\six.py:669
In definition 3:
    LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast reflected list(int32) to ListType[int64]: %".51" = load {i8*, i8*}, {i8*, i8
*}* %"value"

File "..\numba_master\numba\numba\dictobject.py", line 683:
    def impl(d, key, value):
        <source elided>
        castedkey = _cast(key, keyty)
        castedval = _cast(value, valty)
        ^

[1] During: lowering "$18call_function.7 = call $12load_global.4(value, $16load_deref.6,
 func=$12load_global.4, args=[Var(value, dictobject.py:682), Var($16load_deref.6, dictob
ject.py:683)], kws=(), vararg=None)" at c:\users\akozlov\appdata\local\continuum\anacond
a3\numba_master\numba\numba\dictobject.py (683)
    raised from c:\users\akozlov\appdata\local\continuum\anaconda3\numba_master\numba\nu
mba\six.py:669
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
In definition 10:
    All templates rejected with literals.
In definition 11:
    All templates rejected without literals.
In definition 12:
    All templates rejected with literals.
In definition 13:
    All templates rejected without literals.
In definition 14:
    All templates rejected with literals.
In definition 15:
    All templates rejected without literals.
In definition 16:
    TypingError: Operator setitem(). The object
 given: DictType[int64,ListType[int64]]
 expected: SeriesType
    raised from C:\Users\akozlov\AppData\Local\Continuum\anaconda3\hpat\sdc\utilities\sd
c_typing_utils.py:75
In definition 17:
    TypingError: Operator setitem(). The object
 given: DictType[int64,ListType[int64]]
 expected: SeriesType
    raised from C:\Users\akozlov\AppData\Local\Continuum\anaconda3\hpat\sdc\utilities\sd
c_typing_utils.py:75
This error is usually caused by passing an argument of a type that is unsupported by the
 named function.
[1] During: typing of staticsetitem at C:\Users\akozlov\AppData\Local\Continuum\anaconda
3\hpat\sdc\tests\test_series.py (6766)

File "sdc\tests\test_series.py", line 6766:
        def test_impl(ref_list):
            <source elided>
            a_dict = Dict.empty(types.int64, list_type1)
            a_dict[3] = ref_list
            ^
```

Can you please fix that?

Reproducers:
```
    def test_numba_typed_vs_reflected_lists(self):
        import numba
        from numba import types
        from numba.typed import Dict, List
        list_type1 = types.ListType(types.int64)

        def test_impl(ref_list):
            # normal python list is still by default old List type
            # so this fails to compile as we assign reflected list 
            # to a variable that expects typed.List
#             ref_list = [i for i in np.arange(n) if i in values]
            a_dict = Dict.empty(types.int64, list_type1)
            a_dict[3] = ref_list

            # example workaround:
#             a_dict[3] = List.empty_list(types.int64)
#             a_dict[3].extend(ref_list)

            return len(a_dict[3])
        jitted = numba.njit(test_impl)

        n = 10
        ref_list = list(np.arange(n))
        print(jitted(ref_list))
```
or
```
    def test_numba_typed_vs_reflected_lists(self):
        import numba
        from numba import types
        from numba.typed import Dict, List
        list_type1 = types.ListType(types.int64)

        def test_impl(n, values):
            # normal python list is still by default old List type
            # so this fails to compile as we assign reflected list 
            # to a variable that expects typed.List
            ref_list = [i for i in np.arange(n) if i in values]
            a_dict = Dict.empty(types.int64, list_type1)
            a_dict[3] = ref_list

            # example workaround:
#             a_dict[3] = List.empty_list(types.int64)
#             a_dict[3].extend(ref_list)

            return len(a_dict[3])
        jitted = numba.njit(test_impl)

        n = 10
        good_values = {1, 2, 4, 6}
        print(jitted(n, good_values))
```
 
# Name                    Version                   Build  Channel
numba                     0.48.0                    dev_0    <develop>


Best Regards,
Alexey.

user: kozlov-alexey
issue_5350: state: open
title: yield statement yields leaky memory
body: Potentially related to: https://github.com/numba/numba/issues/1361, maintainers please let me know if you prefer this discussion to be moved to that issue and I'll close this.

[+] I am using the latest [stable] released version of Numba '0.48.0'
[+] I have included below a minimal working reproducer

The following minimum reproducible example illustrates a substantial memory leak in the numba's `yield` statement.

To show the problem, I write 3 different functions:

1. The first is a native python generator
2. The second is the same generator numba-ized
3. The third is a numba-ized function with all yield statements replaced with return statements

The code runs each of these functions 1000 times. In case 2 the peak memory incrementally increases over time. 

Here is the reproducible example:

```python
#! /usr/bin/env python
import sys
import resource
import numpy as np

from numba import jit

# returns peak memory usage
mem = lambda: resource.getrusage(resource.RUSAGE_SELF).ru_maxrss

def get_blocks_native_python(array, value):
    """Generator that returns blocks of consecutive numbers

    Parameters
    ==========
    array : array
        a numerical numpy array.

    value : number
        The number you want to get constant blocks for.

    Examples
    ========

    >>> a = np.array([47, 47, 47, 49, 50, 47, 47, 99])
    >>> for i in get_blocks_native_python(a, 47): print(i)
    (0, 3)
    (5, 7)
    """

    matching = False
    for i in range(len(array)):
        if array[i] == value:
            if not matching:
                start = i
                matching = True
        else:
            if matching:
                matching = False
                yield start, i

    if matching:
        yield start, i + 1


@jit(nopython=True)
def get_blocks_generator(array, value):
    """As above, but with jit decorator"""

    matching = False
    for i in range(len(array)):
        if array[i] == value:
            if not matching:
                start = i
                matching = True
        else:
            if matching:
                matching = False
                yield start, i

    if matching:
        yield start, i + 1


@jit(nopython=True)
def get_blocks_function(array, value):
    """Returns instead of yields"""

    matching = False
    for i in range(len(array)):
        if array[i] == value:
            if not matching:
                start = i
                matching = True
        else:
            if matching:
                matching = False
                return start, i

    if matching:
        return start, i + 1


iterations = 1000

print("=====================")
print("Testing native python")
print("=====================")
initial_mem = mem()
prev_mem = initial_mem
for i in range(iterations):
    # create an array of 1's and 0's, high bias towards 0's
    a = np.random.choice([0,1], p=[0.95, 0.05], size=100)

    # get first block of zeros in the array
    block = next(get_blocks_native_python(a, 0))

    # print change in peak memory
    curr_mem = mem()
    if curr_mem != prev_mem:
        print(f"iteration {i}: peak memory increased by {curr_mem - prev_mem}")
    prev_mem = curr_mem

final_mem = prev_mem

print(f"Total change in memory: {final_mem - initial_mem}")

print("=======================")
print("Testing numba generator")
print("=======================")
initial_mem = mem()
prev_mem = initial_mem
for i in range(iterations):
    # create an array of 1's and 0's, high bias towards 0's
    a = np.random.choice([0,1], p=[0.95, 0.05], size=100)

    # get first block of zeros in the array
    block = next(get_blocks_generator(a, 0))

    # print change in peak memory
    curr_mem = mem()
    if curr_mem != prev_mem:
        print(f"iteration {i}: peak memory increased by {curr_mem - prev_mem}")
    prev_mem = curr_mem

final_mem = prev_mem

print(f"Total change in memory: {final_mem - initial_mem}")

print("======================")
print("Testing numba function")
print("======================")
initial_mem = mem()
prev_mem = initial_mem
for i in range(iterations):
    # create an array of 1's and 0's, high bias towards 0's
    a = np.random.choice([0,1], p=[0.95, 0.05], size=100)

    # get first block of zeros in the array
    block = get_blocks_function(a, 0)

    # print change in peak memory
    curr_mem = mem()
    if curr_mem != prev_mem:
        print(f"iteration {i}: peak memory increased by {curr_mem - prev_mem}")
    prev_mem = curr_mem

final_mem = prev_mem

print(f"Total change in memory: {final_mem - initial_mem}")
```

When this is run, the following output is produced.

The first chunk of output, case 1, looks like this:

```
=====================
Testing native python
=====================
iteration 0: peak memory increased by 204800
iteration 1: peak memory increased by 4096
Total change in memory: 208896
```

Besides iteration 0 and 1, the memory remains constant.

The second chunk of output, case 2, looks like this:

```
=======================
Testing numba generator
=======================
iteration 0: peak memory increased by 15704064
iteration 40: peak memory increased by 4096
iteration 46: peak memory increased by 4096
iteration 51: peak memory increased by 4096
iteration 56: peak memory increased by 4096
iteration 61: peak memory increased by 4096
iteration 66: peak memory increased by 4096
iteration 71: peak memory increased by 4096
iteration 76: peak memory increased by 4096
iteration 81: peak memory increased by 4096
iteration 87: peak memory increased by 4096
iteration 92: peak memory increased by 4096
iteration 108: peak memory increased by 4096
iteration 113: peak memory increased by 4096
iteration 118: peak memory increased by 4096
iteration 123: peak memory increased by 4096
iteration 128: peak memory increased by 4096
iteration 133: peak memory increased by 4096
iteration 139: peak memory increased by 4096
iteration 144: peak memory increased by 4096
iteration 149: peak memory increased by 4096
iteration 154: peak memory increased by 4096
iteration 159: peak memory increased by 4096
iteration 164: peak memory increased by 4096
iteration 169: peak memory increased by 4096
iteration 174: peak memory increased by 4096
iteration 179: peak memory increased by 4096
iteration 185: peak memory increased by 4096
iteration 190: peak memory increased by 4096
iteration 195: peak memory increased by 4096
iteration 200: peak memory increased by 4096
iteration 205: peak memory increased by 4096
iteration 208: peak memory increased by 4096
iteration 210: peak memory increased by 4096
iteration 292: peak memory increased by 4096
iteration 297: peak memory increased by 4096
iteration 302: peak memory increased by 4096
iteration 308: peak memory increased by 4096
iteration 313: peak memory increased by 4096
iteration 318: peak memory increased by 4096
iteration 323: peak memory increased by 4096
iteration 328: peak memory increased by 4096
iteration 333: peak memory increased by 4096
iteration 338: peak memory increased by 4096
iteration 342: peak memory increased by 4096
iteration 351: peak memory increased by 4096
iteration 352: peak memory increased by 4096
iteration 357: peak memory increased by 4096
iteration 373: peak memory increased by 4096
iteration 385: peak memory increased by 4096
iteration 390: peak memory increased by 4096
iteration 395: peak memory increased by 4096
iteration 400: peak memory increased by 4096
iteration 441: peak memory increased by 4096
iteration 446: peak memory increased by 4096
iteration 451: peak memory increased by 4096
iteration 456: peak memory increased by 4096
iteration 461: peak memory increased by 4096
iteration 467: peak memory increased by 4096
iteration 472: peak memory increased by 4096
iteration 477: peak memory increased by 4096
iteration 482: peak memory increased by 4096
iteration 568: peak memory increased by 4096
iteration 620: peak memory increased by 4096
iteration 625: peak memory increased by 4096
iteration 631: peak memory increased by 4096
iteration 636: peak memory increased by 4096
iteration 641: peak memory increased by 4096
iteration 646: peak memory increased by 4096
iteration 651: peak memory increased by 4096
iteration 656: peak memory increased by 4096
iteration 661: peak memory increased by 4096
iteration 666: peak memory increased by 4096
iteration 671: peak memory increased by 4096
iteration 677: peak memory increased by 4096
iteration 682: peak memory increased by 4096
iteration 687: peak memory increased by 4096
iteration 692: peak memory increased by 4096
iteration 699: peak memory increased by 4096
iteration 703: peak memory increased by 4096
iteration 708: peak memory increased by 4096
iteration 713: peak memory increased by 4096
iteration 718: peak memory increased by 4096
iteration 724: peak memory increased by 4096
iteration 729: peak memory increased by 4096
iteration 734: peak memory increased by 4096
iteration 739: peak memory increased by 4096
iteration 744: peak memory increased by 4096
iteration 749: peak memory increased by 4096
iteration 754: peak memory increased by 4096
iteration 759: peak memory increased by 4096
iteration 765: peak memory increased by 4096
iteration 770: peak memory increased by 4096
iteration 775: peak memory increased by 4096
iteration 780: peak memory increased by 4096
iteration 785: peak memory increased by 4096
iteration 790: peak memory increased by 4096
iteration 795: peak memory increased by 4096
iteration 800: peak memory increased by 4096
iteration 805: peak memory increased by 4096
iteration 811: peak memory increased by 4096
iteration 816: peak memory increased by 4096
iteration 821: peak memory increased by 4096
iteration 826: peak memory increased by 4096
iteration 831: peak memory increased by 4096
iteration 866: peak memory increased by 4096
iteration 871: peak memory increased by 4096
iteration 875: peak memory increased by 4096
iteration 880: peak memory increased by 4096
iteration 886: peak memory increased by 4096
iteration 947: peak memory increased by 4096
iteration 952: peak memory increased by 4096
iteration 957: peak memory increased by 4096
iteration 962: peak memory increased by 4096
iteration 968: peak memory increased by 4096
iteration 973: peak memory increased by 4096
iteration 978: peak memory increased by 4096
iteration 983: peak memory increased by 4096
iteration 988: peak memory increased by 4096
iteration 994: peak memory increased by 4096
iteration 999: peak memory increased by 4096
Total change in memory: 16195584
```

Iteration 0 has a high memory usage caused by the the just-in-time compilation, but periodically, around ever 5 iterations once it stabilizes, the memory increases by 4096... This is the memory leak.

To test if this is specific to numba generators, here is the output to case 3, the same function body except with yield statements replaced with return statements.

```
======================
Testing numba function
======================
iteration 0: peak memory increased by 1617920
Total change in memory: 1617920
```

The above shows the corresponding numba _function_ does not have this memory leak.

----------------------------------------------------

I discovered this because in a software I'm developing for, I noticed a massive memory leak that makes use of the exact numba-ized generator described above. Here is the memory leak on a small dataset:

![image](https://user-images.githubusercontent.com/8688665/75901329-f5349c00-5e03-11ea-8c00-58b845644f0e.png)

After commenting out the numba decorator, here is the memory usage:

![image](https://user-images.githubusercontent.com/8688665/75901636-74c26b00-5e04-11ea-9e8c-8087d1c1f526.png)

This is a very small dataset, on realistic datasets this amounts to hundreds of GB of memory leakage that accumulates within hours.
user: ekiefl
labels: bug - memory leak: Memory leak
issue_5349: state: open
title: Parfors, LLVM IR Parsing error from conditional needing cast.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the ~latest released~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).
This:
```python
from numba import prange, njit

@njit(parallel=True)
def foo():
    for i in prange(10./1.):
        if i == 0:
            pass

foo()
```
does this:
```
RuntimeError: Failed in nopython mode pipeline (step: nopython mode backend)
LLVM IR parsing error
<string>:41:17: error: invalid cast opcode for cast from 'double' to 'i64'
  %".19" = sext double %".16" to i64
```

user: stuartarchibald
issue_5344: state: open
title: literal_unroll != numba.literal_unroll?
body: Hi, I'm seeing a strange behaviour, confirmed in two v0.48 environments. The same function behaves differently when using `literal_unroll` or `numba.literal_unroll`.

```python
def make_foo():
    x = (1, 2)
    @njit
    def _foo_unrolled_global():
        a = 0
        for val in numba.literal_unroll(x):
            a += val
        return a
    return _foo_unrolled_global


def make_bar():
    x = (1, 2)
    @njit
    def _bar_unrolled_global():
        a = 0
        for val in literal_unroll(x):
            a += val
        return a
    return _bar_unrolled_global

foo = make_foo()
foo()
# OK

bar = make_bar()
bar()
UnsupportedError: Failed in nopython mode pipeline (step: handles literal_unroll)
Failed in literal_unroll_subpipeline mode pipeline (step: switch const list for tuples)
Invalid use of literal_unroll, argument should be a tuple or a list of constant values, found unknown problem

```

I know the second error is related (and fixed by) #5182, so it should not fail in v0.49, but the puzzle is why the first one does not fail in v0.48.

cc: @stuartarchibald 


user: luk-f-a
issue_5339: state: open
title: Add a `as_constant` helper for forcing computations to compile-time
body: ## Feature request

I'd like to be able to write something like the following:
```python
from types import SimpleNamespace
a = SimpleNamespace(b=2)

@numba.njit
def foo():
    # return a.b   # fails, because numba tries to evaluate at runtime
    return numba.as_constant(lambda: a.b)
```
My understanding is that `as_constant(a.b)` would be tricky to extract in numba, but I think `as_constant(lambda: a.b)` would be more easy to pull out the of the python bytecode.


A more complex situation would be one where I want the constant to depend on the argument types:
```python
def make_multiply_by(a):
    @numba.njit
    def inner(b):
        # trickier - want to expose the type information of `b` here, without actually using the value
        # information.
        a_copy = numba.as_constant(lambda: a.astype(b.dtype))
    return inner
```

user: eric-wieser
issue_5336: state: open
title: NativeValue.cleanup doesn't seem to be used consistently
body: This is a speculative report, but while trying to implement boxing and unboxing of my own compound type, I ran into some confusion about the nature of `NativeValue.cleanup`.

---

## Case A

Here's what seems to be the motivating case for `cleanup`:

https://github.com/numba/numba/blob/a4c4a8dceb0801672d6fda9199c36047dba16f0b/numba/core/boxing.py#L192-L203

As I read it, this returns either:

* A pointer to the buffer, no error set, and a cleanup function which emits code to release the buffer
* A null pointer, an error set, and a cleanup function which emits code that would segfault if called.

From this, the semantics seem to be:

* If you succeed, set `is_error` to `False`, and set `cleanup` to something that emits cleanup code
* If you fail, set `is_error` to `True`. The caller promises that the code emitted by `cleanup` is never called.

This is sort of consistent with the python model of either returning an object implementing `tp_del`, or returning `NULL` and performing all cleanup as the callee.

## Case B

Now let's look at tuple unboxing:

https://github.com/numba/numba/blob/a4c4a8dceb0801672d6fda9199c36047dba16f0b/numba/core/boxing.py#L528-L553

Here, we set `is_error` if the size does not match, yet continue unboxing anyway and generating cleanup tasks. If one of those unboxings fail, then we keep going anyway. There are at least two problems here:
* The attempt at providing a conditional clean up based on `size_matches` fails to achieve its intent (gh-5334), as wrapping a function definition in `c.builder.if_then` has no effect
* If is_error is set, then our cleanup function seemingly should not be invoked by the caller anyway (as we deduced in case A). If this happens, then none of the cleanup actually gets done, and we leak objects.

## Case C
Now let's look at `_lower_call_ObjModeDispatcher`:

https://github.com/numba/numba/blob/a4c4a8dceb0801672d6fda9199c36047dba16f0b/numba/core/lowering.py#L831-L854

Here, we:

* Call `cleanup` whether the error occured or not. This contradicts Case A, and as a result can cause a segfault.
* Call `cleanup` before we're done with the result, meaning that `output` is left dangling here.

---

Are the intended semantics of `cleanup` clearly defined anywhere? In the absence of a clear intent, I'd argue that everything should assume the model used by case A.

cc @stuartarchibald, whom via gitter I subjected to a barrage of questions about this.

user: eric-wieser
labels: discussion: An issue requiring discussion
issue_5332: state: open
title: literal_unroll for IntegerLiteral
body: Currently there seems to be no way to unroll a loop with `IntegerLiteral`. This would be very useful if one wanted to call a function that requires an IntegerLiteral as input (simulated by the `print` below).

The following variants are some that I have tried and they all fail:
```python
from numba import njit, literally, literal_unroll
from numba.core.types.misc import literal

size = 10

@njit
def testnumba():
    for i in literal_unroll(range(size)):
        print(literally(i))

testnumba()


indices = tuple(i for i in range(size))

@njit
def testnumba(indices):
    for i in literal_unroll(indices):
        print(literally(i))

testnumba(indices)


indices = tuple(literal(i) for i in range(size))

@njit
def testnumba(indices):
    for i in literal_unroll(range(size)):
        print(literally(i))

testnumba(indices)
```

I would be happy to try to work on implementing this, but to be honest, I have no idea where to start.
user: ARF1
issue_5329: state: open
title: Vectorization of structured types appears to be broken
body: I get a compile error when attempting to generate a structured data ufunc.  Structured data ufuncs appear to be well-supported by [numpy](https://docs.scipy.org/doc/numpy-1.13.0/user/c-info.ufunc-tutorial.html#example-numpy-ufunc-with-structured-array-dtype-arguments).

There's a StackOverflow discussion about it [here](https://stackoverflow.com/questions/60397879/how-can-i-use-numba-vectorize-ufunc-with-a-structured-numpy-array)

This *may* be related to #2475 

Min repro is

```python
import numpy
import numba

Structured = numpy.dtype([("a", numpy.int32), ("b", numpy.float64)])
numba_dtype = numba.from_dtype(Structured)

@numba.vectorize([numba.float64(numba_dtype)], target="cpu", nopython=True)
def vectorized(x):
    return 12.1

print(vectorized(numpy.empty((3,), dtype=Structured)))
```

Output is

> Traceback (most recent call last):
>   File "A:\work\model_engineering_trunk\tmp\np_utils.py", line 35, in <module>
>     print(vectorized(numpy.empty((3,), dtype=Structured)))
> TypeError: ufunc 'vectorized' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''
> 
user: nelson2005
issue_5321: state: open
title: literal_unroll fails with jitclass
body: - [x ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

When iterating over a tuple of indices and using those indices to get an item from an array stored in a jitclass the code fails if the loop uses `literal_unroll`.

```python
from numba import njit, literal_unroll, jitclass, types
import numpy as np

@jitclass(spec=[('data', types.float64[:])])
class COOArray:
    def __init__(self, data):
        self.data = data


@njit
def foo_unrolled(arr):
    idxs = (2, 3)
    a = 0
    for idx in literal_unroll(idxs):
        a += arr.data[idx]
    return a

@njit
def foo(arr):
    idxs = (2, 3)
    a = 0
    for idx in idxs:
        a += arr.data[idx]
    return a

arr = COOArray(np.ones(5))
foo(arr)
#passes
foo_unrolled(arr)
#fails
```
Error message:
Failed in nopython mode pipeline (step: handles literal_unroll)\n"Failed in literal_unroll_subpipeline mode pipeline (step: performs mixed container unroll)\\n\'args\'"


<details>
  <summary>Full error message:</summary>

```python
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-15-466268e2e215> in <module>
      1 arr = COOArray(np.ones(5))
----> 2 foo(arr)

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    418                     e.patch_message('\n'.join((str(e).rstrip(), help_msg)))
    419             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 420             raise e
    421 
    422     def inspect_llvm(self, signature=None):

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    351                 argtypes.append(self.typeof_pyval(a))
    352         try:
--> 353             return self.compile(tuple(argtypes))
    354         except errors.ForceLiteralArg as e:
    355             # Received request for compiler re-entry with the list of arguments

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\dispatcher.py in compile(self, sig)
    766             self._cache_misses[sig] += 1
    767             try:
--> 768                 cres = self._compiler.compile(args, return_type)
    769             except errors.ForceLiteralArg as e:
    770                 def folded(args, kws):

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\dispatcher.py in compile(self, args, return_type)
     75 
     76     def compile(self, args, return_type):
---> 77         status, retval = self._compile_cached(args, return_type)
     78         if status:
     79             return retval

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\dispatcher.py in _compile_cached(self, args, return_type)
     89 
     90         try:
---> 91             retval = self._compile_core(args, return_type)
     92         except errors.TypingError as e:
     93             self._failed_cache[key] = e

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\dispatcher.py in _compile_core(self, args, return_type)
    107                                       args=args, return_type=return_type,
    108                                       flags=flags, locals=self.locals,
--> 109                                       pipeline_class=self.pipeline_class)
    110         # Check typing error if object mode is used
    111         if cres.typing_error is not None and not flags.enable_pyobject:

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    549     pipeline = pipeline_class(typingctx, targetctx, library,
    550                               args, return_type, flags, locals)
--> 551     return pipeline.compile_extra(func)
    552 
    553 

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler.py in compile_extra(self, func)
    329         self.state.lifted = ()
    330         self.state.lifted_from = None
--> 331         return self._compile_bytecode()
    332 
    333     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler.py in _compile_bytecode(self)
    391         """
    392         assert self.state.func_ir is None
--> 393         return self._compile_core()
    394 
    395     def _compile_ir(self):

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler.py in _compile_core(self)
    371                 self.state.status.fail_reason = e
    372                 if is_final_pipeline:
--> 373                     raise e
    374         else:
    375             raise CompilerError("All available pipelines exhausted")

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler.py in _compile_core(self)
    362             res = None
    363             try:
--> 364                 pm.run(self.state)
    365                 if self.state.cr is not None:
    366                     break

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    345                     (self.pipeline_name, pass_desc)
    346                 patched_exception = self._patch_error(msg, e)
--> 347                 raise patched_exception
    348 
    349     def dependency_analysis(self):

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    336                 pass_inst = _pass_registry.get(pss).pass_inst
    337                 if isinstance(pass_inst, CompilerPass):
--> 338                     self._runPass(idx, pass_inst, state)
    339                 else:
    340                     raise BaseException("Legacy pass in use")

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in _runPass(self, index, pss, internal_state)
    300             mutated |= check(pss.run_initialization, internal_state)
    301         with SimpleTimer() as pass_time:
--> 302             mutated |= check(pss.run_pass, internal_state)
    303         with SimpleTimer() as finalize_time:
    304             mutated |= check(pss.run_finalizer, internal_state)

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in check(func, compiler_state)
    273 
    274         def check(func, compiler_state):
--> 275             mangled = func(compiler_state)
    276             if mangled not in (True, False):
    277                 msg = ("CompilerPass implementations should return True/False. "

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\untyped_passes.py in run_pass(self, state)
   1440         pm.add_pass(MixedContainerUnroller, "performs mixed container unroll")
   1441         pm.finalize()
-> 1442         pm.run(state)
   1443         return True
   1444 

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    345                     (self.pipeline_name, pass_desc)
    346                 patched_exception = self._patch_error(msg, e)
--> 347                 raise patched_exception
    348 
    349     def dependency_analysis(self):

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in run(self, state)
    336                 pass_inst = _pass_registry.get(pss).pass_inst
    337                 if isinstance(pass_inst, CompilerPass):
--> 338                     self._runPass(idx, pass_inst, state)
    339                 else:
    340                     raise BaseException("Legacy pass in use")

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in _runPass(self, index, pss, internal_state)
    300             mutated |= check(pss.run_initialization, internal_state)
    301         with SimpleTimer() as pass_time:
--> 302             mutated |= check(pss.run_pass, internal_state)
    303         with SimpleTimer() as finalize_time:
    304             mutated |= check(pss.run_finalizer, internal_state)

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\compiler_machinery.py in check(func, compiler_state)
    273 
    274         def check(func, compiler_state):
--> 275             mangled = func(compiler_state)
    276             if mangled not in (True, False):
    277                 msg = ("CompilerPass implementations should return True/False. "

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\untyped_passes.py in run_pass(self, state)
   1217         # keep running the transform loop until it reports no more changes
   1218         while(True):
-> 1219             stat = self.apply_transform(state)
   1220             mutated |= stat
   1221             if not stat:

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\untyped_passes.py in apply_transform(self, state)
   1084         # 2. Do the unroll, get a loop and process it!
   1085         lbl, info = literal_unroll_info.popitem()
-> 1086         self.unroll_loop(state, info)
   1087 
   1088         # 3. Rebuild the state, the IR has taken a hammering

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\untyped_passes.py in unroll_loop(self, state, loop_info)
   1122                         if stmt.value.value != getitem_target:
   1123                             dfn = func_ir.get_definition(stmt.value.value)
-> 1124                             args = getattr(dfn, 'args', False)
   1125                             if not args:
   1126                                 continue

~\miniconda3\envs\litt-conda3\lib\site-packages\numba\ir.py in __getattr__(self, name)
    380         if name.startswith('_'):
    381             return Inst.__getattr__(self, name)
--> 382         return self._kws[name]
    383 
    384     def __setattr__(self, name, value):

KeyError: 'Failed in nopython mode pipeline (step: handles literal_unroll)\n"Failed in literal_unroll_subpipeline mode pipeline (step: performs mixed container unroll)\\n\'args\'"'

```
</details>

user: anelsene
issue_5309: state: open
title: support for function calls with *args and named kwargs
body: Fixes #5304.

For python 3.6 this depends on #5292. For later versions this dependence does not exist.

Support for function calls with `*args` and named kwargs as in the following example:

```python
from numba import njit

@njit
def foo(*args, kwarg=None):
    print(args)
    print(kwarg)

@njit
def bar(a, *args):
    foo(a, *args, kwarg='foobar')

bar(1, 2, 3)
```


user: ARF1
issue_5306: state: open
title: uninitialized typed-list extending iterable that cannot be sliced
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
An unitialized typed-list cannot extend an iterable that cannot be sliced. 

Reproducible example:
```python
from numba.typed import List

def foo():
     l = List()
     l.extend("")
     return l

foo()
```
Error:
```
Traceback (most recent call last):
  File "test_iterable.py", line 8, in <module>
    foo()
  File "test_iterable.py", line 5, in foo
    l.extend("")
  File "/Users/rohitsanjay/numba/numba/typed/typedlist.py", line 323, in extend
    self._initialise_list(iterable[0])
IndexError: string index out of range
```
FIXME: https://github.com/numba/numba/blob/master/numba/typed/typedlist.py#L318-L326

This issue was encountered while working on test cases for #5295 

cc @esc @stuartarchibald 

user: rohitsanj
issue_5304: state: open
title: Function calls cannot combine tuple unpacking and keyword arguments
body: On the current master, it is not possible for function calls to use tuple unpacking and keyword arguments:

```python
from numba import njit

@njit
def foo(*args, kwarg=None):
    print(args)
    print(kwarg)

@njit
def bar(a, *args):
    foo(a, *args, kwarg='foobar')

bar(1, 2, 3)
```

Output:
```
UnsupportedError: Failed in nopython mode pipeline (step: analyzing bytecode)
CALL_FUNCTION_EX with **kwargs not supported
```

To me this looks like a bug since `**kwargs` is not used anywhere. Clearly `**kwargs` would be a problem with its undefined length at compile time, but here the number of arguments is defined at compile time.

Note: Manually unpacking the tuple with `foo(a, args[0], args[1], kwarg='foobar')` works.
user: ARF1
issue_5302: state: open
title: datetime instances cannot be cast to type datetime
body: On the current master, casting datetime (and probably timedelta) instances to their own type fails while it works for all other dtypes.

```python
import numpy as np
from numba import njit
from numba.np.numpy_support import from_dtype


a = np.datetime64('2000-01-01')
dtype = from_dtype(a.dtype)


@njit
def testnumba(x):
    return dtype(x)


testnumba(a)
```

Output:
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of typeref[datetime64[D]] with parameters (datetime64[D])
No type info available for typeref[datetime64[D]] as a callable.
[1] During: resolving callee type: typeref[datetime64[D]]
[2] During: typing of call at <ipython-input-1-6ddd7a4a79f8> (12)


File "<ipython-input-1-6ddd7a4a79f8>", line 12:
def testnumba(x):
    return dtype(x)
    ^
```
user: ARF1
issue_5300: state: open
title: Partial tuple unpacking fails to compile
body: On the current master partially unpacking a tuple fails:

```python
from numba import njit

@njit
def testnumba():
    a = range(10)
    b = range(10)
    c = range(10)
    for a_el, *some_tuple in zip(a, b, c):
        print(a_el)
        print(some_tuple)

testnumba()
```

Output:
```
UnsupportedError: Failed in nopython mode pipeline (step: analyzing bytecode)
Use of unsupported opcode (UNPACK_EX) found

File "<ipython-input-1-67341a503362>", line 8:
def testnumba():
    <source elided>
    c = range(10)
    for a_el, *some_tuple in zip(a, b, c):
    ^
```
user: ARF1
issue_5291: state: open
title: Compilation failure when overload contains *args and multiple keyword arguments
body: On the current master, compilation fails when an overloaded function contains `*args` and multiple keyword arguments.

Note: In the example below, if one deletes `bar`, compilation succeeds.

```python
from numba import njit
from numba.extending import overload

def foo(*args, **kwargs):
    # stub for overload
    pass


@overload(foo)
def foo_ovl(*args, bar1=None, bar2=None):
    def foo_impl(*args, bar1=None, bar2=None):
        return args

    return foo_impl


@njit
def test(a, b):
    return foo(a, b)


test(1, 2)
```

Output:
```
Traceback (most recent call last):
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.63990\pythonFiles\ptvsd_launcher.py", line 48, in <module>
    main(ptvsdArgs)
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.63990\pythonFiles\lib\python\old_ptvsd\ptvsd\__main__.py", line 432, in main
    run()
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.63990\pythonFiles\lib\python\old_ptvsd\ptvsd\__main__.py", line 316, in run_file
    runpy.run_path(target, run_name='__main__')
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 263, in run_path
    return _run_module_code(code, init_globals, run_name,
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 96, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "c:\Users\My User\Documents\numba\Untitled-2.py", line 22, in <module>
    test(1, 2)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "c:\Users\My User\Documents\numba\numba\core\utils.py", line 77, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
?[1m?[1m?[1mInvalid use of Function(<function foo at 0x0000027BE7E333A0>) with argument(s) of type(s): (int64, int64)
 * parameterized
?[1mIn definition 0:?[0m
?[1m    IndexError: tuple index out of range?[0m
    raised from c:\Users\My User\Documents\numba\numba\core\typing\templates.py:169
?[1mIn definition 1:?[0m
?[1m    IndexError: tuple index out of range?[0m
    raised from c:\Users\My User\Documents\numba\numba\core\typing\templates.py:169
?[1mThis error is usually caused by passing an argument of a type that is unsupported by the named function.?[0m?[0m
?[0m?[1m[1] During: resolving callee type: Function(<function foo at 0x0000027BE7E333A0>)?[0m
?[0m?[1m[2] During: typing of call at c:\Users\My User\Documents\numba\Untitled-2.py (19)
?[0m
?[1m
File "Untitled-2.py", line 19:?[0m
?[1mdef test(a, b):
?[1m    return foo(a, b)
?[0m    ?[1m^?[0m?[0m
```
user: ARF1
issue_5285: state: open
title: Return Numba types from @njit functions
body: In https://github.com/numba/numba/pull/5235 the following issue was encountered. It seems like Numba types are boxed (or casted)  into NumPy dtypes when returned from an `@njit` decorated function. I was wondering if this is intended behavior?

Reproducer:

``` python
from numba import njit, int32

@njit
def foo():
    return int32

print(type(foo()))
print(type(foo.py_func()))
```

Prints:

```
<class 'numpy.dtype'>
<class 'numba.core.types.scalars.Integer'>
```
user: esc
issue_5275: state: open
title: Threading backend using `omp_set_nested` which is deprecated in OpenMP 5?
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).
This
```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def foo(n):
    acc = 0
    for i in prange(n):
        acc += i
    return acc

print(foo(10))
```
run like:
```
NUMBA_THREADING_LAYER=omp python example.py
```
does this:
```
OMP: Info #273: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
```

Think this is because OpenMP 5.0 deprecated `omp_set_nested` and Anaconda MKL 2020 packages depends on in Intel-OpenMP which is 5.0 compliant.

user: stuartarchibald
issue_5274: state: open
title: Attempting to iterate NoneType instance leads to infinite loop
body: On the current master any attempt to iterate a NoneType-instance leads to an infinite loop. They are really painful to debug... :-)

To follow python convention, it should throw `TypeError: 'NoneType' object is not iterable`.

```python
from numba.core import types

none = types.NoneType('none')

for el in none:
    print('test')
```
user: ARF1
labels: good second issue: A good issue for second time contributors
issue_5269: state: open
title: Unable to pickle `DeviceNDArray`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

<hr>

When trying to pickle a `DeviceNDArray`, am running into the following exception.

```python
In [1]: import pickle                                                           

In [2]: import numpy                                                            

In [3]: import numba.cuda                                                       

In [4]: a = numpy.arange(5)                                                     

In [5]: a2 = numba.cuda.to_device(a)                                            

In [6]: pickle.dumps(a2)                                                        
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-6-15f276dab5b1> in <module>
----> 1 pickle.dumps(a2)

ValueError: ctypes objects containing pointers cannot be pickled
```
user: jakirkham
issue_5267: state: open
title: byte code analysis problem with while(True) (but legal?!)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This, from here https://stackoverflow.com/questions/60260414
```python
from numba import njit
import numpy as np

@njit
def num_steps(b, steps):
    e = b
    d = 0
    while True:
        if e == 1:
            d += steps[e]
            return d
        if e % 2 == 0:
            e //= 2
        else:
            e = 3*e + 1
        d += 1

steps = np.array([0, 0, 0, 0])
print(num_steps.py_func(3, steps))
print(num_steps(3, steps))
```
does this:
```
7
0
```
which is evidently incorrect. OP suggests removing `d += steps[e]` triggers correctness. CC @sklam. Reproduces for me on py3.7 + 0.49.0dev0+<>.
user: stuartarchibald
labels: bug - typing: Bugs: occuring at typing time
issue_5263: state: open
title: parfors argmin on boolean array fails
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This:
```python
import numpy as np
import numba


@numba.njit(parallel=True)
def test(array):
    for i in numba.prange(array.shape[0]):
        np.argmin(array[i])


test(np.array([[1, 0], [0, 0]], dtype=np.bool_))
```
does this:
```
Failed in nopython mode pipeline (step: nopython mode backend)
'Boolean' object has no attribute 'bitwidth'
```
patch to start fixing https://gitter.im/numba/numba?at=5e4a655b0c50da598c164cf1

suspect `argmax` will also fail the same way.

CC: @sleighsoft (reporter)

user: stuartarchibald
labels: good second issue: A good issue for second time contributors
issue_5259: state: open
title: Raising an error casts result to OptionalType
body: On the current master, raising an error in the function body casts the result of the function to `OptionalType`:

```python
import numpy as np
from numba import njit


closure_var = True # this would not be static in the real world...


@njit
def barbar_works(a):
    return 1.0


@njit
def barbar_does_not_work(a):
    if closure_var is True:
        raise ValueError('error message')
    return 1.0


@njit
def foo(a):
    if a.size == 0:
        result = barbar_works(a)
    else:
        result = 0.0
    return np.isfinite(result)


foo(np.arange(10)/10)


@njit
def foo(a):
    if a.size == 0:
        result = barbar_does_not_work(a)
    else:
        result = 0.0
    return np.isfinite(result)


foo(np.arange(10)/10)
```

Output:
```
(llvmlite-dev) c:\Users\My User\Documents\numba>cd "c:\Users\My User\Documents\numba" && cmd /C "set "PYTHONPATH=C:/Users/My User/Documents/Finance/python/libraries/numba;" && set "PYTHONIOENCODING=UTF-8" && set "PYTHONUNBUFFERED=1" && Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\python.exe "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.63072\pythonFiles\ptvsd_launcher.py" --default --nodebug --client --host localhost --port 61302 "c:\Users\My User\Documents\numba\test_optional.py" "
Traceback (most recent call last):
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.63072\pythonFiles\ptvsd_launcher.py", line 48, in <module>
    main(ptvsdArgs)
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.63072\pythonFiles\lib\python\old_ptvsd\ptvsd\__main__.py", line 432, in main
    run()
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.63072\pythonFiles\lib\python\old_ptvsd\ptvsd\__main__.py", line 316, in run_file
    runpy.run_path(target, run_name='__main__')
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 263, in run_path
    return _run_module_code(code, init_globals, run_name,
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 96, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "c:\Users\My User\Documents\numba\test_optional.py", line 41, in <module>
    foo(np.arange(10)/10)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "c:\Users\My User\Documents\numba\numba\core\utils.py", line 77, in reraise
    raise value.with_traceback(tb)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
?[1m?[1m?[1mInvalid use of Function(<ufunc 'isfinite'>) with argument(s) of type(s): (OptionalType(float64) i.e. the type 'float64 or None')
 * parameterized
?[1mIn definition 0:?[0m
?[1m    TypingError: ?[1mcan't resolve ufunc isfinite for types (OptionalType(float64),)?[0m?[0m
    raised from c:\Users\My User\Documents\numba\numba\core\typing\npydecl.py:106
?[1mIn definition 1:?[0m
?[1m    TypingError: ?[1mcan't resolve ufunc isfinite for types (OptionalType(float64),)?[0m?[0m
    raised from c:\Users\My User\Documents\numba\numba\core\typing\npydecl.py:106
?[1mThis error is usually caused by passing an argument of a type that is unsupported by the named function.?[0m?[0m
?[0m?[1m[1] During: resolving callee type: Function(<ufunc 'isfinite'>)?[0m
?[0m?[1m[2] During: typing of call at c:\Users\My User\Documents\numba\test_optional.py (38)
?[0m
?[1m
File "test_optional.py", line 38:?[0m
?[1mdef foo(a):
    <source elided>
        result = 0.0
?[1m    return np.isfinite(result)
?[0m    ?[1m^?[0m?[0m
```

Note that manually inlining works:
```python
import numpy as np
from numba import njit


closure_var = True # this would not be static in the real world...


@njit
def foo(a):
    if a.size == 0:
        if closure_var is True:
            raise ValueError('error message')
        result = 1.0
    else:
        result = 0.0
    return np.isfinite(result)


foo(np.arange(10)/10)
```
user: ARF1
issue_5258: state: open
title: OptionalType pruning after test for None
body: On the current master there does not seem to be any way to "unpack" a type once it is wrapped in `OptionalType(...)`.

In the example below, after the test `b is None` followed by a return (or alternatively raised error) `b` should no longer be `OptionalType(int64)` but just `int64` since at this point `b` can in fact no longer be `None`.

This is an issue when one wants to use the result of such a function as input to functions that do not accept optional types as input. (Example: some (all?) current ufunc implementations.)

```python
from numba import njit

@njit
def test_foo(a):
    # let's generate an OptionalType for this demo
    b = 1 if a == 1 else None

    if b is None:
        return 1
    else:
        # b can never be None here and should no longer be of OptionalType
        c = b
        return c

test_foo(1)

test_foo.inspect_types()
```

Output:

```

from numba import njit...
test_foo (int64,)
--------------------------------------------------------------------------------
# File: <ipython-input-6-ef715cbf4eec>
# --- LINE 3 --- 

@njit

# --- LINE 4 --- 

def test_foo(a):

    # --- LINE 5 --- 
    # label 0
    #   a = arg(0, name=a)  :: int64
    #   $const4.1 = const(int, 1)  :: Literal[int](1)
    #   $6compare_op.2 = a == $const4.1  :: bool
    #   del a
    #   del $const4.1
    #   branch $6compare_op.2, 10, 14
    # label 10
    #   del $6compare_op.2
    #   $const10.0 = const(int, 1)  :: Literal[int](1)
    #   $phi16.0 = $const10.0  :: OptionalType(int64) i.e. the type 'int64 or None'
    #   del $const10.0
    #   jump 16
    # label 14
    #   del $6compare_op.2
    #   $const14.0 = const(NoneType, None)  :: none
    #   $phi16.0 = $const14.0  :: OptionalType(int64) i.e. the type 'int64 or None'
    #   del $const14.0
    #   jump 16
    # label 16
    #   b = $phi16.0  :: OptionalType(int64) i.e. the type 'int64 or None'
    #   del $phi16.0

    b = 1 if a == 1 else None

# --- LINE 6 --- 



    # --- LINE 7 --- 
    #   $const20.2 = const(NoneType, None)  :: none
    #   $22compare_op.3 = b is $const20.2  :: bool
    #   del $const20.2
    #   branch $22compare_op.3, 26, 30

    if b is None:

        # --- LINE 8 --- 
        # label 26
        #   del b
        #   del $22compare_op.3
        #   $const26.0 = const(int, 1)  :: Literal[int](1)
        #   $28return_value.1 = cast(value=$const26.0)  :: Literal[int](1)
        #   del $const26.0
        #   return $28return_value.1

        return 1

    # --- LINE 9 --- 

    else:

        # --- LINE 10 --- 
        # label 30
        #   del $22compare_op.3
        #   c = b  :: OptionalType(int64) i.e. the type 'int64 or None'
        #   del b

        c = b

        # --- LINE 11 --- 
        #   $36return_value.2 = cast(value=c)  :: OptionalType(int64) i.e. the type 'int64 or None'
        #   del c
        #   return $36return_value.2

        return c


================================================================================
```
user: ARF1
issue_5255: state: open
title: dtype('<type_as_str>') == 'type_as_str' incorrectly evaluates to False when compiled.
body: ```
import numpy as np
import pandas as pd
from numba import jit

@jit(nopython=True)
def COUNT(x,n,d):
	'''
	the number of sample when condition satistied in past d trade dates
	x: logic vector 
	d: the trade dates 
	'''

	x_ = np.lib.stride_tricks.as_strided(x,shape=(n-d+1,d),strides=(x.strides[0],x.strides[0]))
	x_count = x_.sum(1)

	return x_count


@jit(nopython=True)
def COUNT_mat(conditionMat,d):
	'''
	the number of sample when condition satistied in past d trade dates
	conditionMat: logic matrix
	d: the trade dates 
	'''

	rowNum = conditionMat.shape[0]
	colNum = conditionMat.shape[1]

	if conditionMat.dtype != 'bool':
		return np.full(fill_value=np.nan,shape=(rowNum,colNum),dtype=np.float32)

	retMat = np.zeros((rowNum-d+1,colNum),dtype=np.float32)
	
	for i in np.arange(colNum):
		retMat[:,i] = COUNT(conditionMat[:,i],rowNum,d)

	return retMat
```

```
m1 = np.random.randint(100,size=(300,3000))
m2 = np.random.randint(100,size=(300,3000))
logicM1 = m1 > m2 

ans = COUNT_mat(logicM1,10)
```

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function ne>) with argument(s) of type(s): (dtype(bool), Literal[str](bool))
Known signatures:
 * (bool, bool) -> bool
 * (int8, int8) -> bool
 * (int16, int16) -> bool
 * (int32, int32) -> bool
 * (int64, int64) -> bool
 * (uint8, uint8) -> bool
 * (uint16, uint16) -> bool
 * (uint32, uint32) -> bool
 * (uint64, uint64) -> bool
 * (float32, float32) -> bool
 * (float64, float64) -> bool
 * (complex64, complex64) -> bool
 * (complex128, complex128) -> bool
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
In definition 10:
    All templates rejected with literals.
In definition 11:
    All templates rejected without literals.
In definition 12:
    All templates rejected with literals.
In definition 13:
    All templates rejected without literals.
In definition 14:
    All templates rejected with literals.
In definition 15:
    All templates rejected without literals.
In definition 16:
    All templates rejected with literals.
In definition 17:
    All templates rejected without literals.
In definition 18:
    All templates rejected with literals.
In definition 19:
    All templates rejected without literals.
In definition 20:
    All templates rejected with literals.
In definition 21:
    All templates rejected without literals.
In definition 22:
    All templates rejected with literals.
In definition 23:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of intrinsic-call at <ipython-input-3-1b307e803bb0> (26)

File "<ipython-input-3-1b307e803bb0>", line 26:
def COUNT_mat(conditionMat,d):
    <source elided>

	if conditionMat.dtype != 'bool':
 ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.
```
user: isaac-you
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_5254: state: open
title:  forceobj=True and loop with continiue
body: ## Reporting a bug

Even if the condition is never `True` (j == -1), if only I have `continue` inside the if-statement and the flag is `forceobj=True` numba runs the loop only once. This did not happen in Numba 0.45.0 and it appeared when I updated Numba to 0.48.0. With `break` it work properly.

Code to reproduce the error:
```python
import numba


@numba.jit(forceobj=True)
def bug():
    cnt = 0
    for j in range(5):
        if j == -1:
            continue
        cnt += 1
    print(cnt)


if __name__ == '__main__':
    bug.py_func()
    bug()
```

Output:
```
5
1
```

Also for statement below I have the same output:
```python
        if not j == -1:
            cnt += 1
```

user: piotrbartman
issue_5251: state: open
title: Potential bug, found in test_caching_mutliple_files_with_signature
body: I get several test failures in numba master on 64-bit Linux.

```
======================================================================
ERROR: test_init_entrypoint (numba.tests.test_entrypoints.TestEntrypoints)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_entrypoints.py", line 35, in test_init_entrypoint
    entrypoints = pkg_resources.get_entry_map(dist)
  File "/home/aaronmeurer/anaconda3/envs/numba-dev/lib/python3.7/site-packages/pkg_resources/__init__.py", line 495, in get_entry_map
    return get_distribution(dist).get_entry_map(group)
  File "/home/aaronmeurer/anaconda3/envs/numba-dev/lib/python3.7/site-packages/pkg_resources/__init__.py", line 482, in get_distribution
    dist = get_provider(dist)
  File "/home/aaronmeurer/anaconda3/envs/numba-dev/lib/python3.7/site-packages/pkg_resources/__init__.py", line 358, in get_provider
    return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
  File "/home/aaronmeurer/anaconda3/envs/numba-dev/lib/python3.7/site-packages/pkg_resources/__init__.py", line 901, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/home/aaronmeurer/anaconda3/envs/numba-dev/lib/python3.7/site-packages/pkg_resources/__init__.py", line 787, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'numba' distribution was not found and is required by the application

======================================================================
ERROR: test_isinf_M_? (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 149, in propagate
    constraint(typeinfer)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 486, in __call__
    self.resolve(typeinfer, typevars, fnty)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 506, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 1440, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 214, in resolve_function_type
    raise last_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 197, in resolve_function_type
    res = self._resolve_user_function_type(func, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 249, in _resolve_user_function_type
    return func.get_call_type(self, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 148, in get_call_type
    failures.raise_error()
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 77, in raise_error
    raise errors.TypingError(self.format())
numba.core.errors.TypingError: Invalid use of Function(<ufunc 'isinf'>) with argument(s) of type(s): (array(datetime64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isinf' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isinf' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isinf'>)
[2] During: typing of call at <string> (2)


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1448, in _check_ufunc_with_dtypes
    cr = compile_isolated(fn, arg_nbty, flags=self._compile_flags)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 180, in compile_isolated
    flags, locals)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 548, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 328, in compile_extra
    return self._compile_bytecode()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 390, in _compile_bytecode
    return self._compile_core()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 370, in _compile_core
    raise e
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 361, in _compile_core
    pm.run(self.state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 335, in run
    raise patched_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 326, in run
    self._runPass(idx, pass_inst, state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 290, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 263, in check
    mangled = func(compiler_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 95, in run_pass
    raise_errors=self._raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 67, in type_inference_stage
    infer.propagate(raise_errors=raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 985, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<ufunc 'isinf'>) with argument(s) of type(s): (array(datetime64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isinf' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isinf' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isinf'>)
[2] During: typing of call at <string> (2)


File "<string>", line 2:
<source missing, REPL/exec in use?>


======================================================================
ERROR: test_isinf_m_? (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 149, in propagate
    constraint(typeinfer)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 486, in __call__
    self.resolve(typeinfer, typevars, fnty)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 506, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 1440, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 214, in resolve_function_type
    raise last_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 197, in resolve_function_type
    res = self._resolve_user_function_type(func, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 249, in _resolve_user_function_type
    return func.get_call_type(self, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 148, in get_call_type
    failures.raise_error()
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 77, in raise_error
    raise errors.TypingError(self.format())
numba.core.errors.TypingError: Invalid use of Function(<ufunc 'isinf'>) with argument(s) of type(s): (array(timedelta64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isinf' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isinf' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isinf'>)
[2] During: typing of call at <string> (2)


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1448, in _check_ufunc_with_dtypes
    cr = compile_isolated(fn, arg_nbty, flags=self._compile_flags)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 180, in compile_isolated
    flags, locals)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 548, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 328, in compile_extra
    return self._compile_bytecode()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 390, in _compile_bytecode
    return self._compile_core()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 370, in _compile_core
    raise e
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 361, in _compile_core
    pm.run(self.state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 335, in run
    raise patched_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 326, in run
    self._runPass(idx, pass_inst, state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 290, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 263, in check
    mangled = func(compiler_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 95, in run_pass
    raise_errors=self._raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 67, in type_inference_stage
    infer.propagate(raise_errors=raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 985, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<ufunc 'isinf'>) with argument(s) of type(s): (array(timedelta64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isinf' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isinf' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isinf'>)
[2] During: typing of call at <string> (2)


File "<string>", line 2:
<source missing, REPL/exec in use?>


======================================================================
ERROR: test_isnan_m_? (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 149, in propagate
    constraint(typeinfer)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 486, in __call__
    self.resolve(typeinfer, typevars, fnty)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 506, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 1440, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 214, in resolve_function_type
    raise last_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 197, in resolve_function_type
    res = self._resolve_user_function_type(func, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 249, in _resolve_user_function_type
    return func.get_call_type(self, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 148, in get_call_type
    failures.raise_error()
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 77, in raise_error
    raise errors.TypingError(self.format())
numba.core.errors.TypingError: Invalid use of Function(<ufunc 'isnan'>) with argument(s) of type(s): (array(timedelta64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isnan' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isnan' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isnan'>)
[2] During: typing of call at <string> (2)


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1448, in _check_ufunc_with_dtypes
    cr = compile_isolated(fn, arg_nbty, flags=self._compile_flags)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 180, in compile_isolated
    flags, locals)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 548, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 328, in compile_extra
    return self._compile_bytecode()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 390, in _compile_bytecode
    return self._compile_core()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 370, in _compile_core
    raise e
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 361, in _compile_core
    pm.run(self.state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 335, in run
    raise patched_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 326, in run
    self._runPass(idx, pass_inst, state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 290, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 263, in check
    mangled = func(compiler_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 95, in run_pass
    raise_errors=self._raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 67, in type_inference_stage
    infer.propagate(raise_errors=raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 985, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<ufunc 'isnan'>) with argument(s) of type(s): (array(timedelta64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isnan' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isnan' using the loop 'm->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isnan'>)
[2] During: typing of call at <string> (2)


File "<string>", line 2:
<source missing, REPL/exec in use?>


======================================================================
ERROR: test_isnan_M_? (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 149, in propagate
    constraint(typeinfer)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 486, in __call__
    self.resolve(typeinfer, typevars, fnty)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 506, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 1440, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 214, in resolve_function_type
    raise last_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 197, in resolve_function_type
    res = self._resolve_user_function_type(func, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/typing/context.py", line 249, in _resolve_user_function_type
    return func.get_call_type(self, args, kws)
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 148, in get_call_type
    failures.raise_error()
  File "/home/aaronmeurer/Documents/numba/numba/core/types/functions.py", line 77, in raise_error
    raise errors.TypingError(self.format())
numba.core.errors.TypingError: Invalid use of Function(<ufunc 'isnan'>) with argument(s) of type(s): (array(datetime64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isnan' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isnan' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isnan'>)
[2] During: typing of call at <string> (2)


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1448, in _check_ufunc_with_dtypes
    cr = compile_isolated(fn, arg_nbty, flags=self._compile_flags)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 180, in compile_isolated
    flags, locals)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 548, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 328, in compile_extra
    return self._compile_bytecode()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 390, in _compile_bytecode
    return self._compile_core()
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 370, in _compile_core
    raise e
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler.py", line 361, in _compile_core
    pm.run(self.state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 335, in run
    raise patched_exception
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 326, in run
    self._runPass(idx, pass_inst, state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 290, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/compiler_machinery.py", line 263, in check
    mangled = func(compiler_state)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 95, in run_pass
    raise_errors=self._raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typed_passes.py", line 67, in type_inference_stage
    infer.propagate(raise_errors=raise_errors)
  File "/home/aaronmeurer/Documents/numba/numba/core/typeinfer.py", line 985, in propagate
    raise errors[0]
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<ufunc 'isnan'>) with argument(s) of type(s): (array(datetime64[], 1d, C), array(bool, 1d, C))
 * parameterized
In definition 0:
    TypingError: ufunc 'isnan' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
In definition 1:
    TypingError: ufunc 'isnan' using the loop 'M->?' not supported in this mode
    raised from /home/aaronmeurer/Documents/numba/numba/core/typing/npydecl.py:111
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<ufunc 'isnan'>)
[2] During: typing of call at <string> (2)


File "<string>", line 2:
<source missing, REPL/exec in use?>


======================================================================
FAIL: test_argmin_npdatetime (numba.tests.test_array_reductions.TestArrayReductions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 689, in test_argmin_npdatetime
    self.check_npdatetime(array_argmin)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 674, in check_npdatetime
    self._do_check_nptimedelta(pyfunc, arr)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 667, in _do_check_nptimedelta
    self.assertPreciseEqual(cfunc(arr), pyfunc(arr))
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing 6 and 5: 6 != 5

======================================================================
FAIL: test_argmax_npdatetime (numba.tests.test_array_reductions.TestArrayReductions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 693, in test_argmax_npdatetime
    self.check_npdatetime(array_argmax)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 674, in check_npdatetime
    self._do_check_nptimedelta(pyfunc, arr)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 667, in _do_check_nptimedelta
    self.assertPreciseEqual(cfunc(arr), pyfunc(arr))
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing 3 and 5: 3 != 5

======================================================================
FAIL: test_max_npdatetime (numba.tests.test_array_reductions.TestArrayReductions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 685, in test_max_npdatetime
    self.check_npdatetime(array_max)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 674, in check_npdatetime
    self._do_check_nptimedelta(pyfunc, arr)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 667, in _do_check_nptimedelta
    self.assertPreciseEqual(cfunc(arr), pyfunc(arr))
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing 1979 and NaT: numpy.datetime64('1979') != numpy.datetime64('NaT')

======================================================================
FAIL: test_min_npdatetime (numba.tests.test_array_reductions.TestArrayReductions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 681, in test_min_npdatetime
    self.check_npdatetime(array_min)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 674, in check_npdatetime
    self._do_check_nptimedelta(pyfunc, arr)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_reductions.py", line 667, in _do_check_nptimedelta
    self.assertPreciseEqual(cfunc(arr), pyfunc(arr))
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing 1970 and NaT: numpy.datetime64('1970') != numpy.datetime64('NaT')

======================================================================
FAIL: test_argwhere_array_like (numba.tests.test_array_manipulation.TestArrayManipulation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_array_manipulation.py", line 860, in test_argwhere_array_like
    self.assertPreciseEqual(expected, got)
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing [] and [[0]]: Tuples differ: (1, 0) != (1, 1)

First differing element 1:
0
1

- (1, 0)
?     ^

+ (1, 1)
?     ^
 : different shapes

======================================================================
FAIL: test_argwhere_array_like (numba.tests.test_array_manipulation.TestArrayManipulation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 697, in tearDown
    self.memory_leak_teardown()
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 671, in memory_leak_teardown
    self.assert_no_memory_leak()
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 680, in assert_no_memory_leak
    self.assertEqual(total_alloc, total_free)
AssertionError: 21 != 20

======================================================================
FAIL: test_orphaned_semaphore (numba.tests.test_parallel_backend.TestInitSafetyIssues)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_parallel_backend.py", line 821, in test_orphaned_semaphore
    out, err = run_cmd(cmdline)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_parallel_backend.py", line 812, in run_cmd
    (popen.returncode, err.decode()))
AssertionError: process failed with code 1: stderr follows
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/orphaned_semaphore_usecase.py", line 8, in <module>
    import numba # noqa, deliberately unused, here to test import is safe
ModuleNotFoundError: No module named 'numba'



======================================================================
FAIL: test_minimum_MM_M (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1472, in _check_ufunc_with_dtypes
    ulps=ulps)
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing [       'NaT' '1970-01-01'        'NaT' '1970-01-01' '1970-01-02'
 '1970-01-02'        'NaT' '1970-01-01'] and ['1970-01-02' '1970-01-01'        'NaT' '1970-01-01' '1970-01-02'
 '1970-01-02' '1970-01-02' '1970-01-01']: True != False

======================================================================
FAIL: test_maximum_mm_m (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1472, in _check_ufunc_with_dtypes
    ulps=ulps)
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing [    2 'NaT'     2 'NaT' 'NaT' 'NaT'     2     0] and [ 2  0  2  0 -3 -3  2  0]: True != False

======================================================================
FAIL: test_maximum_MM_M (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1472, in _check_ufunc_with_dtypes
    ulps=ulps)
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing [       'NaT' '1970-01-26'        'NaT' '1970-01-26' '1970-01-26'
 '1970-01-26'        'NaT' '1970-01-01'] and ['1970-01-02' '1970-01-26'        'NaT' '1970-01-26' '1970-01-26'
 '1970-01-26' '1970-01-02' '1970-01-01']: True != False

======================================================================
FAIL: test_minimum_mm_m (numba.tests.test_ufuncs.TestLoopTypesDatetimeNoPython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1486, in test_template
    self._check_loop(fn, ufunc, loop)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1443, in _check_loop
    self._check_ufunc_with_dtypes(fn, ufunc, letter_types)
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_ufuncs.py", line 1472, in _check_ufunc_with_dtypes
    ulps=ulps)
  File "/home/aaronmeurer/Documents/numba/numba/tests/support.py", line 311, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, failure_msg))
AssertionError: when comparing [   -3 'NaT'     2 'NaT' 'NaT' 'NaT'    -3     0] and [-3  0  2  0 -3 -3 -3  0]: True != False

======================================================================
FAIL: test_caching_mutliple_files_with_signature (numba.tests.test_dispatcher.TestCacheMultipleFilesWithSignature)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aaronmeurer/Documents/numba/numba/tests/test_dispatcher.py", line 1723, in test_caching_mutliple_files_with_signature
    self.assertEqual(popen.returncode, 0)
AssertionError: 1 != 0

----------------------------------------------------------------------
Ran 9123 tests in 815.493s

FAILED (failures=12, errors=5, skipped=123, expected failures=11)
```

Here is my GPU info

```
$nvidia-smi
Thu Feb 13 16:07:36 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 435.21       Driver Version: 435.21       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce RTX 2080    Off  | 00000000:01:00.0  On |                  N/A |
|  0%   40C    P8    13W / 215W |    891MiB /  7979MiB |      3%      Default |
+-------------------------------+----------------------+----------------------+
```

The only one of these I've looked into is the `orphaned_semaphores` one. I suspect that is caused by me using `python setup.py build_ext --inplace` rather tha installing numba (see https://github.com/numba/numba/pull/4615#issuecomment-585966470). 
user: asmeurer
labels: caching: Issue involving caching
issue_5246: state: open
title: Bitwidth of datatypes should be an immutable property or name should change on assignment
body: On the current master:

```python
In [1]: from numba.core import types

In [2]: int16 = types.Integer.from_bitwidth(16)

In [3]: int16.bitwidth = 32

In [4]: int16.name
Out[4]: 'int16'

In [5]: int16.bitwidth
Out[5]: 32
```

The problem is, that `name` includes the bitwidth as it was at creation. If the bitwidth is assigned later it is not updated.
user: ARF1
labels: good second issue: A good issue for second time contributors
issue_5245: state: open
title: Unable to create record array
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I'm trying to use numba to run a function that updates a numpy array of records.

Here's a snippet from a complete running example at https://repl.it/@TomGoBravo/numba-create-record
```
rec_dtype = np.dtype([('a', 'int32'), ('b', 'float64')])
rec = from_dtype(rec_dtype)

# With njit commented out this code runs without error.
# With njit enabled np.array fails to compile and raises
# Cannot cast int32 to Record(a[type=int32;offset=0],b[type=float64;offset=4];12;False): %".88"
@njit # (rec[:](numba.int32, numba.float64))
def make_record(a_val, b_val):
  return np.array((a_val, b_val), dtype=rec_dtype)
```

From https://gitter.im/numba/numba?at=5e4517b2cd2d737bb0758426
> the lowering fail is because the array ctor code expects each tuple element to correspond to the dtype of the array, so it's trying to shove an int32 into a slot of the dtype type.

user: TomGoBravo
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_5242: state: open
title: literally() fails when used in implementations with default arguments and overload_method 
body: `literally()` fails when used in implementations with default arguments and `overload_method` on current master.

Note: The same impementation works with `overload`.

Reproducer:

```python
import numpy as np

from numba import literally, njit
from numba.core import types
from numba.extending import overload, overload_method


def foo(a, b=0):
    "stub for overload"


@overload(foo)
@overload_method(types.Array, 'foo')
def foo_ovl(a, b=0):
    b_is_default = b == 0

    if b_is_default is True:
        def foo_impl(a, b=0):
            return 0
    else:
        def foo_impl(a, b=0):
            return literally(b)
                
    return foo_impl


@njit
def works(arr):
    return foo(arr)

@njit
def does_not_work(arr):
    return arr.foo()

works(np.arange(3))
does_not_work(np.arange(3))
```

Output:
```

(llvmlite-dev) c:\Users\My User\Documents\numba>cd "c:\Users\My User\Documents\numba" && cmd /C "set "PYTHONIOENCODING=UTF-8" && set "PYTHONUNBUFFERED=1" && Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\python.exe "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.62710\pythonFiles\ptvsd_launcher.py" --default --nodebug --client --host localhost --port 51462 "c:\Users\My User\Documents\numba\literal_bug.py" "
Traceback (most recent call last):
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 770, in compile
    cres = self._compiler.compile(args, return_type)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 104, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 548, in compile_extra
    return pipeline.compile_extra(func)
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 328, in compile_extra
    return self._compile_bytecode()
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 390, in _compile_bytecode
    return self._compile_core()
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 370, in _compile_core
    raise e
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 361, in _compile_core
    pm.run(self.state)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 335, in run
    raise patched_exception
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 326, in run
    self._runPass(idx, pass_inst, state)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 290, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 263, in check
    mangled = func(compiler_state)
  File "c:\Users\My User\Documents\numba\numba\core\untyped_passes.py", line 411, in run_pass
    find_literally_calls(state.func_ir, state.args)
  File "c:\Users\My User\Documents\numba\numba\core\analysis.py", line 564, in find_literally_calls
    raise errors.ForceLiteralArg(marked_args, loc=loc)
numba.core.errors.ForceLiteralArg: Failed in nopython mode pipeline (step: find literally calls)
?[1mPseudo-exception to force literal arguments in the dispatcher
?[1m
File "literal_bug.py", line 22:?[0m
?[1m        def foo_impl(a, b=0):
?[1m            return literally(b)
?[0m            ?[1m^?[0m?[0m
?[0m

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 770, in compile
    cres = self._compiler.compile(args, return_type)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 104, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 548, in compile_extra
    return pipeline.compile_extra(func)
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 328, in compile_extra
    return self._compile_bytecode()
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 390, in _compile_bytecode
    return self._compile_core()
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 370, in _compile_core
    raise e
  File "c:\Users\My User\Documents\numba\numba\core\compiler.py", line 361, in _compile_core
    pm.run(self.state)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 335, in run
    raise patched_exception
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 326, in run
    self._runPass(idx, pass_inst, state)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 290, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "c:\Users\My User\Documents\numba\numba\core\compiler_machinery.py", line 263, in check
    mangled = func(compiler_state)
  File "c:\Users\My User\Documents\numba\numba\core\typed_passes.py", line 407, in run_pass
    NativeLowering().run_pass(state)
  File "c:\Users\My User\Documents\numba\numba\core\typed_passes.py", line 349, in run_pass
    lower.lower()
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 178, in lower
    self.lower_normal_function(self.fndesc)
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 231, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 256, in lower_function_body
    self.lower_block(block)
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 271, in lower_block
    self.lower_inst(inst)
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 343, in lower_inst
    val = self.lower_assign(ty, inst)
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 517, in lower_assign
    return self.lower_expr(ty, value)
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 982, in lower_expr
    res = self.lower_call(resty, expr)
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 774, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
  File "c:\Users\My User\Documents\numba\numba\core\lowering.py", line 953, in _lower_call_normal
    res = impl(self.builder, argvals, self.loc)
  File "c:\Users\My User\Documents\numba\numba\core\base.py", line 1148, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "c:\Users\My User\Documents\numba\numba\core\base.py", line 1178, in wrapper
    return fn(*args, **kwargs)
  File "c:\Users\My User\Documents\numba\numba\core\typing\templates.py", line 781, in method_impl
    sig = cls._get_signature(typing_context, fnty, sig.args, {})
  File "c:\Users\My User\Documents\numba\numba\core\typing\templates.py", line 753, in _get_signature
    sig = fnty.get_call_type(typingctx, args, kws)
  File "c:\Users\My User\Documents\numba\numba\core\types\functions.py", line 148, in get_call_type
    failures.raise_error()
  File "c:\Users\My User\Documents\numba\numba\core\types\functions.py", line 76, in raise_error
    raise e
  File "c:\Users\My User\Documents\numba\numba\core\types\functions.py", line 127, in get_call_type
    sig = temp.apply(args, kws)
  File "c:\Users\My User\Documents\numba\numba\core\typing\templates.py", line 246, in apply
    sig = generic(args, kws)
  File "c:\Users\My User\Documents\numba\numba\core\typing\templates.py", line 490, in generic
    sig = disp_type.get_call_type(self.context, new_args, kws)
  File "c:\Users\My User\Documents\numba\numba\core\types\functions.py", line 272, in get_call_type
    template, pysig, args, kws = self.dispatcher.get_call_template(args, kws)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 301, in get_call_template
    self.compile(tuple(args))
  File "c:\Users\My User\Documents\numba\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 774, in compile
    raise e.bind_fold_arguments(folded)
numba.core.errors.ForceLiteralArg: Failed in nopython mode pipeline (step: nopython mode backend)
?[1m?[1mPseudo-exception to force literal arguments in the dispatcher
?[1m
File "literal_bug.py", line 22:?[0m
?[1m        def foo_impl(a, b=0):
?[1m            return literally(b)
?[0m            ?[1m^?[0m?[0m
?[0m
?[0m?[1m[1] During: lowering "$6call_method.2 = call $4load_method.1(func=$4load_method.1, args=[], kws=(), vararg=None)" at c:\Users\My User\Documents\numba\literal_bug.py (33)?[0m

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "c:\Users\My User\Documents\numba\numba\core\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 774, in compile
    raise e.bind_fold_arguments(folded)
numba.core.errors.ForceLiteralArg: ?[1mPseudo-exception to force literal arguments in the dispatcher
?[1m
File "literal_bug.py", line 22:?[0m
?[1m        def foo_impl(a, b=0):
?[1m            return literally(b)
?[0m            ?[1m^?[0m?[0m
?[0m

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.62710\pythonFiles\ptvsd_launcher.py", line 48, in <module>
    main(ptvsdArgs)
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.62710\pythonFiles\lib\python\old_ptvsd\ptvsd\__main__.py", line 432, in main
    run()
  File "c:\Users\My User\.vscode\extensions\ms-python.python-2020.2.62710\pythonFiles\lib\python\old_ptvsd\ptvsd\__main__.py", line 316, in run_file
    runpy.run_path(target, run_name='__main__')
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 263, in run_path
    return _run_module_code(code, init_globals, run_name,
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 96, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "Z:\Systemdateien\Miniconda3\envs\llvmlite-dev\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "c:\Users\My User\Documents\numba\literal_bug.py", line 36, in <module>
    does_not_work(np.arange(3))
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 360, in _compile_for_args
    already_lit_pos = [i for i in e.requested_args
  File "c:\Users\My User\Documents\numba\numba\core\dispatcher.py", line 361, in <listcomp>
    if isinstance(args[i], types.Literal)]
IndexError: tuple index out of range
```
user: ARF1
labels: bug - ice: Bugs: internal compiler error
issue_5236: state: open
title: Unboxer/boxer caching for speed
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

As noted here https://github.com/pygae/clifford/pull/229#issuecomment-584630861 unboxing (and boxing) impacts compile time performance. It is exacerbated by the {un,}boxers generating the same LLVM IR each time a type is encountered, irrespective of whether the type has been "seen" before and the resulting {un,}boxing LLVM IR code already existing. {un,}boxing code is particularly taxing for the LLVM optimisers because it often contains deeply nested if statements to deal with error handling.

Potential fixes:
1. Create functions containing the LLVM IR for {un,}boxers and cache these against type, then just call them if there's a match for the type in the cache.
2. As 1. but instead just cache the entry block to the {un,}boxer and emit a jump if there's a match for the type in the cache.

CC @eric-wieser @sklam 

user: stuartarchibald
labels: performance: performance related issue
issue_5230: state: open
title: Show bitwidth in string representation of IntegerLiteral
body: Changes the string representation of `IntegerLiteral` from `Literal[int](0)` to `Literal[int64](0)` where the `int64` is provided by the the underlying `literal_type`.

Clarifies error messages to the user as shown in #5204.
user: ARF1
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_5224: state: open
title: infix logical or/slicing bug
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

```python
from numba import njit
import numpy as np

@njit
def test1(a):
        index = a > 0
        index[:-1] |= index[1:]
        index[1:] |= index[:-1]
        return index

@njit
def test2(a):
        index = a > 0
        index[:-1] = index[:-1] | index[1:]
        index[1:] = index[1:] | index[:-1]
        return index

a = np.array([0, 1, 0, 1, 2, 3, 1, 0, 0, 0])
print(test1.py_func(a))
print(test1(a))
print('-' * 80)
print(test2.py_func(a))
print(test2(a))
```
produces:
```
[ True  True  True  True  True  True  True  True False False]
[ True  True  True  True  True  True  True  True  True  True]
--------------------------------------------------------------------------------
[ True  True  True  True  True  True  True  True False False]
[ True  True  True  True  True  True  True  True False False]
```
indicates a problem with infix `logical or`, or may be something slicing related.
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_5221: state: open
title: literally fails for argument default values
body: On the current master, `literally(obj)` fails if `obj` was assigned the default value of an argument of a function:

```python
from numba import njit, literally
from numba.extending import overload

def foo(a, b=1):
    pass

@overload(foo)
def foo_ovl(a, b=1):
    def foo_impl(a, b=1):
        return literally(b)
    return foo_impl

@njit
def works(a):
    return foo(a, 1)

works(1)


@njit
def does_not_work(a):
    return foo(a)

does_not_work(1)
```

Output:
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Cannot request literal type.

File "", line 22:
def does_not_work(a):
    return foo(a)
    ^

[1] During: resolving callee type: Function()
[2] During: typing of call at  (22)


File "", line 22:
def does_not_work(a):
    return foo(a)
    ^
```

Defining the default argument itself explicitly as a literal (`b=types.literal(1)`) does not help either.

---

One can work around this, but it is quite ugly:
```python
DEFAULT_VALUE = 1

@overload(foo)
def foo_ovl(a, b=DEFAULT_VALUE):
    b_is_default = b == DEFAULT_VALUE

    def foo_impl(a, b=DEFAULT_VALUE):
        if b_is_default is False:
            return literally(b)
        else:
            return DEFAULT_VALUE
    return foo_impl
```
user: ARF1
labels: bug - incorrect behavior: Bugs: incorrect behavior
bug - typing: Bugs: occuring at typing time
issue_5218: state: open
title: Use __init__ type hints for jitclass spec?
body: I really like how jitclass is coming along! I think I've got something that could clean its usage up a little and might not have been considered.

Here's the current usage, with the `spec` argument:

```python
@numba.jitclass({"numbers": numba.int64[:]})
class NumbaArraySummer:
    def __init__(self, numbers):
        self.numbers = numbers
        
    def sum(self):
        return np.sum(self.numbers)
```

But I think another possibility, cleaner and with less typing, would be to use type hints as follows:

```python
@numba.jitclass
class NumbaArraySummerAnnotated:
    def __init__(self, numbers: numba.int64[:]):
        self.numbers = numbers
        
    def sum(self):
        return np.sum(self.numbers)
```

In fact, looking at the implementation of `jitclass`, I think I may be able to contribute this as a PR. Would this be of interest?
user: StanczakDominik
labels: discussion: An issue requiring discussion
issue_5206: state: open
title: Function of len() is invalid to dynamic share array
body: Hi~
I found the function of len() is invalid to dynamic share array. Here is my code snippet:
```python
@cuda.jit
def kern_fun()
    dynamic_share_array = cuda.shared.array(0, numba.float32)
    fill_value(dynamic_share_array)
    print(len(dynamic_share_array))

main():
    kern_fun[1, 10, 0, 100]()
```
the output of print is '0'. Any ideas?
user: mantouRobot
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_5202: state: open
title: numpy.lib.recfunctions not recognized by numba
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Hello,

I am trying to use numba for fast joining two arrays of type unaligned array(Record(a[type=int64;offset=0],b[type=int64;offset=8],c[type=float64;offset=16];24;False), 1d, C).

I would use pandas but one of the arrays has 30 million records and the other 200 records.

Can you please add numpy.lib.recfunctions and numpy.lib.recfunctions.join_by functionality to numba?

Thanks
user: f1nasf1
issue_5187: state: open
title: Add a separate type to indicate the undefined start and stop of the slice
body: Hi, I think it would be really cool if I could distinguish between unset and set slices.
Now with an unspecified slice, the start always has the value 0, and the stop is maximum int, 9223372036854775807. We can confuse this option with the option when we explicitly pass values, example slice(0, 9223372036854775807)
```python
idx = slice(None,None)

@jit
def test(s):
    print(s.start)
    print(s.stop)

test(idx)
```
Output:
> 0
> 9223372036854775807

It would be great to mark an unassigned slice (start and stop value) as a separate type. Or some other solution that allows to distinguish an unassigned slice.
I understand that this is not very useful for arrays, but when developing other types of data, a slice can be used to take an element by value, and not by position (for example, the loc for pandas series)
Thanks
user: 1e-to
issue_5181: state: open
title: np.sum(..., axis=...): remove 0 <= axis <= 3 constraint
body: Depends on and closes #5177 
- depends on and closes #5169
- depends on and closes #5173 

This removes the constraint for `np.sum` for the `axis` parameter to fall within `[0, 3]` for non-constant values.

Also significantly simplifies the implementation.
user: ARF1
issue_5177: state: open
title: Implementation of  np.moveaxis()
body: Depends on and closes #5169.
Depends on and closes #5173.

Implements `numpy.moveaxis()`.
user: ARF1
issue_5170: state: open
title: Assigning to DeviceNDArray with Ellipsis fails
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```python
In [1]: import numba.cuda                                                       

In [2]: a = numba.cuda.device_array((10,))                                      

In [3]: a[...] = 1                                                              
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-4f8eed6187d7> in <module>
----> 1 a[...] = 1

/datasets/jkirkham/miniconda/envs/rapids13dev/lib/python3.7/site-packages/numba/cuda/cudadrv/devices.py in _require_cuda_context(*args, **kws)
    223     def _require_cuda_context(*args, **kws):
    224         with _runtime.ensure_context():
--> 225             return fn(*args, **kws)
    226 
    227     return _require_cuda_context

/datasets/jkirkham/miniconda/envs/rapids13dev/lib/python3.7/site-packages/numba/cuda/cudadrv/devicearray.py in __setitem__(self, key, value)
    528     @devices.require_context
    529     def __setitem__(self, key, value):
--> 530         return self._do_setitem(key, value)
    531 
    532     def setitem(self, key, value, stream=0):

/datasets/jkirkham/miniconda/envs/rapids13dev/lib/python3.7/site-packages/numba/cuda/cudadrv/devicearray.py in _do_setitem(self, key, value, stream)
    541         # (1) prepare LHS
    542 
--> 543         arr = self._dummy.__getitem__(key)
    544         newdata = self.gpu_data.view(*arr.extent)
    545 

/datasets/jkirkham/miniconda/envs/rapids13dev/lib/python3.7/site-packages/numba/dummyarray.py in __getitem__(self, item)
    217             item.append(slice(None, None))
    218 
--> 219         dims = [dim.__getitem__(it) for dim, it in zip(self.dims, item)]
    220         newshape = [d.size for d in dims if not d.single]
    221 

/datasets/jkirkham/miniconda/envs/rapids13dev/lib/python3.7/site-packages/numba/dummyarray.py in <listcomp>(.0)
    217             item.append(slice(None, None))
    218 
--> 219         dims = [dim.__getitem__(it) for dim, it in zip(self.dims, item)]
    220         newshape = [d.size for d in dims if not d.single]
    221 

/datasets/jkirkham/miniconda/envs/rapids13dev/lib/python3.7/site-packages/numba/dummyarray.py in __getitem__(self, item)
     70             return ret
     71         else:
---> 72             sliced = self[item:item + 1]
     73             return Dim(
     74                 start=sliced.start,

TypeError: unsupported operand type(s) for +: 'ellipsis' and 'int'
```
user: jakirkham
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_5158: state: open
title: DeviceNDArray.bind() does not seem to bind the stream to self
body: - [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

The documentation of what `bind()` says it will do and what the implementation does don't seem to match (or if they do, the documentation is pretty ambiguous) - in https://github.com/numba/numba/blob/master/numba/cuda/cudadrv/devicearray.py#L135-L141

```python
def bind(self, stream=0):
    """Bind a CUDA stream to this object so that all subsequent operation
    on this array defaults to the given stream.
    """
    clone = copy.copy(self)
    clone.stream = stream
    return clone
```

Using a modified reproducer from the now-closed #2664:

```python
from numba import cuda
import numpy as np
stream = cuda.stream()
with stream.auto_synchronize():
    arr = cuda.device_array(
        (3, 3), 
        dtype=np.float64)
    arr.bind(stream)
    assert arr.stream == stream
```

results in:

```
$ python repro.py 
Traceback (most recent call last):
  File "repro.py", line 9, in <module>
    assert arr.stream == stream
AssertionError
```

user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_5156: state: open
title: Cannot add edge as dest node on Arch Linux
body: I am using numba version `0.47.0` on this Docker Arch Linux Image: https://hub.docker.com/_/archlinux/

There seems to be an issue with parallelization *EDIT: with Python 3.8* on Arch Linux.

The error does **not** occur on Ubuntu *EDIT: with Python 3.7.3* or when setting `parallel=False`.

This issue was originally discovered in: https://github.com/pymatting/pymatting/issues/3

## Code

```python
import numpy as np
from numba import njit, prange

@njit("void()", parallel=True, cache=True)
def foo():
    for _ in prange(10):
        n = 1
        while n > 0:
            n -= 1
```

## Error

```python
Traceback (most recent call last):
  File "test.py", line 5, in <module>
    def foo():
  File "/usr/lib/python3.8/site-packages/numba/decorators.py", line 200, in wrapper
    disp.compile(sig)
  File "/usr/lib/python3.8/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/numba/dispatcher.py", line 768, in compile
    cres = self._compiler.compile(args, return_type)
  File "/usr/lib/python3.8/site-packages/numba/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/usr/lib/python3.8/site-packages/numba/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/usr/lib/python3.8/site-packages/numba/dispatcher.py", line 104, in _compile_core
    cres = compiler.compile_extra(self.targetdescr.typing_context,
  File "/usr/lib/python3.8/site-packages/numba/compiler.py", line 551, in compile_extra
    return pipeline.compile_extra(func)
  File "/usr/lib/python3.8/site-packages/numba/compiler.py", line 331, in compile_extra
    return self._compile_bytecode()
  File "/usr/lib/python3.8/site-packages/numba/compiler.py", line 393, in _compile_bytecode
    return self._compile_core()
  File "/usr/lib/python3.8/site-packages/numba/compiler.py", line 373, in _compile_core
    raise e
  File "/usr/lib/python3.8/site-packages/numba/compiler.py", line 364, in _compile_core
    pm.run(self.state)
  File "/usr/lib/python3.8/site-packages/numba/compiler_machinery.py", line 347, in run
    raise patched_exception
  File "/usr/lib/python3.8/site-packages/numba/compiler_machinery.py", line 338, in run
    self._runPass(idx, pass_inst, state)
  File "/usr/lib/python3.8/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/numba/compiler_machinery.py", line 302, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/usr/lib/python3.8/site-packages/numba/compiler_machinery.py", line 275, in check
    mangled = func(compiler_state)
  File "/usr/lib/python3.8/site-packages/numba/typed_passes.py", line 269, in run_pass
    parfor_pass.run()
  File "/usr/lib/python3.8/site-packages/numba/parfor.py", line 1513, in run
    self._convert_loop(self.func_ir.blocks)
  File "/usr/lib/python3.8/site-packages/numba/parfor.py", line 1950, in _convert_loop
    self._replace_loop_access_indices(
  File "/usr/lib/python3.8/site-packages/numba/parfor.py", line 1975, in _replace_loop_access_indices
    labels = find_topo_order(loop_body)
  File "/usr/lib/python3.8/site-packages/numba/ir_utils.py", line 1061, in find_topo_order
    cfg = compute_cfg_from_blocks(blocks)
  File "/usr/lib/python3.8/site-packages/numba/analysis.py", line 243, in compute_cfg_from_blocks
    cfg.add_edge(k, target)
  File "/usr/lib/python3.8/site-packages/numba/controlflow.py", line 89, in add_edge
    raise ValueError("Cannot add edge as dest node %s not in nodes %s" %
ValueError: Failed in nopython mode pipeline (step: convert to parfors)
Cannot add edge as dest node 10 not in nodes {26, 18, 12, 39}
```
user: 99991
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_5154: state: open
title: Implementing `__bytes__` on `DeviceNDArray`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

It would be useful to have an implementation of `__bytes__` for `DeviceNDArray` analogous to NumPy's. Ideally this would avoid an intermediate copy to a NumPy array (by using things like `cuMemcpyDtoH`).
user: jakirkham
issue_5149: state: open
title: access to np.array data / tobytes etc
body: ## Feature request

I'd like to turn a numpy array into a python bytes object within nopython code so I can use a short string (5 bytes), stored as a nested struct in an array with many (millions of) rows, as a dict key. I tried a few methods at https://repl.it/@TomGoBravo/numba-bytes


```
@njit
def cast_bytes(arr):
  return bytes(arr)

@njit
def cast_memoryview(arr):
  return memoryview(arr)[0:len(arr)]

@njit
def data_attribute(arr):
  return arr.data[0:len(arr)]

@njit
def tobytes_attribute(arr):
  return arr.tobytes()

@njit
def tostring_attribute(arr):
  return arr.tostring()
```



Unsurprisingly, since none of these are listed at https://numba.pydata.org/numba-doc/dev/reference/numpysupported.html they all fail.

I dug up 
https://stackoverflow.com/questions/53872450/viewing-int32-float32-as-bytes-inside-numba-nopython-function but it doesn't have an answer.

Can anybody suggest a work-around while the feature doesn't exist?

user: TomGoBravo
labels: good second issue: A good issue for second time contributors
issue_5139: state: open
title: Numba can't vectorize simple loop
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
```
import numpy
import numba
import llvmlite.binding as llvm

llvm.set_option('', '--debug-only=loop-vectorize,iv-descriptors')

@numba.njit(fastmath=True)
def my_array_min_impl(arry):
    min_value = arry[0]
    for i in range(1, arry.size):
        v = arry[i]
        if v < min_value:
            min_value = v
    return min_value


print(my_array_min_impl(numpy.array([1.0,2.0,3.0,4.0,5.0])))
# print(my_array_min_impl(numpy.array([1,2,3,4,5])))
```
Prints
```
...
LV: Not vectorizing: Found an unidentified PHI   %min_value.09.i = phi double [ %min_value.1.i, %B26.i ], [ %.55.i, %B26.i.preheader ]
LV: Can't vectorize the instructions or CFG
...
```
While int version (commented) prints:
```
...
LV: We can vectorize this loop!
...
```
Clang can successfully vectorize similar loop with `-ffast-math`  https://godbolt.org/z/6noLYp

One of the issues is llvm vectorizer checking for `no-nans-fp-math=true` function attribute which is not set by numba `fastmath=True` and it seems there is no way to set it currently.
https://github.com/llvm/llvm-project/blob/release/9.x/llvm/lib/Analysis/IVDescriptors.cpp#L618
https://github.com/llvm/llvm-project/blob/release/9.x/llvm/lib/Analysis/IVDescriptors.cpp#L300
https://github.com/llvm/llvm-project/blob/release/9.x/llvm/lib/Analysis/IVDescriptors.cpp#L590
But there can be more

Tested on master (e2dc1ae4520508be64c2c9f726689232d24e938a)
user: Hardcode84
labels: llvm: LLVM related issues
performance: performance related issue
issue_5131: state: open
title: CUDA: pinned_array_like, pinned_zeroes, pinned_ones, etc. would be handy
body: Being able to do things like:

```python
# a is some np.ndarray
pinned_a = cuda.pinned_array_like(a)

# As opposed to `my_zs = cuda.pinned_array(10); my_zs[:] = 0`
my_zs = cuda.pinned_zeros(10)

# As opposed to `my_zs = cuda.pinned_array(10); my_zs[:] = 1`
my_ones = cuda.pinned_ones(10)
```

In general if we could create pinned arrays in more ways similar to how NumPy `ndarray` objects can be created, this would provide a slightly nicer API to work with.
user: gmarkall
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_5128: state: open
title: make caching work for source-less functions, e.g. strings, lambdify exprs.
body: I am evaluating a big sympy generated expression to solve and ODE. I have been able to accelerate it by applying numba.jit to the lambdified expression. However, as the the compilation of the expression takes a long time I wanted to cache the jitted function. Unfortunately, this step returns an error.

A minimal working example is:

```python
from sympy import symbols, lambdify, sqrt
import numpy as np
from numba import jit


x, y = symbols('x y')

expr = sqrt(x**2 + y**2)

fun = lambdify((x, y), expr, modules='numpy', dummify=False)

fun_jit = jit(fun, nopython=True)  # works
# fun_jit = jit(fun, nopython=True, cache=True)  # does not work

N = 10000
x, y = np.linspace(0, 100, N), np.linspace(0, 100,  N)

print('lambdify')
fun(x, y)
print('jitted lambdify')
fun_jit(x, y)
```

The error returned is:

```
Traceback (most recent call last):
  File "C:\Users\xxx\user_programs\miniconda3\envs\py36_64\lib\site-packages\IPython\core\interactiveshell.py", line 3296, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-15-0a062e456430>", line 1, in <module>
    fun_jit = jit(fun, nopython=True, cache=True)
  File "C:\Users\xxx\user_programs\miniconda3\envs\py36_64\lib\site-packages\numba\decorators.py", line 161, in jit
    return wrapper(pyfunc)
  File "C:\Users\xxx\user_programs\miniconda3\envs\py36_64\lib\site-packages\numba\decorators.py", line 179, in wrapper
    disp.enable_caching()
  File "C:\Users\xxx\user_programs\miniconda3\envs\py36_64\lib\site-packages\numba\dispatcher.py", line 571, in enable_caching
    self._cache = FunctionCache(self.py_func)
  File "C:\Users\xxx\user_programs\miniconda3\envs\py36_64\lib\site-packages\numba\caching.py", line 614, in __init__
    self._impl = self._impl_class(py_func)
  File "C:\Users\xxx\user_programs\miniconda3\envs\py36_64\lib\site-packages\numba\caching.py", line 349, in __init__
    "for file %r" % (qualname, source_path))
RuntimeError: cannot cache function '_lambdifygenerated': no locator available for file '<lambdifygenerated-6>'
```

I already opened an issue in sympy https://github.com/sympy/sympy/issues/18432 and as suggested by @oscarbenjamin , this might be related to the fact that sympy is not generating a source file for the lambdified expression.

Do you think that there is any possible modification to get this working in numba?
user: AlexS12
labels: caching: Issue involving caching
issue_5125: state: open
title: Passing a set of strings to Numba function fails
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Passing a `set` of string values to a Numba function fails:
```python
@numba.njit
def g(s):
    return "A" in s

g(set(("AB","D")))
```
```
Traceback (most recent call last):
  File "../str_map.py", line 41, in <module>
    g(set(("AB","D")))
  File "/Users/ehsan/dev/numba/numba/dispatcher.py", line 604, in typeof_pyval
    tp = typeof(val, Purpose.argument)
  File "/Users/ehsan/dev/numba/numba/typing/typeof.py", line 30, in typeof
    ty = typeof_impl(val, c)
  File "/opt/anaconda3/envs/TEST3/lib/python3.7/functools.py", line 827, in wrapper
    return dispatch(args[0].__class__)(*args, **kw)
  File "/Users/ehsan/dev/numba/numba/typing/typeof.py", line 180, in _typeof_set
    return types.Set(ty, reflected=True)
  File "/Users/ehsan/dev/numba/numba/types/abstract.py", line 69, in __call__
    inst = type.__call__(cls, *args, **kwargs)
  File "/Users/ehsan/dev/numba/numba/types/containers.py", line 432, in __init__
    assert isinstance(dtype, (Hashable, Undefined))
AssertionError
```
This assertion shouldn't probably fail since string objects are hashable. Commenting out the `assert` statement gives lowering error:
```
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
No definition for lowering <built-in function eq>(unicode_type, unicode_type) -> bool

File "../str_map.py", line 39:
def g(s):
    return "A" in s
    ^

[1] During: lowering "$6compare_op.2 = $const2.0 in s" at ../str_map.py (39)
```
Adding the lowerer gives another error:
```python
@lower_builtin(operator.eq, numba.types.unicode_type, numba.types.unicode_type)
def lower_string_eq(context, builder, sig, args):
    return context.compile_internal(builder, numba.unicode.unicode_eq(*sig.args), sig, args)
```
```
  File "/Users/ehsan/dev/numba/numba/typed_passes.py", line 351, in run_pass
    lower.create_cpython_wrapper(flags.release_gil)
  File "/Users/ehsan/dev/numba/numba/lowering.py", line 302, in create_cpython_wrapper
    release_gil=release_gil)
  File "/Users/ehsan/dev/numba/numba/targets/cpu.py", line 162, in create_cpython_wrapper
    builder.build()
  File "/Users/ehsan/dev/numba/numba/callwrapper.py", line 124, in build
    self.build_wrapper(api, builder, closure, args, kws)
  File "/Users/ehsan/dev/numba/numba/callwrapper.py", line 157, in build_wrapper
    val = cleanup_manager.add_arg(builder.load(obj), ty)
  File "/Users/ehsan/dev/numba/numba/callwrapper.py", line 32, in add_arg
    native = self.api.to_native_value(ty, obj)
  File "/Users/ehsan/dev/numba/numba/pythonapi.py", line 1425, in to_native_value
    return impl(typ, obj, c)
  File "/Users/ehsan/dev/numba/numba/targets/boxing.py", line 888, in unbox_set
    _python_set_to_native(typ, obj, c, size, setptr, errorptr)
  File "/Users/ehsan/dev/numba/numba/targets/boxing.py", line 842, in _python_set_to_native
    inst.add_pyapi(c.pyapi, native.value, do_resize=False)
  File "/Users/ehsan/dev/numba/numba/targets/setobj.py", line 488, in add_pyapi
    self._add_key(payload, item, h, do_resize)
  File "/Users/ehsan/dev/numba/numba/targets/setobj.py", line 425, in _add_key
    found, i = payload._lookup(item, h, for_insert=True)
  File "/Users/ehsan/dev/numba/numba/targets/setobj.py", line 241, in _lookup
    check_entry(i)
  File "/Users/ehsan/dev/numba/numba/targets/setobj.py", line 221, in check_entry
    eq = eqfn(builder, (item, entry.key))
  File "/Users/ehsan/dev/numba/numba/targets/base.py", line 1146, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "/Users/ehsan/dev/numba/numba/targets/base.py", line 1176, in wrapper
    return fn(*args, **kwargs)
  File "../str_map.py", line 43, in lower_string_eq
    return context.compile_internal(builder, numba.unicode.unicode_eq(*sig.args), sig, args)
  File "/Users/ehsan/dev/numba/numba/targets/base.py", line 873, in compile_internal
    return self.call_internal(builder, cres.fndesc, sig, args)
  File "/Users/ehsan/dev/numba/numba/targets/base.py", line 887, in call_internal
    self.call_conv.return_status_propagate(builder, status)
  File "/Users/ehsan/dev/numba/numba/targets/callconv.py", line 441, in return_status_propagate
    builder.store(status.excinfoptr, excptr)
  File "/opt/anaconda3/envs/TEST3/lib/python3.7/site-packages/llvmlite/ir/builder.py", line 740, in store
    % (value.type, ptr.type))
TypeError: Failed in nopython mode pipeline (step: nopython mode backend)
cannot store {i8*, i32}* to i8*: mismatching types
```
user: ehsantn
issue_5124: state: open
title: slicing arrays pessimises array layout in typing
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This:
```python
from numba import njit
import numpy as np


@njit
def foo(X):
    a = X[0]
    b = X[0, :, :]
    return a, b


X = np.zeros((3, 4, 5))
X.flags

print("Numba")
a, b = foo(X)
print(a.flags)
print(b.flags)

print("NumPy")
a, b = foo.py_func(X)
print(a.flags)
print(b.flags)

foo.inspect_types()
```
does this:
```
Numba
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False

  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False

NumPy
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False

  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False

foo (array(float64, 3d, C),)
--------------------------------------------------------------------------------
# File: foo2522.py
# --- LINE 5 --- 

@njit

# --- LINE 6 --- 

def foo(X):

    # --- LINE 7 --- 
    # label 0
    #   X = arg(0, name=X)  :: array(float64, 3d, C)
    #   $const4.1 = const(int, 0)  :: Literal[int](0)
    #   $6binary_subscr.2 = static_getitem(value=X, index=0, index_var=$const4.1)  :: array(float64, 2d, C)
    #   del $const4.1
    #   a = $6binary_subscr.2  :: array(float64, 2d, C)
    #   del $6binary_subscr.2

    a = X[0]

    # --- LINE 8 --- 
    #   $const12.4 = const(int, 0)  :: Literal[int](0)
    #   $const14.5 = const(NoneType, None)  :: none
    #   $const16.6 = const(NoneType, None)  :: none
    #   $18build_slice.7 = global(slice: <class 'slice'>)  :: Function(<class 'slice'>)
    #   $18build_slice.8 = call $18build_slice.7($const14.5, $const16.6, func=$18build_slice.7, args=(Var($const14.5, foo2522.py:8), Var($const16.6, foo2522.py:8)), kws=(), vararg=None)  :: (none, none) -> slice<a:b>
    #   del $const16.6
    #   del $const14.5
    #   del $18build_slice.7
    #   $const20.9 = const(NoneType, None)  :: none
    #   $const22.10 = const(NoneType, None)  :: none
    #   $24build_slice.11 = global(slice: <class 'slice'>)  :: Function(<class 'slice'>)
    #   $24build_slice.12 = call $24build_slice.11($const20.9, $const22.10, func=$24build_slice.11, args=(Var($const20.9, foo2522.py:8), Var($const22.10, foo2522.py:8)), kws=(), vararg=None)  :: (none, none) -> slice<a:b>
    #   del $const22.10
    #   del $const20.9
    #   del $24build_slice.11
    #   $26build_tuple.13 = build_tuple(items=[Var($const12.4, foo2522.py:8), Var($18build_slice.8, foo2522.py:8), Var($24build_slice.12, foo2522.py:8)])  :: Tuple(Literal[int](0), slice<a:b>, slice<a:b>)
    #   del $const12.4
    #   del $24build_slice.12
    #   del $18build_slice.8
    #   $28binary_subscr.14 = static_getitem(value=X, index=(0, slice(None, None, None), slice(None, None, None)), index_var=$26build_tuple.13)  :: array(float64, 2d, A)
    #   del X
    #   del $26build_tuple.13
    #   b = $28binary_subscr.14  :: array(float64, 2d, A)
    #   del $28binary_subscr.14

    b = X[0, :, :]

    # --- LINE 9 --- 
    #   $36build_tuple.17 = build_tuple(items=[Var(a, foo2522.py:7), Var(b, foo2522.py:8)])  :: Tuple(array(float64, 2d, C), array(float64, 2d, A))
    #   del b
    #   del a
    #   $38return_value.18 = cast(value=$36build_tuple.17)  :: Tuple(array(float64, 2d, C), array(float64, 2d, A))
    #   del $36build_tuple.17
    #   return $38return_value.18

    return a, b
```
the answer is correct, but that the `b = X[0, :, :]` ends up being typed as `array(float64, 2d, A)` pessimises later functions that might specialise on contiguous data e.g. `np.dot`.

CC @eric-wieser 

user: stuartarchibald
labels: performance: performance related issue
issue_5103: state: open
title: Option to run Numba tests with pdb
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

It would be useful to have an option to run Numba tests with pdb. That way if a test fails, one can be dropped into the debugger to inspect the failing tests. It's really useful for fixing test failures. FWIW pytest has [an analogous feature]( https://docs.pytest.org/en/latest/usage.html#dropping-to-pdb-python-debugger-on-failures ) for comparison.

(Apologies in advance if this does work today and I'm just clueless 🙂)
user: jakirkham
issue_5101: state: open
title: Add `@lower_constant` example to `IntervalType` doc
body: As title.
user: stuartarchibald
issue_5094: state: open
title: object mode fails sometimes
body: Hi,

this snippet gets called several times in my main Numba processing function:

```
@nb.jit(boundscheck=True, debug=True, forceobj=True)
def printing4Numba(runner, datetimeInt, par0, par1, par2, par3, par4):
   with nb.objmode():
        print('%8s' % runner, datetime.datetime.utcfromtimestamp(datetimeInt), par0, par1, par2, par3, par4)
        1 + 1

```
Using the directives `@nb.jit(boundscheck=True, debug=True, forceobj=True)` 
leads to this error (at least sometimes):
```
warning: ignoring debug info with an invalid version (0) in <string>
Traceback (most recent call last):
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/errors.py", line 717, in new_error_context
    yield
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/lowering.py", line 288, in lower_block
    self.lower_inst(inst)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/pylowering.py", line 176, in lower_inst
    raise NotImplementedError(type(inst), inst)
NotImplementedError: (<class 'numba.ir.EnterWith'>, <numba.ir.EnterWith object at 0x7f7ea4f010f0>)

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
.
.
.
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/dispatcher.py", line 420, in _compile_for_args
    raise e
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/dispatcher.py", line 768, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler.py", line 551, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler.py", line 331, in compile_extra
    return self._compile_bytecode()
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler.py", line 393, in _compile_bytecode
    return self._compile_core()
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler.py", line 373, in _compile_core
    raise e
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler.py", line 364, in _compile_core
    pm.run(self.state)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler_machinery.py", line 347, in run
    raise patched_exception
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler_machinery.py", line 338, in run
    self._runPass(idx, pass_inst, state)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler_machinery.py", line 302, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/compiler_machinery.py", line 275, in check
    mangled = func(compiler_state)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/object_mode_passes.py", line 145, in run_pass
    lowered = backend_object_mode()
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/object_mode_passes.py", line 143, in backend_object_mode
    state.flags)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/object_mode_passes.py", line 100, in _py_lowering_stage
    lower.lower()
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/lowering.py", line 195, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/lowering.py", line 248, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/lowering.py", line 273, in lower_function_body
    self.lower_block(block)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/lowering.py", line 288, in lower_block
    self.lower_inst(inst)
  File "/home/user/anaconda3/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/errors.py", line 725, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/home/user/venv/numba/lib/python3.6/site-packages/numba/six.py", line 669, in reraise
    raise value
numba.errors.LoweringError: Failed in object mode pipeline (step: object mode backend)
(<class 'numba.ir.EnterWith'>, <numba.ir.EnterWith object at 0x7f7ea4f010f0>)

File "t_a0340_aBig_B.py", line 437:
def printing4Numba(runner, datetimeInt, par0, par1, par2, par3, par4):
   with nb.objmode():
   ^

[1] During: lowering "enter_with $phi8.1" at /home/user/PycharmProjects/0650_r_b/t_a0340_aBig_B.py (437)

-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.47.0.
```

Please see also https://github.com/numba/numba/issues/5093

Unfortunately, I cannot share my code. Extracting it to a minimal reproducable code snippet did not work neither.

user: haimivan
issue_5086: state: open
title: np.nan is np.nan behaves differently when jitted
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using versions `0.47.0` and `0.45.1` installed with conda

- [x] I have included below a minimal working reproducer 

Comparison of `np.nan` to itself using `is` behaves differently when jitted:

```
import numpy as np
import numba

def foo():
    return np.nan is np.nan

@numba.njit
def jitfoo():
    return np.nan is np.nan
```
`foo()` returns `True`
`jitfoo()` returns `False`

Obviously it's best to use `np.isnan` where possible 
user: timothymillar
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_5084: state: open
title: Support for Stack-Allocated Arrays
body: Very small, heap allocated arrays have a high overhead in cases where c-function should be wrapped. Therefore it would be good to support stack-allocated arrays in an official API.

[Related exampe (passing scalar by reference)](https://github.com/person142/numba_special/issues/1#issuecomment-568278201)

**Intrinsic implementation and basic example**

```Python
import numpy as np
import numba as nb

from numba import types
from numba.extending import intrinsic
from numba import cgutils

@intrinsic
def stack_empty(typingctx,size,dtype):
    def impl(context, builder, signature, args):
        ty=context.get_value_type(dtype.dtype)
        ptr = cgutils.alloca_once(builder, ty,size=args[0])
        return ptr
    
    sig = types.CPointer(dtype.dtype)(types.int64,dtype)
    return sig, impl

@nb.njit()
def method_using_intrinsics():
    #Allocate memory on stack
    #arr_ptr can for example be passed to a wrapped c-function
    arr_ptr=stack_empty(10,np.float64)

    #Create a view on the allocated memory and do something
    arr=nb.carray(arr_ptr,10)
    for i in range(arr.shape[0]):
        arr[i]=i

    print(arr)
```

**Edit: Maybe more comfortable**

```Python
import numpy as np
import numba as nb

from numba import types
from numba.extending import intrinsic,register_jitable
from numba.core import cgutils


@intrinsic
def stack_empty_impl(typingctx,size,dtype):
    def impl(context, builder, signature, args):
        ty=context.get_value_type(dtype.dtype)
        ptr = cgutils.alloca_once(builder, ty,size=args[0])
        return ptr

    sig = types.CPointer(dtype.dtype)(types.int64,dtype)
    return sig, impl

@register_jitable
def stack_empty(size,shape,dtype):
    """
    Size (int) must be a fixed at compile time. 
    It is not possible to change it during execution.

    The shape (tuple) size can be as large as the size or smaller. 
    This can be dynamically changed during execution.

    The datatype also have to be fixed in this implementation.

    The carray can't be returned from a function. 
    """
    arr_ptr=stack_empty_impl(size,dtype)
    arr=nb.carray(arr_ptr,shape)
    return arr_ptr, arr

@nb.njit()
def method_using_intrinsics():
    arr_ptr, arr=stack_empty(50,(5,10),np.int32)
    for i in range(arr.shape[0]):
        arr[i]=i

    print(arr)
```
user: max9111
issue_5075: state: open
title: np concatenate slower in numba
body: Not sure if this needs resolving, but as I was benchmarking a piece of code I noticed more time was being spent in concatenate than I expected. So I tried having numba speed up that operation, but the result was it became slower by a factor of 2ish (88 ms vs 200 ms).

```
from numba import njit

@njit
def fast_concatenate(arrays, axis=0):
    return np.concatenate(arrays, axis=axis)

```

I was concatenating two arrays and their shapes were (1476, 1292, 1). I'm on numba 0.47.

edit: Realized I gave the shape for just one array. The timing I gave of 88 ms vs 200 ms, was for (1476, 1292, 1) and (1476, 1292, 35ish) for axis 2. Timing other axes also shows a performance difference (including the default axis of 0).
user: hmc-cs-mdrissi
labels: performance: performance related issue
performance - run time: Performance issue occurring at run time.
issue_5072: state: open
title: Accept `prange` driven loops in the loop body versioning transform.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Accept `prange` driven loops in the loop body versioning transform. From mailing list: https://groups.google.com/a/continuum.io/forum/#!topic/numba-users/3BtwxQ_tNUQ

Example:
```python
from numba import njit, prange, literal_unroll
import numpy as np

@njit
def foo1(x):
    return x**2

@njit
def foo2(x):
    return x**3

@njit(parallel=True)
def baz(z):
    acc = 0
    for i in prange(len(literal_unroll(z))): # versioned `prange` loop.
        f, a = z[i]
        acc += f(a)
    return acc

funtup = (foo1, foo2)
args = (1., 2)

z = ((foo1, 1.), (foo2, 2))

print(baz(z))
```
I expect accepting the loop form is a relatively simple change but getting parfors to handle it will be challenging?

user: stuartarchibald
issue_5069: state: open
title: Improve error message for accidental use of a non-void function spec in `@guvectorize`.
body: ## Feature request
As title.
user: stuartarchibald
labels: good second issue: A good issue for second time contributors
issue_5067: state: open
title: Avoidable loop vectorization failure with float datatype (x3.5 performance penalty)
body: With numba 0.47 there are issues with loop vectorization where the same loop structure vectorizes with some data types but not with others.

But running the numba `NUMBA_DUMP_OPTIMIZED` code with the failed loop vectorization through **`opt` fixes the failed loop vectorization**!

This bug has a significant performance penalty for some float operations. I the case of `max()` numba takes 3.5x as long as numpy. See the details below for a demonstration:

<details>

```python
Python 3.7.5 (default, Oct 31 2019, 15:18:51) [MSC v.1916 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.10.2 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import numpy as np
   ...: from numba import njit
   ...:

In [2]: test_size = int(1e7)
   ...: arr32 = np.random.random(test_size).astype(np.float32)

In [3]: def test_numpy_max(arr):
   ...:     return np.max(arr)
   ...:

In [4]: %%timeit test_numpy_max(arr32)
   ...: test_numpy_max(arr32)
   ...:
   ...:
3.02 ms ± 51.4 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [5]: @njit(fastmath=True)
   ...: def test_numba_max(arr):
   ...:     return np.max(arr)
   ...:

In [6]: %%timeit test_numba_max(arr32)
   ...: test_numba_max(arr32)
   ...:
   ...:
10.8 ms ± 40.7 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

```
</details>

While it is possible to code around this issue by writing loops that are manually quasi-vectorized, this is fairly impractical and leads to code that is hard to read.

----

To illustrate that the solution should be fixable, let's take the following function as an example:
```python
@njit(fastmath=True)
def array_max_impl(arr, n):
    a = arr.flat
    max_value = a[0]
    for i in range(1, n):
        if a[i] > max_value:
            max_value = a[i]
    return max_value
```

In numba this vectorizes perfectly fine for `int32`. See the output produced by `NUMBA_DUMP_OPTIMIZED` in the following details section:

<details>

```llvm
; ModuleID = 'array_max_impl'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"

@"_ZN08NumbaEnv8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx" = common local_unnamed_addr global i8* null
@.const.array_max_impl = internal constant [15 x i8] c"array_max_impl\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@PyExc_TypeError = external global i8
@".const.can't unbox array from PyObject into native value.  The object maybe of a different type" = internal constant [89 x i8] c"can't unbox array from PyObject into native value.  The object maybe of a different type\00"

; Function Attrs: norecurse nounwind
define i32 @"_ZN8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx"(i32* noalias nocapture %retptr, { i8*, i32 }** noalias nocapture readnone %excinfo, i8* nocapture readnone %arg.arr.0, i8* nocapture readnone %arg.arr.1, i64 %arg.arr.2, i64 %arg.arr.3, i32* nocapture readonly %arg.arr.4, i64 %arg.arr.5.0, i64 %arg.arr.6.0, i64 %arg.n) local_unnamed_addr #0 {
entry:
  %.90 = load i32, i32* %arg.arr.4, align 4
  %.157 = add i64 %arg.n, -1
  %.158 = icmp sgt i64 %.157, 0
  br i1 %.158, label %B30.preheader, label %B54

B30.preheader:                                    ; preds = %entry
  %min.iters.check = icmp ult i64 %.157, 32
  br i1 %min.iters.check, label %B30.preheader38, label %vector.ph

vector.ph:                                        ; preds = %B30.preheader
  %n.vec = and i64 %.157, -32
  %ind.end = sub i64 %.157, %n.vec
  %ind.end9 = or i64 %n.vec, 1
  %minmax.ident.splatinsert = insertelement <8 x i32> undef, i32 %.90, i32 0
  %minmax.ident.splat = shufflevector <8 x i32> %minmax.ident.splatinsert, <8 x i32> undef, <8 x i32> zeroinitializer
  %0 = add i64 %n.vec, -32
  %1 = lshr exact i64 %0, 5
  %2 = add nuw nsw i64 %1, 1
  %xtraiter = and i64 %2, 1
  %3 = icmp eq i64 %0, 0
  br i1 %3, label %middle.block.unr-lcssa, label %vector.ph.new

vector.ph.new:                                    ; preds = %vector.ph
  %4 = add i64 %xtraiter, -1
  %5 = sub i64 %2, 1
  %6 = sub i64 %4, %5
  br label %vector.body

vector.body:                                      ; preds = %vector.body, %vector.ph.new
  %lsr.iv71 = phi i64 [ %lsr.iv.next72, %vector.body ], [ %6, %vector.ph.new ]
  %lsr.iv47 = phi i64 [ %lsr.iv.next, %vector.body ], [ 1, %vector.ph.new ]
  %vec.phi = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %19, %vector.body ]
  %vec.phi10 = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %20, %vector.body ]
  %vec.phi11 = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %21, %vector.body ]
  %vec.phi12 = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %22, %vector.body ]
  %scevgep60 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep6061 = bitcast i32* %scevgep60 to <8 x i32>*
  %wide.load = load <8 x i32>, <8 x i32>* %scevgep6061, align 4
  %scevgep68 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep6869 = bitcast i32* %scevgep68 to <8 x i32>*
  %scevgep70 = getelementptr <8 x i32>, <8 x i32>* %scevgep6869, i64 1
  %wide.load23 = load <8 x i32>, <8 x i32>* %scevgep70, align 4
  %scevgep65 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep6566 = bitcast i32* %scevgep65 to <8 x i32>*
  %scevgep67 = getelementptr <8 x i32>, <8 x i32>* %scevgep6566, i64 2
  %wide.load24 = load <8 x i32>, <8 x i32>* %scevgep67, align 4
  %scevgep62 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep6263 = bitcast i32* %scevgep62 to <8 x i32>*
  %scevgep64 = getelementptr <8 x i32>, <8 x i32>* %scevgep6263, i64 3
  %wide.load25 = load <8 x i32>, <8 x i32>* %scevgep64, align 4
  %7 = icmp sgt <8 x i32> %wide.load, %vec.phi
  %8 = icmp sgt <8 x i32> %wide.load23, %vec.phi10
  %9 = icmp sgt <8 x i32> %wide.load24, %vec.phi11
  %10 = icmp sgt <8 x i32> %wide.load25, %vec.phi12
  %11 = select <8 x i1> %7, <8 x i32> %wide.load, <8 x i32> %vec.phi
  %12 = select <8 x i1> %8, <8 x i32> %wide.load23, <8 x i32> %vec.phi10
  %13 = select <8 x i1> %9, <8 x i32> %wide.load24, <8 x i32> %vec.phi11
  %14 = select <8 x i1> %10, <8 x i32> %wide.load25, <8 x i32> %vec.phi12
  %scevgep57 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep5758 = bitcast i32* %scevgep57 to <8 x i32>*
  %scevgep59 = getelementptr <8 x i32>, <8 x i32>* %scevgep5758, i64 4
  %wide.load.1 = load <8 x i32>, <8 x i32>* %scevgep59, align 4
  %scevgep54 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep5455 = bitcast i32* %scevgep54 to <8 x i32>*
  %scevgep56 = getelementptr <8 x i32>, <8 x i32>* %scevgep5455, i64 5
  %wide.load23.1 = load <8 x i32>, <8 x i32>* %scevgep56, align 4
  %scevgep51 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep5152 = bitcast i32* %scevgep51 to <8 x i32>*
  %scevgep53 = getelementptr <8 x i32>, <8 x i32>* %scevgep5152, i64 6
  %wide.load24.1 = load <8 x i32>, <8 x i32>* %scevgep53, align 4
  %scevgep48 = getelementptr i32, i32* %arg.arr.4, i64 %lsr.iv47
  %scevgep4849 = bitcast i32* %scevgep48 to <8 x i32>*
  %scevgep50 = getelementptr <8 x i32>, <8 x i32>* %scevgep4849, i64 7
  %wide.load25.1 = load <8 x i32>, <8 x i32>* %scevgep50, align 4
  %15 = icmp sgt <8 x i32> %wide.load.1, %11
  %16 = icmp sgt <8 x i32> %wide.load23.1, %12
  %17 = icmp sgt <8 x i32> %wide.load24.1, %13
  %18 = icmp sgt <8 x i32> %wide.load25.1, %14
  %19 = select <8 x i1> %15, <8 x i32> %wide.load.1, <8 x i32> %11
  %20 = select <8 x i1> %16, <8 x i32> %wide.load23.1, <8 x i32> %12
  %21 = select <8 x i1> %17, <8 x i32> %wide.load24.1, <8 x i32> %13
  %22 = select <8 x i1> %18, <8 x i32> %wide.load25.1, <8 x i32> %14
  %lsr.iv.next = add i64 %lsr.iv47, 64
  %lsr.iv.next72 = add i64 %lsr.iv71, 2
  %niter.ncmp.1 = icmp eq i64 %lsr.iv.next72, 0
  br i1 %niter.ncmp.1, label %middle.block.unr-lcssa, label %vector.body, !llvm.loop !0

middle.block.unr-lcssa:                           ; preds = %vector.body, %vector.ph
  %.lcssa41.ph = phi <8 x i32> [ undef, %vector.ph ], [ %19, %vector.body ]
  %.lcssa40.ph = phi <8 x i32> [ undef, %vector.ph ], [ %20, %vector.body ]
  %.lcssa39.ph = phi <8 x i32> [ undef, %vector.ph ], [ %21, %vector.body ]
  %.lcssa.ph = phi <8 x i32> [ undef, %vector.ph ], [ %22, %vector.body ]
  %index.unr = phi i64 [ 1, %vector.ph ], [ %lsr.iv.next, %vector.body ]
  %vec.phi.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %19, %vector.body ]
  %vec.phi10.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %20, %vector.body ]
  %vec.phi11.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %21, %vector.body ]
  %vec.phi12.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %22, %vector.body ]
  %lcmp.mod = icmp eq i64 %xtraiter, 0
  br i1 %lcmp.mod, label %middle.block, label %vector.body.epil

vector.body.epil:                                 ; preds = %middle.block.unr-lcssa
  %23 = getelementptr i32, i32* %arg.arr.4, i64 %index.unr
  %24 = bitcast i32* %23 to <8 x i32>*
  %wide.load.epil = load <8 x i32>, <8 x i32>* %24, align 4
  %25 = getelementptr i32, i32* %23, i64 8
  %26 = bitcast i32* %25 to <8 x i32>*
  %wide.load23.epil = load <8 x i32>, <8 x i32>* %26, align 4
  %27 = getelementptr i32, i32* %23, i64 16
  %28 = bitcast i32* %27 to <8 x i32>*
  %wide.load24.epil = load <8 x i32>, <8 x i32>* %28, align 4
  %29 = getelementptr i32, i32* %23, i64 24
  %30 = bitcast i32* %29 to <8 x i32>*
  %wide.load25.epil = load <8 x i32>, <8 x i32>* %30, align 4
  %31 = icmp sgt <8 x i32> %wide.load25.epil, %vec.phi12.unr
  %32 = select <8 x i1> %31, <8 x i32> %wide.load25.epil, <8 x i32> %vec.phi12.unr
  %33 = icmp sgt <8 x i32> %wide.load24.epil, %vec.phi11.unr
  %34 = select <8 x i1> %33, <8 x i32> %wide.load24.epil, <8 x i32> %vec.phi11.unr
  %35 = icmp sgt <8 x i32> %wide.load23.epil, %vec.phi10.unr
  %36 = select <8 x i1> %35, <8 x i32> %wide.load23.epil, <8 x i32> %vec.phi10.unr
  %37 = icmp sgt <8 x i32> %wide.load.epil, %vec.phi.unr
  %38 = select <8 x i1> %37, <8 x i32> %wide.load.epil, <8 x i32> %vec.phi.unr
  br label %middle.block

middle.block:                                     ; preds = %middle.block.unr-lcssa, %vector.body.epil
  %.lcssa41 = phi <8 x i32> [ %.lcssa41.ph, %middle.block.unr-lcssa ], [ %38, %vector.body.epil ]
  %.lcssa40 = phi <8 x i32> [ %.lcssa40.ph, %middle.block.unr-lcssa ], [ %36, %vector.body.epil ]
  %.lcssa39 = phi <8 x i32> [ %.lcssa39.ph, %middle.block.unr-lcssa ], [ %34, %vector.body.epil ]
  %.lcssa = phi <8 x i32> [ %.lcssa.ph, %middle.block.unr-lcssa ], [ %32, %vector.body.epil ]
  %rdx.minmax.cmp = icmp sgt <8 x i32> %.lcssa41, %.lcssa40
  %rdx.minmax.select = select <8 x i1> %rdx.minmax.cmp, <8 x i32> %.lcssa41, <8 x i32> %.lcssa40
  %rdx.minmax.cmp26 = icmp sgt <8 x i32> %rdx.minmax.select, %.lcssa39
  %rdx.minmax.select27 = select <8 x i1> %rdx.minmax.cmp26, <8 x i32> %rdx.minmax.select, <8 x i32> %.lcssa39
  %rdx.minmax.cmp28 = icmp sgt <8 x i32> %rdx.minmax.select27, %.lcssa
  %rdx.minmax.select29 = select <8 x i1> %rdx.minmax.cmp28, <8 x i32> %rdx.minmax.select27, <8 x i32> %.lcssa
  %rdx.shuf = shufflevector <8 x i32> %rdx.minmax.select29, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp30 = icmp sgt <8 x i32> %rdx.minmax.select29, %rdx.shuf
  %rdx.minmax.select31 = select <8 x i1> %rdx.minmax.cmp30, <8 x i32> %rdx.minmax.select29, <8 x i32> %rdx.shuf
  %rdx.shuf32 = shufflevector <8 x i32> %rdx.minmax.select31, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp33 = icmp sgt <8 x i32> %rdx.minmax.select31, %rdx.shuf32
  %rdx.minmax.select34 = select <8 x i1> %rdx.minmax.cmp33, <8 x i32> %rdx.minmax.select31, <8 x i32> %rdx.shuf32
  %rdx.shuf35 = shufflevector <8 x i32> %rdx.minmax.select34, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp36 = icmp sgt <8 x i32> %rdx.minmax.select34, %rdx.shuf35
  %rdx.minmax.select37 = select <8 x i1> %rdx.minmax.cmp36, <8 x i32> %rdx.minmax.select34, <8 x i32> %rdx.shuf35
  %39 = extractelement <8 x i32> %rdx.minmax.select37, i32 0
  %cmp.n = icmp eq i64 %.157, %n.vec
  br i1 %cmp.n, label %B54, label %B30.preheader38

B30.preheader38:                                  ; preds = %middle.block, %B30.preheader
  %max_value.07.ph = phi i32 [ %.90, %B30.preheader ], [ %39, %middle.block ]
  %.147.06.ph = phi i64 [ %.157, %B30.preheader ], [ %ind.end, %middle.block ]
  %.144.05.ph = phi i64 [ 1, %B30.preheader ], [ %ind.end9, %middle.block ]
  %scevgep = getelementptr i32, i32* %arg.arr.4, i64 %.144.05.ph
  br label %B30

B30:                                              ; preds = %B30.preheader38, %B30
  %lsr.iv = phi i32* [ %scevgep, %B30.preheader38 ], [ %scevgep46, %B30 ]
  %max_value.07 = phi i32 [ %spec.select, %B30 ], [ %max_value.07.ph, %B30.preheader38 ]
  %.147.06 = phi i64 [ %.219, %B30 ], [ %.147.06.ph, %B30.preheader38 ]
  %.219 = add nsw i64 %.147.06, -1
  %.285 = load i32, i32* %lsr.iv, align 4
  %.291 = icmp sgt i32 %.285, %max_value.07
  %spec.select = select i1 %.291, i32 %.285, i32 %max_value.07
  %scevgep46 = getelementptr i32, i32* %lsr.iv, i64 1
  %.210 = icmp sgt i64 %.219, 0
  br i1 %.210, label %B30, label %B54, !llvm.loop !2

B54:                                              ; preds = %B30, %middle.block, %entry
  %max_value.0.lcssa = phi i32 [ %.90, %entry ], [ %39, %middle.block ], [ %spec.select, %B30 ]
  store i32 %max_value.0.lcssa, i32* %retptr, align 4
  ret i32 0
}

define i8* @"_ZN7cpython8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([15 x i8], [15 x i8]* @.const.array_max_impl, i64 0, i64 0), i64 2, i64 2, i8** nonnull %.5, i8** nonnull %.6)
  %.8 = icmp eq i32 %.7, 0
  %.22 = alloca { i8*, i8*, i64, i64, i32*, [1 x i64], [1 x i64] }, align 8
  %0 = bitcast { i8*, i8*, i64, i64, i32*, [1 x i64], [1 x i64] }* %.22 to i8*
  call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %0, i8 0, i64 56, i1 false)
  br i1 %.8, label %entry.if, label %entry.endif, !prof !4

entry.if:                                         ; preds = %entry.endif.endif.endif.thread, %entry.endif.endif.endif.endif.endif.if, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.12 = load i8*, i8** @"_ZN08NumbaEnv8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx", align 8
  %.17 = icmp eq i8* %.12, null
  br i1 %.17, label %entry.endif.if, label %entry.endif.endif, !prof !4

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.21 = load i8*, i8** %.5, align 8
  %.25 = bitcast { i8*, i8*, i64, i64, i32*, [1 x i64], [1 x i64] }* %.22 to i8*
  %1 = bitcast { i8*, i8*, i64, i64, i32*, [1 x i64], [1 x i64] }* %.22 to i8*
  call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %1, i8 0, i64 56, i1 false)
  %.26 = call i32 @NRT_adapt_ndarray_from_python(i8* %.21, i8* nonnull %.25)
  %2 = bitcast { i8*, i8*, i64, i64, i32*, [1 x i64], [1 x i64] }* %.22 to i8*
  %sunkaddr = getelementptr i8, i8* %2, i64 24
  %3 = bitcast i8* %sunkaddr to i64*
  %.30 = load i64, i64* %3, align 8
  %.31 = icmp ne i64 %.30, 4
  %.32 = icmp ne i32 %.26, 0
  %.33 = or i1 %.32, %.31
  br i1 %.33, label %entry.endif.endif.endif.thread, label %entry.endif.endif.endif.endif, !prof !4

entry.endif.endif.endif.thread:                   ; preds = %entry.endif.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_TypeError, i8* getelementptr inbounds ([89 x i8], [89 x i8]* @".const.can't unbox array from PyObject into native value.  The object maybe of a different type", i64 0, i64 0))
  br label %entry.if

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif
  %4 = bitcast { i8*, i8*, i64, i64, i32*, [1 x i64], [1 x i64] }* %.22 to i8**
  %.37.fca.0.load = load i8*, i8** %4, align 8
  %5 = bitcast { i8*, i8*, i64, i64, i32*, [1 x i64], [1 x i64] }* %.22 to i8*
  %sunkaddr59 = getelementptr i8, i8* %5, i64 32
  %6 = bitcast i8* %sunkaddr59 to i32**
  %.37.fca.4.load = load i32*, i32** %6, align 8
  %.44 = load i8*, i8** %.6, align 8
  %.47 = call i8* @PyNumber_Long(i8* %.44)
  %.48 = icmp eq i8* %.47, null
  br i1 %.48, label %entry.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.if, !prof !4

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.50 = call i64 @PyLong_AsLongLong(i8* nonnull %.47)
  call void @Py_DecRef(i8* nonnull %.47)
  %phitmp = add i64 %.50, -1
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif, %entry.endif.endif.endif.endif.if
  %.45.0 = phi i64 [ %phitmp, %entry.endif.endif.endif.endif.if ], [ -1, %entry.endif.endif.endif.endif ]
  %.55 = call i8* @PyErr_Occurred()
  %.56 = icmp eq i8* %.55, null
  br i1 %.56, label %entry.endif.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.endif.if, !prof !5

entry.endif.endif.endif.endif.endif.if:           ; preds = %entry.endif.endif.endif.endif.endif
  call void @NRT_decref(i8* %.37.fca.0.load)
  br label %entry.if

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.90.i = load i32, i32* %.37.fca.4.load, align 4, !noalias !6
  %.158.i = icmp sgt i64 %.45.0, 0
  br i1 %.158.i, label %B30.i.preheader, label %"_ZN8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx.exit"

B30.i.preheader:                                  ; preds = %entry.endif.endif.endif.endif.endif.endif
  %min.iters.check = icmp ult i64 %.45.0, 32
  br i1 %min.iters.check, label %B30.i.preheader24, label %vector.ph

vector.ph:                                        ; preds = %B30.i.preheader
  %n.vec = and i64 %.45.0, -32
  %ind.end = or i64 %n.vec, 1
  %minmax.ident.splatinsert = insertelement <8 x i32> undef, i32 %.90.i, i32 0
  %minmax.ident.splat = shufflevector <8 x i32> %minmax.ident.splatinsert, <8 x i32> undef, <8 x i32> zeroinitializer
  %7 = add i64 %n.vec, -32
  %8 = lshr exact i64 %7, 5
  %9 = add nuw nsw i64 %8, 1
  %xtraiter = and i64 %9, 1
  %10 = icmp eq i64 %7, 0
  br i1 %10, label %middle.block.unr-lcssa, label %vector.ph.new

vector.ph.new:                                    ; preds = %vector.ph
  %11 = add i64 %xtraiter, -1
  %12 = sub i64 %9, 1
  %13 = sub i64 %11, %12
  br label %vector.body

vector.body:                                      ; preds = %vector.body, %vector.ph.new
  %lsr.iv56 = phi i64 [ %lsr.iv.next57, %vector.body ], [ %13, %vector.ph.new ]
  %lsr.iv = phi i64 [ %lsr.iv.next, %vector.body ], [ 1, %vector.ph.new ]
  %vec.phi = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %26, %vector.body ]
  %vec.phi3 = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %27, %vector.body ]
  %vec.phi4 = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %28, %vector.body ]
  %vec.phi5 = phi <8 x i32> [ %minmax.ident.splat, %vector.ph.new ], [ %29, %vector.body ]
  %scevgep45 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep4546 = bitcast i32* %scevgep45 to <8 x i32>*
  %wide.load = load <8 x i32>, <8 x i32>* %scevgep4546, align 4, !noalias !6
  %scevgep53 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep5354 = bitcast i32* %scevgep53 to <8 x i32>*
  %scevgep55 = getelementptr <8 x i32>, <8 x i32>* %scevgep5354, i64 1
  %wide.load9 = load <8 x i32>, <8 x i32>* %scevgep55, align 4, !noalias !6
  %scevgep50 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep5051 = bitcast i32* %scevgep50 to <8 x i32>*
  %scevgep52 = getelementptr <8 x i32>, <8 x i32>* %scevgep5051, i64 2
  %wide.load10 = load <8 x i32>, <8 x i32>* %scevgep52, align 4, !noalias !6
  %scevgep47 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep4748 = bitcast i32* %scevgep47 to <8 x i32>*
  %scevgep49 = getelementptr <8 x i32>, <8 x i32>* %scevgep4748, i64 3
  %wide.load11 = load <8 x i32>, <8 x i32>* %scevgep49, align 4, !noalias !6
  %14 = icmp sgt <8 x i32> %wide.load, %vec.phi
  %15 = icmp sgt <8 x i32> %wide.load9, %vec.phi3
  %16 = icmp sgt <8 x i32> %wide.load10, %vec.phi4
  %17 = icmp sgt <8 x i32> %wide.load11, %vec.phi5
  %18 = select <8 x i1> %14, <8 x i32> %wide.load, <8 x i32> %vec.phi
  %19 = select <8 x i1> %15, <8 x i32> %wide.load9, <8 x i32> %vec.phi3
  %20 = select <8 x i1> %16, <8 x i32> %wide.load10, <8 x i32> %vec.phi4
  %21 = select <8 x i1> %17, <8 x i32> %wide.load11, <8 x i32> %vec.phi5
  %scevgep42 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep4243 = bitcast i32* %scevgep42 to <8 x i32>*
  %scevgep44 = getelementptr <8 x i32>, <8 x i32>* %scevgep4243, i64 4
  %wide.load.1 = load <8 x i32>, <8 x i32>* %scevgep44, align 4, !noalias !6
  %scevgep39 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep3940 = bitcast i32* %scevgep39 to <8 x i32>*
  %scevgep41 = getelementptr <8 x i32>, <8 x i32>* %scevgep3940, i64 5
  %wide.load9.1 = load <8 x i32>, <8 x i32>* %scevgep41, align 4, !noalias !6
  %scevgep36 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep3637 = bitcast i32* %scevgep36 to <8 x i32>*
  %scevgep38 = getelementptr <8 x i32>, <8 x i32>* %scevgep3637, i64 6
  %wide.load10.1 = load <8 x i32>, <8 x i32>* %scevgep38, align 4, !noalias !6
  %scevgep33 = getelementptr i32, i32* %.37.fca.4.load, i64 %lsr.iv
  %scevgep3334 = bitcast i32* %scevgep33 to <8 x i32>*
  %scevgep35 = getelementptr <8 x i32>, <8 x i32>* %scevgep3334, i64 7
  %wide.load11.1 = load <8 x i32>, <8 x i32>* %scevgep35, align 4, !noalias !6
  %22 = icmp sgt <8 x i32> %wide.load.1, %18
  %23 = icmp sgt <8 x i32> %wide.load9.1, %19
  %24 = icmp sgt <8 x i32> %wide.load10.1, %20
  %25 = icmp sgt <8 x i32> %wide.load11.1, %21
  %26 = select <8 x i1> %22, <8 x i32> %wide.load.1, <8 x i32> %18
  %27 = select <8 x i1> %23, <8 x i32> %wide.load9.1, <8 x i32> %19
  %28 = select <8 x i1> %24, <8 x i32> %wide.load10.1, <8 x i32> %20
  %29 = select <8 x i1> %25, <8 x i32> %wide.load11.1, <8 x i32> %21
  %lsr.iv.next = add i64 %lsr.iv, 64
  %lsr.iv.next57 = add i64 %lsr.iv56, 2
  %niter.ncmp.1 = icmp eq i64 %lsr.iv.next57, 0
  br i1 %niter.ncmp.1, label %middle.block.unr-lcssa, label %vector.body, !llvm.loop !9

middle.block.unr-lcssa:                           ; preds = %vector.body, %vector.ph
  %.lcssa27.ph = phi <8 x i32> [ undef, %vector.ph ], [ %26, %vector.body ]
  %.lcssa26.ph = phi <8 x i32> [ undef, %vector.ph ], [ %27, %vector.body ]
  %.lcssa25.ph = phi <8 x i32> [ undef, %vector.ph ], [ %28, %vector.body ]
  %.lcssa.ph = phi <8 x i32> [ undef, %vector.ph ], [ %29, %vector.body ]
  %index.unr = phi i64 [ 1, %vector.ph ], [ %lsr.iv.next, %vector.body ]
  %vec.phi.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %26, %vector.body ]
  %vec.phi3.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %27, %vector.body ]
  %vec.phi4.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %28, %vector.body ]
  %vec.phi5.unr = phi <8 x i32> [ %minmax.ident.splat, %vector.ph ], [ %29, %vector.body ]
  %lcmp.mod = icmp eq i64 %xtraiter, 0
  br i1 %lcmp.mod, label %middle.block, label %vector.body.epil

vector.body.epil:                                 ; preds = %middle.block.unr-lcssa
  %30 = getelementptr i32, i32* %.37.fca.4.load, i64 %index.unr
  %31 = bitcast i32* %30 to <8 x i32>*
  %wide.load.epil = load <8 x i32>, <8 x i32>* %31, align 4, !noalias !6
  %32 = getelementptr i32, i32* %30, i64 8
  %33 = bitcast i32* %32 to <8 x i32>*
  %wide.load9.epil = load <8 x i32>, <8 x i32>* %33, align 4, !noalias !6
  %34 = getelementptr i32, i32* %30, i64 16
  %35 = bitcast i32* %34 to <8 x i32>*
  %wide.load10.epil = load <8 x i32>, <8 x i32>* %35, align 4, !noalias !6
  %36 = getelementptr i32, i32* %30, i64 24
  %37 = bitcast i32* %36 to <8 x i32>*
  %wide.load11.epil = load <8 x i32>, <8 x i32>* %37, align 4, !noalias !6
  %38 = icmp sgt <8 x i32> %wide.load11.epil, %vec.phi5.unr
  %39 = select <8 x i1> %38, <8 x i32> %wide.load11.epil, <8 x i32> %vec.phi5.unr
  %40 = icmp sgt <8 x i32> %wide.load10.epil, %vec.phi4.unr
  %41 = select <8 x i1> %40, <8 x i32> %wide.load10.epil, <8 x i32> %vec.phi4.unr
  %42 = icmp sgt <8 x i32> %wide.load9.epil, %vec.phi3.unr
  %43 = select <8 x i1> %42, <8 x i32> %wide.load9.epil, <8 x i32> %vec.phi3.unr
  %44 = icmp sgt <8 x i32> %wide.load.epil, %vec.phi.unr
  %45 = select <8 x i1> %44, <8 x i32> %wide.load.epil, <8 x i32> %vec.phi.unr
  br label %middle.block

middle.block:                                     ; preds = %middle.block.unr-lcssa, %vector.body.epil
  %.lcssa27 = phi <8 x i32> [ %.lcssa27.ph, %middle.block.unr-lcssa ], [ %45, %vector.body.epil ]
  %.lcssa26 = phi <8 x i32> [ %.lcssa26.ph, %middle.block.unr-lcssa ], [ %43, %vector.body.epil ]
  %.lcssa25 = phi <8 x i32> [ %.lcssa25.ph, %middle.block.unr-lcssa ], [ %41, %vector.body.epil ]
  %.lcssa = phi <8 x i32> [ %.lcssa.ph, %middle.block.unr-lcssa ], [ %39, %vector.body.epil ]
  %rdx.minmax.cmp = icmp sgt <8 x i32> %.lcssa27, %.lcssa26
  %rdx.minmax.select = select <8 x i1> %rdx.minmax.cmp, <8 x i32> %.lcssa27, <8 x i32> %.lcssa26
  %rdx.minmax.cmp12 = icmp sgt <8 x i32> %rdx.minmax.select, %.lcssa25
  %rdx.minmax.select13 = select <8 x i1> %rdx.minmax.cmp12, <8 x i32> %rdx.minmax.select, <8 x i32> %.lcssa25
  %rdx.minmax.cmp14 = icmp sgt <8 x i32> %rdx.minmax.select13, %.lcssa
  %rdx.minmax.select15 = select <8 x i1> %rdx.minmax.cmp14, <8 x i32> %rdx.minmax.select13, <8 x i32> %.lcssa
  %rdx.shuf = shufflevector <8 x i32> %rdx.minmax.select15, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp16 = icmp sgt <8 x i32> %rdx.minmax.select15, %rdx.shuf
  %rdx.minmax.select17 = select <8 x i1> %rdx.minmax.cmp16, <8 x i32> %rdx.minmax.select15, <8 x i32> %rdx.shuf
  %rdx.shuf18 = shufflevector <8 x i32> %rdx.minmax.select17, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp19 = icmp sgt <8 x i32> %rdx.minmax.select17, %rdx.shuf18
  %rdx.minmax.select20 = select <8 x i1> %rdx.minmax.cmp19, <8 x i32> %rdx.minmax.select17, <8 x i32> %rdx.shuf18
  %rdx.shuf21 = shufflevector <8 x i32> %rdx.minmax.select20, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp22 = icmp sgt <8 x i32> %rdx.minmax.select20, %rdx.shuf21
  %rdx.minmax.select23 = select <8 x i1> %rdx.minmax.cmp22, <8 x i32> %rdx.minmax.select20, <8 x i32> %rdx.shuf21
  %46 = extractelement <8 x i32> %rdx.minmax.select23, i32 0
  %cmp.n = icmp eq i64 %.45.0, %n.vec
  br i1 %cmp.n, label %"_ZN8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx.exit", label %B30.i.preheader24

B30.i.preheader24:                                ; preds = %middle.block, %B30.i.preheader
  %max_value.07.i.ph = phi i32 [ %.90.i, %B30.i.preheader ], [ %46, %middle.block ]
  %.144.05.i.ph = phi i64 [ 1, %B30.i.preheader ], [ %ind.end, %middle.block ]
  %47 = add i64 %.45.0, 1
  br label %B30.i

B30.i:                                            ; preds = %B30.i.preheader24, %B30.i
  %max_value.07.i = phi i32 [ %spec.select.i, %B30.i ], [ %max_value.07.i.ph, %B30.i.preheader24 ]
  %.144.05.i = phi i64 [ %.223.i, %B30.i ], [ %.144.05.i.ph, %B30.i.preheader24 ]
  %.223.i = add nuw i64 %.144.05.i, 1
  %scevgep = getelementptr i32, i32* %.37.fca.4.load, i64 %.144.05.i
  %.285.i = load i32, i32* %scevgep, align 4, !noalias !6
  %.291.i = icmp sgt i32 %.285.i, %max_value.07.i
  %spec.select.i = select i1 %.291.i, i32 %.285.i, i32 %max_value.07.i
  %exitcond = icmp eq i64 %47, %.223.i
  br i1 %exitcond, label %"_ZN8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx.exit", label %B30.i, !llvm.loop !10

"_ZN8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx.exit": ; preds = %B30.i, %middle.block, %entry.endif.endif.endif.endif.endif.endif
  %max_value.0.lcssa.i = phi i32 [ %.90.i, %entry.endif.endif.endif.endif.endif.endif ], [ %46, %middle.block ], [ %spec.select.i, %B30.i ]
  call void @NRT_decref(i8* %.37.fca.0.load)
  %.84 = sext i32 %max_value.0.lcssa.i to i64
  %.87 = call i8* @PyLong_FromLongLong(i64 %.84)
  ret i8* %.87
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i32 @NRT_adapt_ndarray_from_python(i8* nocapture, i8* nocapture) local_unnamed_addr

declare i8* @PyNumber_Long(i8*) local_unnamed_addr

declare i64 @PyLong_AsLongLong(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyLong_FromLongLong(i64) local_unnamed_addr

; Function Attrs: noinline
define linkonce_odr void @NRT_decref(i8* %.1) local_unnamed_addr #1 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !4

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !4

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: argmemonly nounwind
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1) #2

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #3

attributes #0 = { norecurse nounwind }
attributes #1 = { noinline }
attributes #2 = { argmemonly nounwind }
attributes #3 = { nounwind }

!0 = distinct !{!0, !1}
!1 = !{!"llvm.loop.isvectorized", i32 1}
!2 = distinct !{!2, !3, !1}
!3 = !{!"llvm.loop.unroll.runtime.disable"}
!4 = !{!"branch_weights", i32 1, i32 99}
!5 = !{!"branch_weights", i32 99, i32 1}
!6 = !{!7}
!7 = distinct !{!7, !8, !"_ZN8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx: %retptr"}
!8 = distinct !{!8, !"_ZN8__main__18array_max_impl$241E5ArrayIiLi1E1C7mutable7alignedEx"}
!9 = distinct !{!9, !1}
!10 = distinct !{!10, !3, !1}
```

</details>

When called with a `float32` or `float64` in numba this fails to vectorize:

<details>

```llvm
; ModuleID = 'array_max_impl'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"

@"_ZN08NumbaEnv8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx" = common local_unnamed_addr global i8* null
@.const.array_max_impl = internal constant [15 x i8] c"array_max_impl\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@PyExc_TypeError = external global i8
@".const.can't unbox array from PyObject into native value.  The object maybe of a different type" = internal constant [89 x i8] c"can't unbox array from PyObject into native value.  The object maybe of a different type\00"

; Function Attrs: norecurse nounwind
define i32 @"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx"(double* noalias nocapture %retptr, { i8*, i32 }** noalias nocapture readnone %excinfo, i8* nocapture readnone %arg.arr.0, i8* nocapture readnone %arg.arr.1, i64 %arg.arr.2, i64 %arg.arr.3, double* nocapture readonly %arg.arr.4, i64 %arg.arr.5.0, i64 %arg.arr.6.0, i64 %arg.n) local_unnamed_addr #0 {
entry:
  %.90 = load double, double* %arg.arr.4, align 8
  %.157 = add i64 %arg.n, -1
  %.158 = icmp sgt i64 %.157, 0
  br i1 %.158, label %B30.preheader, label %B54

B30.preheader:                                    ; preds = %entry
  %0 = add i64 %arg.n, -2
  %xtraiter = and i64 %.157, 7
  %1 = icmp ult i64 %0, 7
  br i1 %1, label %B54.loopexit.unr-lcssa, label %B30.preheader.new

B30.preheader.new:                                ; preds = %B30.preheader
  %2 = sub i64 %arg.n, %xtraiter
  br label %B30

B30:                                              ; preds = %B30, %B30.preheader.new
  %max_value.06 = phi double [ %.90, %B30.preheader.new ], [ %max_value.1.7, %B30 ]
  %.144.04 = phi i64 [ 1, %B30.preheader.new ], [ %.223.7, %B30 ]
  %scevgep23 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %.285 = load double, double* %scevgep23, align 8
  %.291 = fcmp fast ogt double %.285, %max_value.06
  %max_value.1 = select i1 %.291, double %.285, double %max_value.06
  %scevgep21 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %scevgep22 = getelementptr double, double* %scevgep21, i64 1
  %.285.1 = load double, double* %scevgep22, align 8
  %.291.1 = fcmp fast ogt double %.285.1, %max_value.1
  %max_value.1.1 = select i1 %.291.1, double %.285.1, double %max_value.1
  %scevgep19 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %scevgep20 = getelementptr double, double* %scevgep19, i64 2
  %.285.2 = load double, double* %scevgep20, align 8
  %.291.2 = fcmp fast ogt double %.285.2, %max_value.1.1
  %max_value.1.2 = select i1 %.291.2, double %.285.2, double %max_value.1.1
  %scevgep17 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %scevgep18 = getelementptr double, double* %scevgep17, i64 3
  %.285.3 = load double, double* %scevgep18, align 8
  %.291.3 = fcmp fast ogt double %.285.3, %max_value.1.2
  %max_value.1.3 = select i1 %.291.3, double %.285.3, double %max_value.1.2
  %scevgep15 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %scevgep16 = getelementptr double, double* %scevgep15, i64 4
  %.285.4 = load double, double* %scevgep16, align 8
  %.291.4 = fcmp fast ogt double %.285.4, %max_value.1.3
  %max_value.1.4 = select i1 %.291.4, double %.285.4, double %max_value.1.3
  %scevgep13 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %scevgep14 = getelementptr double, double* %scevgep13, i64 5
  %.285.5 = load double, double* %scevgep14, align 8
  %.291.5 = fcmp fast ogt double %.285.5, %max_value.1.4
  %max_value.1.5 = select i1 %.291.5, double %.285.5, double %max_value.1.4
  %scevgep11 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %scevgep12 = getelementptr double, double* %scevgep11, i64 6
  %.285.6 = load double, double* %scevgep12, align 8
  %.291.6 = fcmp fast ogt double %.285.6, %max_value.1.5
  %max_value.1.6 = select i1 %.291.6, double %.285.6, double %max_value.1.5
  %.223.7 = add i64 %.144.04, 8
  %scevgep9 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %scevgep10 = getelementptr double, double* %scevgep9, i64 7
  %.285.7 = load double, double* %scevgep10, align 8
  %.291.7 = fcmp fast ogt double %.285.7, %max_value.1.6
  %max_value.1.7 = select i1 %.291.7, double %.285.7, double %max_value.1.6
  %niter.ncmp.7 = icmp eq i64 %2, %.223.7
  br i1 %niter.ncmp.7, label %B54.loopexit.unr-lcssa, label %B30

B54.loopexit.unr-lcssa:                           ; preds = %B30, %B30.preheader
  %max_value.1.lcssa.ph = phi double [ undef, %B30.preheader ], [ %max_value.1.7, %B30 ]
  %max_value.06.unr = phi double [ %.90, %B30.preheader ], [ %max_value.1.7, %B30 ]
  %.144.04.unr = phi i64 [ 1, %B30.preheader ], [ %.223.7, %B30 ]
  %lcmp.mod = icmp eq i64 %xtraiter, 0
  br i1 %lcmp.mod, label %B54, label %B30.epil.preheader

B30.epil.preheader:                               ; preds = %B54.loopexit.unr-lcssa
  %scevgep = getelementptr double, double* %arg.arr.4, i64 %.144.04.unr
  br label %B30.epil

B30.epil:                                         ; preds = %B30.epil.preheader, %B30.epil
  %lsr.iv = phi i64 [ 0, %B30.epil.preheader ], [ %lsr.iv.next, %B30.epil ]
  %max_value.06.epil = phi double [ %max_value.1.epil, %B30.epil ], [ %max_value.06.unr, %B30.epil.preheader ]
  %scevgep8 = getelementptr double, double* %scevgep, i64 %lsr.iv
  %.285.epil = load double, double* %scevgep8, align 8
  %.291.epil = fcmp fast ogt double %.285.epil, %max_value.06.epil
  %max_value.1.epil = select i1 %.291.epil, double %.285.epil, double %max_value.06.epil
  %lsr.iv.next = add nuw nsw i64 %lsr.iv, 1
  %epil.iter.cmp = icmp eq i64 %xtraiter, %lsr.iv.next
  br i1 %epil.iter.cmp, label %B54, label %B30.epil, !llvm.loop !0

B54:                                              ; preds = %B30.epil, %B54.loopexit.unr-lcssa, %entry
  %max_value.0.lcssa = phi double [ %.90, %entry ], [ %max_value.1.lcssa.ph, %B54.loopexit.unr-lcssa ], [ %max_value.1.epil, %B30.epil ]
  store double %max_value.0.lcssa, double* %retptr, align 8
  ret i32 0
}

define i8* @"_ZN7cpython8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([15 x i8], [15 x i8]* @.const.array_max_impl, i64 0, i64 0), i64 2, i64 2, i8** nonnull %.5, i8** nonnull %.6)
  %.8 = icmp eq i32 %.7, 0
  %.22 = alloca { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }, align 8
  %0 = bitcast { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22 to i8*
  call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %0, i8 0, i64 56, i1 false)
  br i1 %.8, label %entry.if, label %entry.endif, !prof !2

entry.if:                                         ; preds = %entry.endif.endif.endif.thread, %entry.endif.endif.endif.endif.endif.if, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.12 = load i8*, i8** @"_ZN08NumbaEnv8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx", align 8
  %.17 = icmp eq i8* %.12, null
  br i1 %.17, label %entry.endif.if, label %entry.endif.endif, !prof !2

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.21 = load i8*, i8** %.5, align 8
  %.25 = bitcast { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22 to i8*
  %1 = bitcast { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22 to i8*
  call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %1, i8 0, i64 56, i1 false)
  %.26 = call i32 @NRT_adapt_ndarray_from_python(i8* %.21, i8* nonnull %.25)
  %2 = bitcast { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22 to i8*
  %sunkaddr = getelementptr i8, i8* %2, i64 24
  %3 = bitcast i8* %sunkaddr to i64*
  %.30 = load i64, i64* %3, align 8
  %.31 = icmp ne i64 %.30, 8
  %.32 = icmp ne i32 %.26, 0
  %.33 = or i1 %.32, %.31
  br i1 %.33, label %entry.endif.endif.endif.thread, label %entry.endif.endif.endif.endif, !prof !2

entry.endif.endif.endif.thread:                   ; preds = %entry.endif.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_TypeError, i8* getelementptr inbounds ([89 x i8], [89 x i8]* @".const.can't unbox array from PyObject into native value.  The object maybe of a different type", i64 0, i64 0))
  br label %entry.if

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif
  %4 = bitcast { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22 to i8**
  %.37.fca.0.load = load i8*, i8** %4, align 8
  %5 = bitcast { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22 to i8*
  %sunkaddr24 = getelementptr i8, i8* %5, i64 32
  %6 = bitcast i8* %sunkaddr24 to double**
  %.37.fca.4.load = load double*, double** %6, align 8
  %.44 = load i8*, i8** %.6, align 8
  %.47 = call i8* @PyNumber_Long(i8* %.44)
  %.48 = icmp eq i8* %.47, null
  br i1 %.48, label %entry.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.if, !prof !2

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.50 = call i64 @PyLong_AsLongLong(i8* nonnull %.47)
  call void @Py_DecRef(i8* nonnull %.47)
  %phitmp = add i64 %.50, -1
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif, %entry.endif.endif.endif.endif.if
  %.45.0 = phi i64 [ %phitmp, %entry.endif.endif.endif.endif.if ], [ -1, %entry.endif.endif.endif.endif ]
  %.55 = call i8* @PyErr_Occurred()
  %.56 = icmp eq i8* %.55, null
  br i1 %.56, label %entry.endif.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.endif.if, !prof !3

entry.endif.endif.endif.endif.endif.if:           ; preds = %entry.endif.endif.endif.endif.endif
  call void @NRT_decref(i8* %.37.fca.0.load)
  br label %entry.if

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.90.i = load double, double* %.37.fca.4.load, align 8, !noalias !4
  %.158.i = icmp sgt i64 %.45.0, 0
  br i1 %.158.i, label %B30.i.preheader, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit"

B30.i.preheader:                                  ; preds = %entry.endif.endif.endif.endif.endif.endif
  %7 = add i64 %.45.0, -1
  %xtraiter = and i64 %.45.0, 7
  %8 = icmp ult i64 %7, 7
  br i1 %8, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa", label %B30.i.preheader.new

B30.i.preheader.new:                              ; preds = %B30.i.preheader
  %unroll_iter = sub i64 %.45.0, %xtraiter
  br label %B30.i

B30.i:                                            ; preds = %B30.i, %B30.i.preheader.new
  %lsr.iv5 = phi i64 [ %lsr.iv.next6, %B30.i ], [ 0, %B30.i.preheader.new ]
  %max_value.06.i = phi double [ %.90.i, %B30.i.preheader.new ], [ %max_value.1.i.7, %B30.i ]
  %sunkaddr25 = mul i64 %lsr.iv5, 8
  %9 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr26 = getelementptr i8, i8* %9, i64 %sunkaddr25
  %sunkaddr27 = getelementptr i8, i8* %sunkaddr26, i64 8
  %10 = bitcast i8* %sunkaddr27 to double*
  %.285.i = load double, double* %10, align 8, !noalias !4
  %.291.i = fcmp fast ogt double %.285.i, %max_value.06.i
  %max_value.1.i = select i1 %.291.i, double %.285.i, double %max_value.06.i
  %sunkaddr28 = mul i64 %lsr.iv5, 8
  %11 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr29 = getelementptr i8, i8* %11, i64 %sunkaddr28
  %sunkaddr30 = getelementptr i8, i8* %sunkaddr29, i64 16
  %12 = bitcast i8* %sunkaddr30 to double*
  %.285.i.1 = load double, double* %12, align 8, !noalias !4
  %.291.i.1 = fcmp fast ogt double %.285.i.1, %max_value.1.i
  %max_value.1.i.1 = select i1 %.291.i.1, double %.285.i.1, double %max_value.1.i
  %sunkaddr31 = mul i64 %lsr.iv5, 8
  %13 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr32 = getelementptr i8, i8* %13, i64 %sunkaddr31
  %sunkaddr33 = getelementptr i8, i8* %sunkaddr32, i64 24
  %14 = bitcast i8* %sunkaddr33 to double*
  %.285.i.2 = load double, double* %14, align 8, !noalias !4
  %.291.i.2 = fcmp fast ogt double %.285.i.2, %max_value.1.i.1
  %max_value.1.i.2 = select i1 %.291.i.2, double %.285.i.2, double %max_value.1.i.1
  %sunkaddr34 = mul i64 %lsr.iv5, 8
  %15 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr35 = getelementptr i8, i8* %15, i64 %sunkaddr34
  %sunkaddr36 = getelementptr i8, i8* %sunkaddr35, i64 32
  %16 = bitcast i8* %sunkaddr36 to double*
  %.285.i.3 = load double, double* %16, align 8, !noalias !4
  %.291.i.3 = fcmp fast ogt double %.285.i.3, %max_value.1.i.2
  %max_value.1.i.3 = select i1 %.291.i.3, double %.285.i.3, double %max_value.1.i.2
  %sunkaddr37 = mul i64 %lsr.iv5, 8
  %17 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr38 = getelementptr i8, i8* %17, i64 %sunkaddr37
  %sunkaddr39 = getelementptr i8, i8* %sunkaddr38, i64 40
  %18 = bitcast i8* %sunkaddr39 to double*
  %.285.i.4 = load double, double* %18, align 8, !noalias !4
  %.291.i.4 = fcmp fast ogt double %.285.i.4, %max_value.1.i.3
  %max_value.1.i.4 = select i1 %.291.i.4, double %.285.i.4, double %max_value.1.i.3
  %sunkaddr40 = mul i64 %lsr.iv5, 8
  %19 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr41 = getelementptr i8, i8* %19, i64 %sunkaddr40
  %sunkaddr42 = getelementptr i8, i8* %sunkaddr41, i64 48
  %20 = bitcast i8* %sunkaddr42 to double*
  %.285.i.5 = load double, double* %20, align 8, !noalias !4
  %.291.i.5 = fcmp fast ogt double %.285.i.5, %max_value.1.i.4
  %max_value.1.i.5 = select i1 %.291.i.5, double %.285.i.5, double %max_value.1.i.4
  %sunkaddr43 = mul i64 %lsr.iv5, 8
  %21 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr44 = getelementptr i8, i8* %21, i64 %sunkaddr43
  %sunkaddr45 = getelementptr i8, i8* %sunkaddr44, i64 56
  %22 = bitcast i8* %sunkaddr45 to double*
  %.285.i.6 = load double, double* %22, align 8, !noalias !4
  %.291.i.6 = fcmp fast ogt double %.285.i.6, %max_value.1.i.5
  %max_value.1.i.6 = select i1 %.291.i.6, double %.285.i.6, double %max_value.1.i.5
  %sunkaddr46 = mul i64 %lsr.iv5, 8
  %23 = bitcast double* %.37.fca.4.load to i8*
  %sunkaddr47 = getelementptr i8, i8* %23, i64 %sunkaddr46
  %sunkaddr48 = getelementptr i8, i8* %sunkaddr47, i64 64
  %24 = bitcast i8* %sunkaddr48 to double*
  %.285.i.7 = load double, double* %24, align 8, !noalias !4
  %.291.i.7 = fcmp fast ogt double %.285.i.7, %max_value.1.i.6
  %max_value.1.i.7 = select i1 %.291.i.7, double %.285.i.7, double %max_value.1.i.6
  %lsr.iv.next6 = add i64 %lsr.iv5, 8
  %niter.ncmp.7 = icmp eq i64 %unroll_iter, %lsr.iv.next6
  br i1 %niter.ncmp.7, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit", label %B30.i

"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit": ; preds = %B30.i
  %25 = add i64 %lsr.iv.next6, 1
  br label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa"

"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa": ; preds = %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit", %B30.i.preheader
  %max_value.1.i.lcssa.ph = phi double [ undef, %B30.i.preheader ], [ %max_value.1.i.7, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit" ]
  %max_value.06.i.unr = phi double [ %.90.i, %B30.i.preheader ], [ %max_value.1.i.7, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit" ]
  %.144.04.i.unr = phi i64 [ 1, %B30.i.preheader ], [ %25, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit" ]
  %lcmp.mod = icmp eq i64 %xtraiter, 0
  br i1 %lcmp.mod, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit", label %B30.i.epil.preheader

B30.i.epil.preheader:                             ; preds = %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa"
  %scevgep = getelementptr double, double* %.37.fca.4.load, i64 %.144.04.i.unr
  br label %B30.i.epil

B30.i.epil:                                       ; preds = %B30.i.epil.preheader, %B30.i.epil
  %lsr.iv = phi i64 [ 0, %B30.i.epil.preheader ], [ %lsr.iv.next, %B30.i.epil ]
  %max_value.06.i.epil = phi double [ %max_value.1.i.epil, %B30.i.epil ], [ %max_value.06.i.unr, %B30.i.epil.preheader ]
  %scevgep4 = getelementptr double, double* %scevgep, i64 %lsr.iv
  %.285.i.epil = load double, double* %scevgep4, align 8, !noalias !4
  %.291.i.epil = fcmp fast ogt double %.285.i.epil, %max_value.06.i.epil
  %max_value.1.i.epil = select i1 %.291.i.epil, double %.285.i.epil, double %max_value.06.i.epil
  %lsr.iv.next = add nuw nsw i64 %lsr.iv, 1
  %epil.iter.cmp = icmp eq i64 %xtraiter, %lsr.iv.next
  br i1 %epil.iter.cmp, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit", label %B30.i.epil, !llvm.loop !7

"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit": ; preds = %B30.i.epil, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa", %entry.endif.endif.endif.endif.endif.endif
  %max_value.0.lcssa.i = phi double [ %.90.i, %entry.endif.endif.endif.endif.endif.endif ], [ %max_value.1.i.lcssa.ph, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa" ], [ %max_value.1.i.epil, %B30.i.epil ]
  call void @NRT_decref(i8* %.37.fca.0.load)
  %.84 = call i8* @PyFloat_FromDouble(double %max_value.0.lcssa.i)
  ret i8* %.84
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i32 @NRT_adapt_ndarray_from_python(i8* nocapture, i8* nocapture) local_unnamed_addr

declare i8* @PyNumber_Long(i8*) local_unnamed_addr

declare i64 @PyLong_AsLongLong(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyFloat_FromDouble(double) local_unnamed_addr

; Function Attrs: noinline
define linkonce_odr void @NRT_decref(i8* %.1) local_unnamed_addr #1 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !2

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !2

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: argmemonly nounwind
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1) #2

; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #3

attributes #0 = { norecurse nounwind }
attributes #1 = { noinline }
attributes #2 = { argmemonly nounwind }
attributes #3 = { nounwind }

!0 = distinct !{!0, !1}
!1 = !{!"llvm.loop.unroll.disable"}
!2 = !{!"branch_weights", i32 1, i32 99}
!3 = !{!"branch_weights", i32 99, i32 1}
!4 = !{!5}
!5 = distinct !{!5, !6, !"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx: %retptr"}
!6 = distinct !{!6, !"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx"}
!7 = distinct !{!7, !1}
```

</details>

However, if I run this already optimized output once more through the llvm optimizer with `opt -Ofast -S` , I get back a successfully vectorized loop body. See the following details section:

<details>

```llvm
; ModuleID = 'optimized.ll'
source_filename = "<string>"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"

@"_ZN08NumbaEnv8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx" = common local_unnamed_addr global i8* null
@.const.array_max_impl = internal constant [15 x i8] c"array_max_impl\00"
@PyExc_RuntimeError = external global i8
@".const.missing Environment" = internal constant [20 x i8] c"missing Environment\00"
@PyExc_TypeError = external global i8
@".const.can't unbox array from PyObject into native value.  The object maybe of a different type" = internal constant [89 x i8] c"can't unbox array from PyObject into native value.  The object maybe of a different type\00"

; Function Attrs: nofree norecurse nounwind
define i32 @"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx"(double* noalias nocapture %retptr, { i8*, i32 }** noalias nocapture readnone %excinfo, i8* nocapture readnone %arg.arr.0, i8* nocapture readnone %arg.arr.1, i64 %arg.arr.2, i64 %arg.arr.3, double* nocapture readonly %arg.arr.4, i64 %arg.arr.5.0, i64 %arg.arr.6.0, i64 %arg.n) local_unnamed_addr #0 {
entry:
  %.90 = load double, double* %arg.arr.4, align 8
  %.157 = add i64 %arg.n, -1
  %.158 = icmp sgt i64 %.157, 0
  br i1 %.158, label %B30.preheader, label %B54

B30.preheader:                                    ; preds = %entry
  %0 = add i64 %arg.n, -2
  %xtraiter = and i64 %.157, 7
  %1 = icmp ult i64 %0, 7
  br i1 %1, label %B54.loopexit.unr-lcssa, label %B30.preheader.new

B30.preheader.new:                                ; preds = %B30.preheader
  %2 = sub nuw i64 %arg.n, %xtraiter
  br label %B30

B30:                                              ; preds = %B30, %B30.preheader.new
  %max_value.06 = phi double [ %.90, %B30.preheader.new ], [ %op.extra, %B30 ]
  %.144.04 = phi i64 [ 1, %B30.preheader.new ], [ %.223.7, %B30 ]
  %scevgep23 = getelementptr double, double* %arg.arr.4, i64 %.144.04
  %3 = bitcast double* %scevgep23 to <8 x double>*
  %4 = load <8 x double>, <8 x double>* %3, align 8
  %.223.7 = add i64 %.144.04, 8
  %rdx.shuf = shufflevector <8 x double> %4, <8 x double> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp = fcmp fast ogt <8 x double> %4, %rdx.shuf
  %rdx.minmax.select = select <8 x i1> %rdx.minmax.cmp, <8 x double> %4, <8 x double> %rdx.shuf
  %rdx.shuf1 = shufflevector <8 x double> %rdx.minmax.select, <8 x double> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp2 = fcmp fast ogt <8 x double> %rdx.minmax.select, %rdx.shuf1
  %rdx.minmax.select3 = select <8 x i1> %rdx.minmax.cmp2, <8 x double> %rdx.minmax.select, <8 x double> %rdx.shuf1
  %rdx.shuf4 = shufflevector <8 x double> %rdx.minmax.select3, <8 x double> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp5 = fcmp fast ogt <8 x double> %rdx.minmax.select3, %rdx.shuf4
  %rdx.minmax.select6 = select <8 x i1> %rdx.minmax.cmp5, <8 x double> %rdx.minmax.select3, <8 x double> %rdx.shuf4
  %5 = extractelement <8 x double> %rdx.minmax.select6, i32 0
  %6 = fcmp fast ogt double %5, %max_value.06
  %op.extra = select i1 %6, double %5, double %max_value.06
  %niter.ncmp.7 = icmp eq i64 %2, %.223.7
  br i1 %niter.ncmp.7, label %B54.loopexit.unr-lcssa, label %B30

B54.loopexit.unr-lcssa:                           ; preds = %B30, %B30.preheader
  %max_value.1.lcssa.ph = phi double [ undef, %B30.preheader ], [ %op.extra, %B30 ]
  %max_value.06.unr = phi double [ %.90, %B30.preheader ], [ %op.extra, %B30 ]
  %.144.04.unr = phi i64 [ 1, %B30.preheader ], [ %2, %B30 ]
  %lcmp.mod = icmp eq i64 %xtraiter, 0
  br i1 %lcmp.mod, label %B54, label %B30.epil.preheader

B30.epil.preheader:                               ; preds = %B54.loopexit.unr-lcssa
  %scevgep = getelementptr double, double* %arg.arr.4, i64 %.144.04.unr
  br label %B30.epil

B30.epil:                                         ; preds = %B30.epil, %B30.epil.preheader
  %lsr.iv = phi i64 [ 0, %B30.epil.preheader ], [ %lsr.iv.next, %B30.epil ]
  %max_value.06.epil = phi double [ %max_value.06.unr, %B30.epil.preheader ], [ %max_value.1.epil, %B30.epil ]
  %scevgep8 = getelementptr double, double* %scevgep, i64 %lsr.iv
  %.285.epil = load double, double* %scevgep8, align 8
  %.291.epil = fcmp fast ogt double %.285.epil, %max_value.06.epil
  %max_value.1.epil = select i1 %.291.epil, double %.285.epil, double %max_value.06.epil
  %lsr.iv.next = add nuw nsw i64 %lsr.iv, 1
  %epil.iter.cmp = icmp eq i64 %xtraiter, %lsr.iv.next
  br i1 %epil.iter.cmp, label %B54, label %B30.epil, !llvm.loop !0

B54:                                              ; preds = %B30.epil, %B54.loopexit.unr-lcssa, %entry
  %max_value.0.lcssa = phi double [ %.90, %entry ], [ %max_value.1.lcssa.ph, %B54.loopexit.unr-lcssa ], [ %max_value.1.epil, %B30.epil ]
  store double %max_value.0.lcssa, double* %retptr, align 8
  ret i32 0
}

define i8* @"_ZN7cpython8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx"(i8* nocapture readnone %py_closure, i8* %py_args, i8* nocapture readnone %py_kws) local_unnamed_addr {
entry:
  %.5 = alloca i8*, align 8
  %.6 = alloca i8*, align 8
  %.7 = call i32 (i8*, i8*, i64, i64, ...) @PyArg_UnpackTuple(i8* %py_args, i8* getelementptr inbounds ([15 x i8], [15 x i8]* @.const.array_max_impl, i64 0, i64 0), i64 2, i64 2, i8** nonnull %.5, i8** nonnull %.6)
  %.8 = icmp eq i32 %.7, 0
  %.22 = alloca { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }, align 8
  %0 = bitcast { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22 to i8*
  call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %0, i8 0, i64 56, i1 false)
  br i1 %.8, label %entry.if, label %entry.endif, !prof !2

entry.if:                                         ; preds = %entry.endif.endif.endif.endif.endif.if, %entry.endif.endif.endif.thread, %entry
  ret i8* null

entry.endif:                                      ; preds = %entry
  %.12 = load i8*, i8** @"_ZN08NumbaEnv8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx", align 8
  %.17 = icmp eq i8* %.12, null
  br i1 %.17, label %entry.endif.if, label %entry.endif.endif, !prof !2

entry.endif.if:                                   ; preds = %entry.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_RuntimeError, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @".const.missing Environment", i64 0, i64 0))
  ret i8* null

entry.endif.endif:                                ; preds = %entry.endif
  %.21 = load i8*, i8** %.5, align 8
  call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %0, i8 0, i64 56, i1 false)
  %.26 = call i32 @NRT_adapt_ndarray_from_python(i8* %.21, i8* nonnull %0)
  %sunkaddr = getelementptr inbounds { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }, { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22, i64 0, i32 3
  %.30 = load i64, i64* %sunkaddr, align 8
  %.31 = icmp ne i64 %.30, 8
  %.32 = icmp ne i32 %.26, 0
  %.33 = or i1 %.32, %.31
  br i1 %.33, label %entry.endif.endif.endif.thread, label %entry.endif.endif.endif.endif, !prof !2

entry.endif.endif.endif.thread:                   ; preds = %entry.endif.endif
  call void @PyErr_SetString(i8* nonnull @PyExc_TypeError, i8* getelementptr inbounds ([89 x i8], [89 x i8]* @".const.can't unbox array from PyObject into native value.  The object maybe of a different type", i64 0, i64 0))
  br label %entry.if

entry.endif.endif.endif.endif:                    ; preds = %entry.endif.endif
  %1 = getelementptr inbounds { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }, { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22, i64 0, i32 0
  %.37.fca.0.load = load i8*, i8** %1, align 8
  %sunkaddr24 = getelementptr inbounds { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }, { i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64] }* %.22, i64 0, i32 4
  %.37.fca.4.load = load double*, double** %sunkaddr24, align 8
  %.44 = load i8*, i8** %.6, align 8
  %.47 = call i8* @PyNumber_Long(i8* %.44)
  %.48 = icmp eq i8* %.47, null
  br i1 %.48, label %entry.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.if, !prof !2

entry.endif.endif.endif.endif.if:                 ; preds = %entry.endif.endif.endif.endif
  %.50 = call i64 @PyLong_AsLongLong(i8* nonnull %.47)
  call void @Py_DecRef(i8* nonnull %.47)
  %phitmp = add i64 %.50, -1
  br label %entry.endif.endif.endif.endif.endif

entry.endif.endif.endif.endif.endif:              ; preds = %entry.endif.endif.endif.endif.if, %entry.endif.endif.endif.endif
  %.45.0 = phi i64 [ %phitmp, %entry.endif.endif.endif.endif.if ], [ -1, %entry.endif.endif.endif.endif ]
  %.55 = call i8* @PyErr_Occurred()
  %.56 = icmp eq i8* %.55, null
  br i1 %.56, label %entry.endif.endif.endif.endif.endif.endif, label %entry.endif.endif.endif.endif.endif.if, !prof !3

entry.endif.endif.endif.endif.endif.if:           ; preds = %entry.endif.endif.endif.endif.endif
  call void @NRT_decref(i8* %.37.fca.0.load)
  br label %entry.if

entry.endif.endif.endif.endif.endif.endif:        ; preds = %entry.endif.endif.endif.endif.endif
  %.90.i = load double, double* %.37.fca.4.load, align 8, !noalias !4
  %.158.i = icmp sgt i64 %.45.0, 0
  br i1 %.158.i, label %B30.i.preheader, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit"

B30.i.preheader:                                  ; preds = %entry.endif.endif.endif.endif.endif.endif
  %2 = add nsw i64 %.45.0, -1
  %xtraiter = and i64 %.45.0, 7
  %3 = icmp ult i64 %2, 7
  br i1 %3, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa", label %B30.i.preheader.new

B30.i.preheader.new:                              ; preds = %B30.i.preheader
  %unroll_iter = sub nuw nsw i64 %.45.0, %xtraiter
  %sunkaddr261 = getelementptr double, double* %.37.fca.4.load, i64 1
  br label %B30.i

B30.i:                                            ; preds = %B30.i, %B30.i.preheader.new
  %lsr.iv5 = phi i64 [ %lsr.iv.next6, %B30.i ], [ 0, %B30.i.preheader.new ]
  %max_value.06.i = phi double [ %op.extra, %B30.i ], [ %.90.i, %B30.i.preheader.new ]
  %sunkaddr272 = getelementptr double, double* %sunkaddr261, i64 %lsr.iv5
  %4 = bitcast double* %sunkaddr272 to <8 x double>*
  %5 = load <8 x double>, <8 x double>* %4, align 8, !noalias !4
  %rdx.shuf = shufflevector <8 x double> %5, <8 x double> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp = fcmp fast ogt <8 x double> %5, %rdx.shuf
  %rdx.minmax.select = select <8 x i1> %rdx.minmax.cmp, <8 x double> %5, <8 x double> %rdx.shuf
  %rdx.shuf10 = shufflevector <8 x double> %rdx.minmax.select, <8 x double> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp11 = fcmp fast ogt <8 x double> %rdx.minmax.select, %rdx.shuf10
  %rdx.minmax.select12 = select <8 x i1> %rdx.minmax.cmp11, <8 x double> %rdx.minmax.select, <8 x double> %rdx.shuf10
  %rdx.shuf13 = shufflevector <8 x double> %rdx.minmax.select12, <8 x double> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  %rdx.minmax.cmp14 = fcmp fast ogt <8 x double> %rdx.minmax.select12, %rdx.shuf13
  %rdx.minmax.select15 = select <8 x i1> %rdx.minmax.cmp14, <8 x double> %rdx.minmax.select12, <8 x double> %rdx.shuf13
  %6 = extractelement <8 x double> %rdx.minmax.select15, i32 0
  %7 = fcmp fast ogt double %6, %max_value.06.i
  %op.extra = select i1 %7, double %6, double %max_value.06.i
  %lsr.iv.next6 = add i64 %lsr.iv5, 8
  %niter.ncmp.7 = icmp eq i64 %unroll_iter, %lsr.iv.next6
  br i1 %niter.ncmp.7, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit", label %B30.i

"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit": ; preds = %B30.i
  %8 = add i64 %lsr.iv5, 9
  br label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa"

"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa": ; preds = %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit", %B30.i.preheader
  %max_value.1.i.lcssa.ph = phi double [ undef, %B30.i.preheader ], [ %op.extra, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit" ]
  %max_value.06.i.unr = phi double [ %.90.i, %B30.i.preheader ], [ %op.extra, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit" ]
  %.144.04.i.unr = phi i64 [ 1, %B30.i.preheader ], [ %8, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa.loopexit" ]
  %lcmp.mod = icmp eq i64 %xtraiter, 0
  br i1 %lcmp.mod, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit", label %B30.i.epil.preheader

B30.i.epil.preheader:                             ; preds = %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa"
  %scevgep = getelementptr double, double* %.37.fca.4.load, i64 %.144.04.i.unr
  br label %B30.i.epil

B30.i.epil:                                       ; preds = %B30.i.epil, %B30.i.epil.preheader
  %lsr.iv = phi i64 [ 0, %B30.i.epil.preheader ], [ %lsr.iv.next, %B30.i.epil ]
  %max_value.06.i.epil = phi double [ %max_value.06.i.unr, %B30.i.epil.preheader ], [ %max_value.1.i.epil, %B30.i.epil ]
  %scevgep4 = getelementptr double, double* %scevgep, i64 %lsr.iv
  %.285.i.epil = load double, double* %scevgep4, align 8, !noalias !4
  %.291.i.epil = fcmp fast ogt double %.285.i.epil, %max_value.06.i.epil
  %max_value.1.i.epil = select i1 %.291.i.epil, double %.285.i.epil, double %max_value.06.i.epil
  %lsr.iv.next = add nuw nsw i64 %lsr.iv, 1
  %epil.iter.cmp = icmp eq i64 %xtraiter, %lsr.iv.next
  br i1 %epil.iter.cmp, label %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit", label %B30.i.epil, !llvm.loop !7

"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit": ; preds = %B30.i.epil, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa", %entry.endif.endif.endif.endif.endif.endif
  %max_value.0.lcssa.i = phi double [ %.90.i, %entry.endif.endif.endif.endif.endif.endif ], [ %max_value.1.i.lcssa.ph, %"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx.exit.loopexit.unr-lcssa" ], [ %max_value.1.i.epil, %B30.i.epil ]
  call void @NRT_decref(i8* %.37.fca.0.load)
  %.84 = call i8* @PyFloat_FromDouble(double %max_value.0.lcssa.i)
  ret i8* %.84
}

declare i32 @PyArg_UnpackTuple(i8*, i8*, i64, i64, ...) local_unnamed_addr

declare void @PyErr_SetString(i8*, i8*) local_unnamed_addr

declare i32 @NRT_adapt_ndarray_from_python(i8* nocapture, i8* nocapture) local_unnamed_addr

declare i8* @PyNumber_Long(i8*) local_unnamed_addr

declare i64 @PyLong_AsLongLong(i8*) local_unnamed_addr

declare void @Py_DecRef(i8*) local_unnamed_addr

declare i8* @PyErr_Occurred() local_unnamed_addr

declare i8* @PyFloat_FromDouble(double) local_unnamed_addr

; Function Attrs: noinline
define linkonce_odr void @NRT_decref(i8* %.1) local_unnamed_addr #1 {
.3:
  %.4 = icmp eq i8* %.1, null
  br i1 %.4, label %.3.if, label %.3.endif, !prof !2

.3.if:                                            ; preds = %.3.endif, %.3
  ret void

.3.endif:                                         ; preds = %.3
  fence release
  %.8 = bitcast i8* %.1 to i64*
  %.4.i = atomicrmw sub i64* %.8, i64 1 monotonic
  %.10 = icmp eq i64 %.4.i, 1
  br i1 %.10, label %.3.endif.if, label %.3.if, !prof !2

.3.endif.if:                                      ; preds = %.3.endif
  fence acquire
  tail call void @NRT_MemInfo_call_dtor(i8* nonnull %.1)
  ret void
}

declare void @NRT_MemInfo_call_dtor(i8*) local_unnamed_addr

; Function Attrs: argmemonly nounwind
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1 immarg) #2

attributes #0 = { nofree norecurse nounwind }
attributes #1 = { noinline }
attributes #2 = { argmemonly nounwind }

!0 = distinct !{!0, !1}
!1 = !{!"llvm.loop.unroll.disable"}
!2 = !{!"branch_weights", i32 1, i32 99}
!3 = !{!"branch_weights", i32 99, i32 1}
!4 = !{!5}
!5 = distinct !{!5, !6, !"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx: %retptr"}
!6 = distinct !{!6, !"_ZN8__main__18array_max_impl$241E5ArrayIdLi1E1C7mutable7alignedEx"}
!7 = distinct !{!7, !1}
```
</details>
user: ARF1
labels: llvm: LLVM related issues
performance: performance related issue
issue_5052: state: open
title: Factor common infrastructure between CUDA simulator and hardware target implementations
body: As the simulator evolves along with the CUDA target, there is an increase in logic / coda duplication between the two - e.g. as suggested in https://github.com/numba/numba/pull/4975/files#r364319727, and particularly around the operation of real and fake device arrays.

It would be good to factor this shared and duplicated logic into a common, or shared module, from which both the real target and the simulator are composed.
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_5045: state: open
title: Looplift fail on if-branch after for-loop in py3.8
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version (0.47) of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

See affected test in https://github.com/numba/numba/pull/5029.

Reproducer:
```python
from numba import jit
import logging
logging.basicConfig(level=logging.DEBUG)

def bar(x):
    return x

@jit
def foo(x):
    h = 0.
    for k in range(x):
        h = h + k

    bar(x)
    if x:
        h = h - bar(x)
    return h


foo(1)
foo.inspect_types()
```

The log will show:

```log
INFO:numba.transforms:finding looplift candidates
DEBUG:numba.transforms:top-level loop: Loop(entries={14}, exits={40}, header=16, body={16, 28})
DEBUG:numba.transforms:same_exit_point=False ({52, 53})
```
Loop lifting fails on the `same_exit_point` requirement.

user: sklam
labels: performance: performance related issue
issue_5043: state: open
title: @overload cannot replace previously defined or built-in implementations
body: Let's assume I would like to `@overload` (or replace) an already existing implementation of a numpy function. In this case, the `@overload` function seems to get called (i.e. it produces errors e.g. if the returned function signature does not match) but the new implementation never gets used:

(Tested with numba 0.47)


```python
import numpy as np
from numba import  njit
import numba.types as types
from numba.extending import overload, overload_method, register_jitable

@overload(np.sum)
@overload_method(types.Array, "sum")
def array_sum(arr):
    def array_sum_impl(arr):
        print('Test1')
        return 0.0
    return array_sum_impl

@njit
def test_sum(arr):
    return np.sum(arr)

arr = np.arange(10)
print(test_sum(arr))
```

Prints `45.0` rather than `0.0`.

----
Similarly for previously defined implementations that are not built-in:

```python
import numpy as np
from numba import  njit
import numba.types as types
from numba.extending import overload, overload_method, register_jitable

@overload(np.apply_along_axis)
def array_sum(arr):
    def array_sum_impl(arr):
        return 0.0
    return array_sum_impl

@njit
def test_sum(arr):
    return np.apply_along_axis(arr)

arr = np.arange(10)
print(test_sum(arr))

@overload(np.apply_along_axis)
def array_sum(arr):
    def array_sum_impl(arr):
        return 1.0
    return array_sum_impl

@njit
def test_sum(arr):
    return np.apply_along_axis(arr)
print(test_sum(arr))
```

Prints
```
0.0
0.0
```

rather than 
```
0.0
1.0
```
user: ARF1
issue_5042: state: open
title: Make DummyType type factory for testing
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

From discussion: https://github.com/numba/numba/pull/5018#discussion_r362553658 and [gitter](https://gitter.im/numba/numba-dev?at=5e149642e409da486cdd8185)

There are many duplicated code for making a `Dummy` type for testing extension APIs. We should to unify them all into a type factory.

Find all the `Dummy` types by `grep "class Dummy" numba/tests/*`
user: sklam
labels: good second issue: A good issue for second time contributors
issue_5028: state: open
title: Feature request: line profiler/performance profiler
body: A long and often requested feature for Numba is a JIT'd code performance profiler. The basic idea is to be able to provide feedback to users about which lines of Python source are taking the most time to execute once compiled by Numba's JIT.

This is one way to do it on the CPU:

0. Numba parses Python bytecode to it's own IR (Numba IR).
1. Numba IR has `ir.Loc` entries which correspond to the source lines as encoded    in the byte code.
2. If Numba has `debug=True` set in the `numba.*jit` decorator then the line   numbers appear in LLVM IR as part of the debug metadata and then once compiled as LNS entries in the disassembly of the JIT produced ELF object.
3. Linux [`perf`](https://perf.wiki.kernel.org/index.php/Main_Page) is a tool that can be used to profile execution and works by doing event based sampling (it's a statistical profiler). perf can be run on numba.jit compiled code but the JIT compiled code need to write out a special map to describe which addresses map to which symbol names, this comes from patching LLVM.
4. LLVM needs patching a bit, at present Numba uses MCJIT, applying:
   * https://reviews.llvm.org/D44892
   * https://reviews.llvm.org/D47343

   with minor fixes to get it to compile and then adding the `LLVM_USE_PERF` option to the LLVM build makes it such that `perf` and LLVM know about each other and can cooperate over these map files.
5. llvmlite needs patching a bit so that function attributes can be key-word
6. From 5. frame pointer elimination needs disabling on all Numba compiled functions so that stacks are complete.
7. Once 1-6 are done it's possible to get a reasonably accurate performance annotated disassembly of the JIT ELF that ran following commands similar to those presented here: https://reviews.llvm.org/D44892
8. The problem with the performance record in 7 is that it refers to the JIT ELF which, when disassembled, looks like the (dis)assembly MCJIT produces but is not  exactly the same (there's relocations/optimisations/NOP sleds etc) it also has line number missing (obviously). As a result something is needed to match up the JIT ELF disassembly with the MCJIT assembly to line up the performance information (I did this with [capstone](https://www.capstone-engine.org/) and a custom parser).
9. Once 8. is done there's a map available between:
   `JIT ELF disassembly -> MCJIT (dis)assembly -> LLVM IR -> Numba IR -> Python source.`

   As there's performance information available for the bottom item in the chain it's possible to chase this through the map right up to the Python source. Practically, it makes sense to store this in a dataframe such that e.g. `.groupby(by="linenumber")` can be done to trivially aggregate the performance information.
10. Once 9 is done it just needs presenting reasonably.

I've actually implemented a load of the above locally and have managed to produce something that seems reasonable, here's some simple output from executing a trivial function:

![line_profiler1](https://user-images.githubusercontent.com/907717/71738655-2b2ec180-2e4f-11ea-8466-87a14b677115.png)

This is more complicated output from running numba's `siphash24` replication as needed for it's CPython `__str__.hash()`
![line_profiler2](https://user-images.githubusercontent.com/907717/71739026-359d8b00-2e50-11ea-9437-40d92abea00e.png)
and some level of drill down is possible:
![line_profiler3](https://user-images.githubusercontent.com/907717/71739038-3fbf8980-2e50-11ea-8613-fe0808f8cc55.png)



Level of effort to complete this feature is unknown and potentially quite large as there are numerous dependencies in the R&D chain that should really be done first to make this easier. Namely:
1. Migrate to LLVM latest
2. Migrate from MCJIT to ORCJIT2 as the `perf` support seems considerably more  trodden path for that JIT engine.

There is also quite a lot of scope for work on the UI side too and it will likely be helpful to get input from those with expertise in jupyter notebooks / visualisation in general.


This work is also interlinked with:
 - disassembly and inspection views for Numba compilation stages (and tracking of these with line numbers)
 - CUDA profiling of the same (will open another ticket)
 - Computing code coverage of JIT'd code.
user: stuartarchibald
issue_5026: state: open
title: Typed List sort() struggles key function optional
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the 0.47.0 version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).


This:
```python
from numba import njit
import numpy as np
from numba.typed import List

@njit
def demo_sort_sorted(chars):

    def numba_order(x):
        return 'NUMBA🐍numba⚡'.index(x)

    x = chars[:]
    x.sort(key=numba_order)
    print("sorted key=numba_order:", ''.join(x))

# let's sort a numba.typed.List of characters
input_list = List()
[input_list.append(x) for x in ('m','M','a','N','n','u','⚡','🐍','B','b','U','A')]
demo_sort_sorted(input_list)
```
is a typing error.
```
TypingError: List.item_type cannot be of type OptionalType(int64) i.e. the type 'int64 or None'
```
think it's coming from here: https://github.com/numba/numba/blob/4eb9cf875969ef7f099b292e0c5a8bb852f6fc7f/numba/listobject.py#L1065-L1071

the branch is taken as `KEY` is present, but type still may be `None` or thing as typing doesn't know about the impossibility of a `None` key. I'm not sure right now whether the fix is need in `typed.List` or the `sort()` impl (I think the latter just requires the old-style none-like handling implementing).
user: stuartarchibald
issue_5022: state: open
title: Unhelpful AssertionError when bad arguments passed to cuda.to_device
body: - [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Discovered while looking into #5017, I mistyped some input and got:

```python
In [1]: from numba import cuda                                                                                                                               

In [2]: N = 0                                                                                                                                                

In [3]: a = range(N)                                                                                                                                         

In [4]: arr = cuda.to_device(len(a), 'f')                                                                                                                    
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-4-65af9bf63292> in <module>
----> 1 arr = cuda.to_device(len(a), 'f')

~/numbadev/numba/numba/cuda/cudadrv/devices.py in _require_cuda_context(*args, **kws)
    223     def _require_cuda_context(*args, **kws):
    224         with _runtime.ensure_context():
--> 225             return fn(*args, **kws)
    226 
    227     return _require_cuda_context

~/numbadev/numba/numba/cuda/api.py in to_device(obj, stream, copy, to)
    109     """
    110     if to is None:
--> 111         to, new = devicearray.auto_device(obj, stream=stream, copy=copy)
    112         return to
    113     if copy:

~/numbadev/numba/numba/cuda/cudadrv/devicearray.py in auto_device(obj, stream, copy)
    704             devobj = from_array_like(obj, stream=stream)
    705         if copy:
--> 706             devobj.copy_to_device(obj, stream=stream)
    707         return devobj, True
    708 

~/numbadev/numba/numba/cuda/cudadrv/devices.py in _require_cuda_context(*args, **kws)
    223     def _require_cuda_context(*args, **kws):
    224         with _runtime.ensure_context():
--> 225             return fn(*args, **kws)
    226 
    227     return _require_cuda_context

~/numbadev/numba/numba/cuda/cudadrv/devicearray.py in copy_to_device(self, ary, stream)
    207                 copy=not ary_core.flags['WRITEABLE'])
    208             check_array_compatibility(self_core, ary_core)
--> 209             _driver.host_to_device(self, ary_core, self.alloc_size, stream=stream)
    210 
    211     @devices.require_context

~/numbadev/numba/numba/cuda/cudadrv/driver.py in host_to_device(dst, src, size, stream)
   1892 
   1893     if stream:
-> 1894         assert isinstance(stream, Stream)
   1895         fn = driver.cuMemcpyHtoDAsync
   1896         varargs.append(stream.handle)

AssertionError: 

In [5]:
```
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_5005: state: open
title: @jit is not working for big integers
body: ```
Traceback (most recent call last):
  File "kangaroo256-main.py", line 732, in <module>
    Sp.append(mul_2a(Sp[k]))
  File "kangaroo256-main.py", line 200, in mul_2a
    c = A.x * A.x * invert(A.y+A.y, p)          # 1I,2M,0S
  File "C:\Users\Admin\Anaconda3\lib\site-packages\numba\dispatcher.py", line 351, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\Admin\Anaconda3\lib\site-packages\numba\dispatcher.py", line 318, in error_rewrite
    reraise(type(e), e, None)
  File "C:\Users\Admin\Anaconda3\lib\site-packages\numba\six.py", line 658, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
[1m[1mnon-precise type pyobject[0m
[0m[1m[1] During: typing of argument at kangaroo256-main.py (144)[0m
[1m
File "kangaroo256-main.py", line 144:[0m
[1mdef invert(b, p=modulo):
[1m    u, v = b%p, p
[0m [1m^[0m[0m
```
This error may have been caused by the following argument(s):
- argument 0: Int value is too large: 65341020041517633956166170261014086368942546761318486551877808671514674964848
- argument 1: Int value is too large: 115792089237316195423570985008687907853269984665640564039457584007908834671663

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/dev/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/dev/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
user: BrijeshVadodariya
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_5003: state: open
title: Memory leak when allocating arrays in function in parallel loop
body: I tired to accelerate a numerical simulation using the excellent `nb.prange` for simple parallelization. At its core, my simulation calls a single function (`update` in the code below) many times during each timestep. This function updates the central data array in arbitrary (i.e. hard to predict) locations. I wanted to accelerate the inner loop using `nb.prange` and used a chunked iteration with temporary arrays to avoid the race condition when multiple threads write to the same data array. However, using the simplest implementation, I ran into a memory leak, which I consider a bug.

To illustrate the problem, I attach a working example, where calling `test(parallel)` shows the memory leak. The allocated memory seems to scale linearly with the number `rep` of repetitions. I saw this problem with the following Numba environment on MacOs 10.14.6 using python 3.7:

>version: 0.46.0
>using_svml: False
>threading_layer: tbb
>omp_num_threads: None
>mkl_num_threads: None
>num_threads: 12

If you cannot see the problem on your setup, it might help to increase `rep`, which makes the memory leak for longer on my setup. 

```python
#!/usr/bin/env python3

import numpy as np
import numba as nb


num = 10_000_000
rep = 1000
threads = 5
dim = 10_000


@nb.jit
def update(arr, out, offset=0):
    """ inner update function """
    for i in range(arr.size):
        out[(i + offset) % dim] += arr[i]


@nb.jit
def basic(arr, offset=0):
    """ basic usage of the update function """
    out = np.zeros(dim, np.int64)
    update(arr, out, offset)
    return out
     

@nb.jit(parallel=True)
def race_condition(arr):
    """ naive parallization with race condition """
    out = np.zeros(dim, np.int64)
    size = int(np.ceil(arr.size / threads))
    for i in nb.prange(threads):
        arr_junk = arr[i * size:(i + 1) * size]
        update(arr_junk, out, i * size)
    return out
     

def iter_in_junks(arr):
    """ junked iteration guarding against race condition """
    # get size of a single junk
    res = np.zeros(dim, np.int64)
    size = int(np.ceil(arr.size / threads))
    for i in nb.prange(threads):
        arr_junk = arr[i * size:(i + 1) * size]
        res += basic(arr_junk, i * size)
        
    return res
        
# compile without and with parallel support
single = nb.jit()(iter_in_junks)
parallel = nb.jit(parallel=True)(iter_in_junks)
        
arr = np.arange(num)
expect = basic(arr)
        
def test(func):
    """ test function that repeatably calls func and test result """
    
    @nb.jit
    def inner():
        for i in range(rep):
            res = func(arr)
            if not np.array_equal(res, expect):
                return False
        return True
        
    return inner()
        
# test the different variants
print('Race condition:', test(race_condition))
print('Single thread:', test(single))
print('Multiple threads:', test(parallel))
```


user: david-zwicker
issue_5002: state: open
title: Error model does not effect complex number
body: ```python
from numba import jit
import numpy as np

@jit(error_model='numpy')
def real(x):
    return np.array([1.]) / x

@jit(error_model='numpy')
def complex(x):
    return np.array([1. + 2.j]) / x

print(real(3))
print(real(0.))
print(complex(3))

a = np.array([1. + 2j]) / 0.
print(a)
print(complex(0.)) #  I expect this gives `inf + inf j`
```
user: szsdk
labels: good second issue: A good issue for second time contributors
issue_5000: state: open
title: Closure inliner not handling keyword args correctly
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the ~latest released~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
This:
```python
from numba import njit
import numpy as np

@njit
def pennsylvania6():

    def foo(a, b, kw1=False):
        print(a, b, kw1)

    foo(1, 2, "x")
    foo(1, 2, kw1="y")
    foo(1, 2, kw1=True)


pennsylvania6()
print('-' * 80)
pennsylvania6.py_func()
```
produces:
```
1 2 x                                                                                                                           
1 2 False                                                                                                                       
1 2 False                                                                                                                       
--------------------------------------------------------------------------------                                                
1 2 x                                                                                                                           
1 2 y                                                                                                                           
1 2 True                                                                                                                        
```

suspect there's something wrong with the inliner/a missing guard against this.

user: stuartarchibald
labels: bug - miscompile: Bugs: miscompile
issue_4989: state: open
title: lldb support
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request
`gdb` support works fine but it seems like getting `gdb` on OSX can be tricky https://stackoverflow.com/questions/59412358/debugging-numba-in-macos, OSX often has `lldb`  available and it'd be nice to support this. I think most of the `gdb` machinery can be reused/refactored for reuse and then it'll just be a question of writing some command files to get `lldb` into a known state for use in debugging.
user: stuartarchibald
issue_4988: state: open
title: bug: range accepts float
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the ~latest released~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This shouldn't make it through typing but it does
```python
from numba import njit
import numpy as np

@njit
def foo(x):
    for i in range(x):
        print(i)

foo(12.3)
```
`range()` should not accept a floating point value. This types as:
```
----------------------------------IR DUMP: foo----------------------------------
label 0:
    x = arg(0, name=x)                       ['x']
    jump 2                                   []
label 2:
    $4load_global.0 = global(range: <class 'range'>) ['$4load_global.0']
    $8call_function.2 = call $4load_global.0(x, func=$4load_global.0, args=[Var(x, range_issue.py:6)], kws=(), vararg=None) ['$4load_global.0', '$8call_function.2', 'x']
    del x                                    []
    del $4load_global.0                      []
    $10get_iter.3 = getiter(value=$8call_function.2) ['$10get_iter.3', '$8call_function.2']
    del $8call_function.2                    []
    $phi12.0 = $10get_iter.3                 ['$10get_iter.3', '$phi12.0']
    del $10get_iter.3                        []
    jump 12                                  []
label 12:
    $12for_iter.1 = iternext(value=$phi12.0) ['$12for_iter.1', '$phi12.0']
    $12for_iter.2 = pair_first(value=$12for_iter.1) ['$12for_iter.1', '$12for_iter.2']
    $12for_iter.3 = pair_second(value=$12for_iter.1) ['$12for_iter.1', '$12for_iter.3']
    del $12for_iter.1                        []
    $phi14.1 = $12for_iter.2                 ['$12for_iter.2', '$phi14.1']
    del $12for_iter.2                        []
    branch $12for_iter.3, 14, 26             ['$12for_iter.3']
label 14:
    del $12for_iter.3                        []
    i = $phi14.1                             ['$phi14.1', 'i']
    del $phi14.1                             []
    $16load_global.2 = global(print: <built-in function print>) ['$16load_global.2']
    del $16load_global.2                     []
    print(i)                                 ['i']
    del i                                    []
    $20call_function.4 = const(NoneType, None) ['$20call_function.4']
    del $20call_function.4                   []
    jump 12                                  []
label 26:
    del $phi14.1                             []
    del $phi12.0                             []
    del $12for_iter.3                        []
    jump 28                                  []
label 28:
    $const28.0 = const(NoneType, None)       ['$const28.0']
    $30return_value.1 = cast(value=$const28.0) ['$30return_value.1', '$const28.0']
    del $const28.0                           []
    return $30return_value.1                 ['$30return_value.1']

-----------------------------------propagate------------------------------------
---- type variables ----
[$10get_iter.3 := range_iter_int32,
 $12for_iter.1 := pair<int32, bool>,
 $12for_iter.2 := int32,
 $12for_iter.3 := bool,
 $16load_global.2 := Function(<built-in function print>),
 $20call_function.4 := none,
 $30return_value.1 := none,
 $4load_global.0 := Function(<class 'range'>),
 $8call_function.2 := range_state_int32,
 $const28.0 := none,
 $phi12.0 := range_iter_int32,
 $phi14.1 := int32,
 arg.x := float64,
 i := int32,
 x := float64]
-----------------------------------propagate------------------------------------
---- type variables ----
[$10get_iter.3 := range_iter_int32,
 $12for_iter.1 := pair<int32, bool>,
 $12for_iter.2 := int32,
 $12for_iter.3 := bool,
 $16load_global.2 := Function(<built-in function print>),
 $20call_function.4 := none,
 $30return_value.1 := none,
 $4load_global.0 := Function(<class 'range'>),
 $8call_function.2 := range_state_int32,
 $const28.0 := none,
 $phi12.0 := range_iter_int32,
 $phi14.1 := int32,
 arg.x := float64,
 i := int32,
 x := float64]
---------------------------------Variable types---------------------------------
{'$10get_iter.3': range_iter_int32,
 '$12for_iter.1': pair<int32, bool>,
 '$12for_iter.2': int32,
 '$12for_iter.3': bool,
 '$16load_global.2': Function(<built-in function print>),
 '$20call_function.4': none,
 '$30return_value.1': none,
 '$4load_global.0': Function(<class 'range'>),
 '$8call_function.2': range_state_int32,
 '$const28.0': none,
 '$phi12.0': range_iter_int32,
 '$phi14.1': int32,
 'arg.x': float64,
 'i': int32,
 'x': float64}
----------------------------------Return type-----------------------------------
none
-----------------------------------Call types-----------------------------------
{call $4load_global.0(x, func=$4load_global.0, args=[Var(x, range_issue.py:6)], kws=(), vararg=None): (int32,) -> range_state_int32,
 getiter(value=$8call_function.2): (range_state_int32,) -> range_iter_int32,
 iternext(value=$phi12.0): (range_iter_int32,) -> pair<int32, bool>,
 <numba.ir.Print object at 0x7fb8630b1810>: (int32,) -> none}
```


user: stuartarchibald
issue_4974: state: open
title: Strides of transposes differ between CUDA target and Numpy
body: - [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Spotted whilst working on a fix for #4832 - there is a further deviation from Numpy in the strides of transposes of views. Example:

```python
from numba import cuda
import numpy as np

a = np.arange(120).reshape((10, 12))
a_view = a[::2, ::2]
a_view_t = a_view.T


d_a = cuda.to_device(a)
d_a_view = d_a[::2, ::2]
d_a_view_t = d_a_view.T

h_a_view_t = d_a_view_t.copy_to_host()

print(a_view_t)
print(h_a_view_t)

print(d_a_view.strides)
print(d_a_view_t.strides)

assert np.all(a_view_t == h_a_view_t)
```

prints:

```
[[  0  24  48  72  96]
 [  2  26  50  74  98]
 [  4  28  52  76 100]
 [  6  30  54  78 102]
 [  8  32  56  80 104]
 [ 10  34  58  82 106]]
[[  0  24  48  72  96]
 [  2  26  50  74  98]
 [  4  28  52  76 100]
 [  6  30  54  78 102]
 [  8  32  56  80 104]
 [ 10  34  58  82 106]]
(192, 16)
(40, 8)
```

with no assertion - i.e. the transpose is correctly computed, but the result has different strides to Numpy. This could fall into the "half-bug" category as @stuartarchibald mentioned for #4832 in that it's not necessarily incorrect, but a little surprising. It might be nice as a user to be able to choose whether the transpose kernel will run and create a new array, or whether a new array pointing at the same data with modified strides is returned.
user: gmarkall
labels: CUDA: CUDA related issue/PR
discussion: An issue requiring discussion
issue_4956: state: open
title: Add ability to specify types for lazily compiled function
body: According to http://numba.pydata.org/numba-doc/0.46.0/user/jit.html, Numba will eagerly compile a function if you specify the types explicitly, which it says is "useful if you want fine-grained control over types chosen by the compiler (for example, to use single-precision floats)".

It would be nice if the user could specify the type for a rarely used function that we don't want to be eagerly compiled. In my case, it's to specify that when the function is called it should use the indicated types, yet compiling it slows down import times for everyone, which is painful because most people don't use this function.

Can users have a way to specify types without triggering eager compilation? 

(CC: @brendancol)
user: jbednar
issue_4952: state: open
title: CUDA guvectorize target does not copy back modified input arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

This is either a documentation bug or an implementation bug - it would be nice to think of it as an implementation bug, because it would be good to support this use case in the CUDA target.

If I write a gufunc that writes to the inputs, then the writes to the input are reflected in the array when using the CPU target. However, on the CUDA target, writes to inputs are "lost". In the example below, writing to `pos` on CUDA does not affect the `pos_cuda` array after execution finishes: 

```python
import numpy as np
from numba import guvectorize, float32

@guvectorize([(float32[:], float32[:])], '()->()')
def init_cpu(pos, accel):
    pos[0] = 6.5
    accel[0] = 4.2 * pos[0]

@guvectorize([(float32[:], float32[:])], '()->()', target='cuda')
def init_cuda(pos, accel):
    pos[0] = 6.5
    accel[0] = 4.2 * pos[0]

pos_cpu = np.zeros( shape=(50, 50), dtype=np.float32 )
pos_cuda = np.zeros( shape=(50, 50), dtype=np.float32 )

accel_cpu = init_cpu(pos_cpu)
accel_cuda = init_cuda(pos_cuda)

print(pos_cpu)
print(pos_cuda)

print(accel_cpu)
print(accel_cuda)

assert np.isclose(accel_cpu, accel_cuda).all()
assert np.isclose(pos_cpu, pos_cuda).all()
```

The output is:

```
[[6.5 6.5 6.5 ... 6.5 6.5 6.5]
 [6.5 6.5 6.5 ... 6.5 6.5 6.5]
 [6.5 6.5 6.5 ... 6.5 6.5 6.5]
 ...
 [6.5 6.5 6.5 ... 6.5 6.5 6.5]
 [6.5 6.5 6.5 ... 6.5 6.5 6.5]
 [6.5 6.5 6.5 ... 6.5 6.5 6.5]]
[[0. 0. 0. ... 0. 0. 0.]
 [0. 0. 0. ... 0. 0. 0.]
 [0. 0. 0. ... 0. 0. 0.]
 ...
 [0. 0. 0. ... 0. 0. 0.]
 [0. 0. 0. ... 0. 0. 0.]
 [0. 0. 0. ... 0. 0. 0.]]
[[27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 ...
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]]
[[27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 ...
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]
 [27.3 27.3 27.3 ... 27.3 27.3 27.3]]
Traceback (most recent call last):
  File "bug.py", line 27, in <module>
    assert np.isclose(pos_cpu, pos_cuda).all()
AssertionError
```

Additionally I tried writing the layout string as `(),()`, in case that would make the CUDA target get the idea (noting that the reference manual states that you should write a signature that way if there are no outputs, implying that it is legal to write to inputs: http://numba.pydata.org/numba-doc/latest/reference/jit-compilation.html#numba.guvectorize). However, I then found I ran into #2011 - only one output is supported on CUDA at the moment:

```
Traceback (most recent call last):
  File "bug.py", line 9, in <module>
    @guvectorize([(float32[:], float32[:])], '(),()', target='cuda')
  File "/home/nfs/gmarkall/numbadev/numba/numba/npyufunc/decorators.py", line 177, in wrap
    guvec = GUVectorize(func, signature, **kws)
  File "/home/nfs/gmarkall/numbadev/numba/numba/npyufunc/decorators.py", line 50, in __new__
    targetoptions=kws)
  File "/home/nfs/gmarkall/numbadev/numba/numba/npyufunc/deviceufunc.py", line 446, in __init__
    assert len(self.outputsig) == 1, "only support 1 output"
AssertionError: only support 1 output
```

Possible ways to resolve this:

1. Document that you can't write to inputs on CUDA, and raise an error when compiling a function that writes to an input for the CUDA target.
2. Detect when inputs are written to on the CUDA target, and copy them back.

I'd prefer to fix this with option 2, but I have yet to scope out how difficult that would be (it would probably fix #2011 in conjunction as well).
user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_4951: state: open
title: Slow performance with numpy.record data type (only when passed as parameter)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba.
- [X] I have included below a minimal working reproducer.

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

The performance with a `numpy.record` data type when it was passed as a parameter to a jit function is slow compared to passing a single-element `numpy.recarray` to a jit function and unpacking and using the `numpy.record` within the function. 

[Reproducer as gist](https://gist.github.com/ARF1/e261d6d68b8c4e0a468ce115b67f3973):

```
In [1]:

from collections import namedtuple
import numba as nb
import numba.types as types

In [2]:

@nb.jit('int64(int64)')
def ask(a):
    return a + 1

Numpy recordarray (1d):
In [3]:

import numpy as np

state_dtype = np.dtype([
    ('a', np.int64),
    ('b', np.int64),
])

state = np.rec.array([(1, 2)], dtype=state_dtype)

In [4]:

@nb.jit
def test(state):
    state = state[0]
    b = 0
    for i in range(10000000000):
        b += ask(state.a)
    return b

In [5]:

%%timeit -n200 -r10000 test(state)
test(state)

The slowest run took 44.24 times longer than the fastest. This could mean that an intermediate result is being cached.
667 ns ± 531 ns per loop (mean ± std. dev. of 10000 runs, 200 loops each)

Numpy record:
In [6]:

import numpy as np

state_dtype = np.dtype([
    ('a', np.int64),
    ('b', np.int64),
])

state = np.rec.array([(1, 2)], dtype=state_dtype)
state = state[0]

In [7]:

@nb.jit
def test(state):
    b = 0
    for i in range(10000000000):
        b += ask(state.a)
    return b

In [8]:

%%timeit -n200 -r10000 test(state)
test(state)

The slowest run took 12.18 times longer than the fastest. This could mean that an intermediate result is being cached.
1.98 µs ± 1.09 µs per loop (mean ± std. dev. of 10000 runs, 200 loops each)

In [9]:

@nb.jit
def test(state):
    a = state.a
    b = 0
    for i in range(10000000000):
        b += ask(a)
    return b

In [10]:

%%timeit -n200 -r10000 test(state)
test(state)

The slowest run took 11.28 times longer than the fastest. This could mean that an intermediate result is being cached.
1.93 µs ± 916 ns per loop (mean ± std. dev. of 10000 runs, 200 loops each)


```
user: ARF1
labels: performance: performance related issue
issue_4949: state: open
title: `float64()` ctor doesn't support `1d` arrays.
body: I was asked to leave this here, so I'm doing it in appreciation of the work you are putting in to make python better. Basically, I'm trying add three numbers: 

x_fd and x_fd_eps: elements of a float 64 np.array.
eps: a float64

* Adding all three fails because of typing error
* Converting x_fd and x_fd_eps fails like below 

Traceback (most recent call last):
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/targets/base.py", line 691, in cast
    impl = self._casts.find((fromty, toty))
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/targets/base.py", line 50, in find
    out = self._find(sig)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/targets/base.py", line 59, in _find
    raise NotImplementedError(self, sig)
NotImplementedError: (<numba.targets.base.OverloadSelector object at 0x7f4f4b25e5d0>, (array(float64, 1d, C), float64))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/errors.py", line 717, in new_error_context
    yield
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 260, in lower_block
    self.lower_inst(inst)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 303, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 465, in lower_assign
    return self.lower_expr(ty, value)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 927, in lower_expr
    res = self.lower_call(resty, expr)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 719, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 898, in _lower_call_normal
    res = impl(self.builder, argvals, self.loc)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/targets/base.py", line 1132, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/targets/base.py", line 1157, in wrapper
    return fn(*args, **kwargs)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/targets/builtins.py", line 278, in number_constructor
    return context.cast(builder, val, valty, sig.return_type)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/targets/base.py", line 695, in cast
    "Cannot cast %s to %s: %s" % (fromty, toty, val))
NotImplementedError: Cannot cast array(float64, 1d, C) to float64: %".1937" = load {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}, {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}* %"$128.28"

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "src/santa.py", line 262, in <module>
    if __name__ == '__main__': main()
  File "src/santa.py", line 103, in main
    AC_grad = accounting_cost_gradient(X, fam_size, GRAD_EPS)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/dispatcher.py", line 420, in _compile_for_args
    raise e
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/dispatcher.py", line 768, in compile
    cres = self._compiler.compile(args, return_type)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler.py", line 528, in compile_extra
    return pipeline.compile_extra(func)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler.py", line 326, in compile_extra
    return self._compile_bytecode()
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler.py", line 385, in _compile_bytecode
    return self._compile_core()
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler.py", line 365, in _compile_core
    raise e
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler.py", line 356, in _compile_core
    pm.run(self.state)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler_machinery.py", line 328, in run
    raise patched_exception
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler_machinery.py", line 319, in run
    self._runPass(idx, pass_inst, state)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler_machinery.py", line 281, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/compiler_machinery.py", line 268, in check
    mangled = func(compiler_state)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/typed_passes.py", line 380, in run_pass
    NativeLowering().run_pass(state) # TODO: Pull this out into the pipeline
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/typed_passes.py", line 325, in run_pass
    lower.lower()
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 179, in lower
    self.lower_normal_function(self.fndesc)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 220, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 245, in lower_function_body
    self.lower_block(block)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/lowering.py", line 260, in lower_block
    self.lower_inst(inst)
  File "/home/xxxy/anaconda3/lib/python3.7/contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/errors.py", line 725, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/media/xxxy/data/celeba/env/lib/python3.7/site-packages/numba/six.py", line 669, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast array(float64, 1d, C) to float64: %".1937" = load {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}, {i8*, i8*, i64, i64, double*, [1 x i64], [1 x i64]}* %"$128.28"

File "src/santa.py", line 197:
def accounting_cost_gradient(X, fam_size, eps):
    <source elided>

            x_fd = np.float64((d_occ - 125)/400 * d_occ ** (0.5 + np.absolute(d_occ - d_prior_occ)/50))
            ^

[1] During: lowering "$128.29 = call $128.10($128.28, func=$128.10, args=[Var($128.28, src/santa.py (197))], kws=(), vararg=None)" at src/santa.py (197)

-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.46.0.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!


user: LearnDude
issue_4948: state: open
title: typed-list fails to refine via setitem
body: According to the Python API `__setitem__` can be used to add an initial element to a list:

```python
In [1]: l = list()

In [2]: l[0:] = (1, )

In [3]: l
Out[3]: [1]
```

This implies that the Numba typed-list could and should be refined in such cases. However the following reproducer demonstrates that this isn't the case:

```python
from numba import njit
from numba.typed import List


@njit
def foo():
    l = List()
    l[0:] = (1,)
    return l


foo()
```

Here is the stack trace:

```
💥 zsh» python  foo/foo80.py
Traceback (most recent call last):
  File "/Users/vhaenel/git/numba/numba/typeinfer.py", line 148, in propagate
    constraint(typeinfer)
  File "/Users/vhaenel/git/numba/numba/typeinfer.py", line 689, in __call__
    sig = typeinfer.context.resolve_setitem(targetty, idxty, valty)
  File "/Users/vhaenel/git/numba/numba/typing/context.py", line 328, in resolve_setitem
    sig = fnty.get_call_type(self, (target, index, value), {})
  File "/Users/vhaenel/git/numba/numba/types/functions.py", line 150, in get_call_type
    failures.raise_error()
  File "/Users/vhaenel/git/numba/numba/types/functions.py", line 79, in raise_error
    raise errors.TypingError(self.format())
numba.errors.TypingError: Invalid use of Function(<built-in function setitem>) with argument(s) of type(s): (ListType[undefined, mutable=True], slice<a:b>, tuple(int64 x 1))
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type ListType[undefined, mutable=True]
[1] During: typing of argument at /Users/vhaenel/git/numba/numba/listobject.py (735)

File "numba/listobject.py", line 735:
        def impl_slice(l, index, item):
            <source elided>
            # special case "a[i:j] = a", need to copy first
            if l == item:
            ^

    raised from /Users/vhaenel/git/numba/numba/typeinfer.py:956
In definition 5:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type ListType[undefined, mutable=True]
[1] During: typing of argument at /Users/vhaenel/git/numba/numba/listobject.py (735)

File "numba/listobject.py", line 735:
        def impl_slice(l, index, item):
            <source elided>
            # special case "a[i:j] = a", need to copy first
            if l == item:
            ^

    raised from /Users/vhaenel/git/numba/numba/typeinfer.py:956
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of staticsetitem at foo/foo80.py (8)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "foo/foo80.py", line 12, in <module>
    foo()
  File "/Users/vhaenel/git/numba/numba/dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/Users/vhaenel/git/numba/numba/dispatcher.py", line 342, in error_rewrite
    raise e
  File "/Users/vhaenel/git/numba/numba/dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/Users/vhaenel/git/numba/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/vhaenel/git/numba/numba/dispatcher.py", line 788, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/vhaenel/git/numba/numba/dispatcher.py", line 81, in compile
    raise retval
  File "/Users/vhaenel/git/numba/numba/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/Users/vhaenel/git/numba/numba/dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "/Users/vhaenel/git/numba/numba/compiler.py", line 554, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/vhaenel/git/numba/numba/compiler.py", line 339, in compile_extra
    return self._compile_bytecode()
  File "/Users/vhaenel/git/numba/numba/compiler.py", line 400, in _compile_bytecode
    return self._compile_core()
  File "/Users/vhaenel/git/numba/numba/compiler.py", line 379, in _compile_core
    raise e
  File "/Users/vhaenel/git/numba/numba/compiler.py", line 370, in _compile_core
    pm.run(self.state)
  File "/Users/vhaenel/git/numba/numba/compiler_machinery.py", line 331, in run
    raise patched_exception
  File "/Users/vhaenel/git/numba/numba/compiler_machinery.py", line 322, in run
    self._runPass(idx, pass_inst, state)
  File "/Users/vhaenel/git/numba/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/vhaenel/git/numba/numba/compiler_machinery.py", line 281, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/Users/vhaenel/git/numba/numba/compiler_machinery.py", line 268, in check
    mangled = func(compiler_state)
  File "/Users/vhaenel/git/numba/numba/typed_passes.py", line 94, in run_pass
    state.locals)
  File "/Users/vhaenel/git/numba/numba/typed_passes.py", line 66, in type_inference_stage
    infer.propagate()
  File "/Users/vhaenel/git/numba/numba/typeinfer.py", line 956, in propagate
    raise errors[0]
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function setitem>) with argument(s) of type(s): (ListType[undefined, mutable=True], slice<a:b>, tuple(int64 x 1))
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type ListType[undefined, mutable=True]
[1] During: typing of argument at /Users/vhaenel/git/numba/numba/listobject.py (735)

File "numba/listobject.py", line 735:
        def impl_slice(l, index, item):
            <source elided>
            # special case "a[i:j] = a", need to copy first
            if l == item:
            ^

    raised from /Users/vhaenel/git/numba/numba/typeinfer.py:956
In definition 5:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type ListType[undefined, mutable=True]
[1] During: typing of argument at /Users/vhaenel/git/numba/numba/listobject.py (735)

File "numba/listobject.py", line 735:
        def impl_slice(l, index, item):
            <source elided>
            # special case "a[i:j] = a", need to copy first
            if l == item:
            ^

    raised from /Users/vhaenel/git/numba/numba/typeinfer.py:956
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of staticsetitem at foo/foo80.py (8)

File "foo/foo80.py", line 8:
def foo():
    <source elided>
    l = List()
    l[0:] = (1,)
```
user: esc
issue_4945: state: open
title: implement `ndarray.flat.__getitem__(slice)`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

From gitter: https://gitter.im/numba/numba?at=5df10b072cc1b31e34fee7dc
Related https://github.com/numba/numba/issues/3120

Feature request for `ndarray.flat.__getitem__(slice)`

Associated lowering code: https://github.com/numba/numba/blob/3ee055633680c924e940df8212fd8d4b0d057a4b/numba/targets/arrayobj.py#L3134-L3207





user: sklam
issue_4913: state: open
title: feature request, 3 argument form of `pow` built in
body: ```
from numba import njit, jit
from tqdm import tqdm
fib=[1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040,1346269,2178309,3524578,5702887,9227465,14930352,24157817,39088169,63245986,102334155,165580141,267914296,433494437,701408733,1134903170,1836311903,2971215073,4807526976,7778742049,12586269025,20365011074,32951280099,53316291173,86267571272,139583862445,225851433717,365435296162,591286729879,956722026041,1548008755920,2504730781961,4052739537881,6557470319842,10610209857723,17167680177565,27777890035288,44945570212853,72723460248141,117669030460994,190392490709135,308061521170129,498454011879264,806515533049393,1304969544928657,2111485077978050,3416454622906707,5527939700884757,8944394323791464,14472334024676221,23416728348467685,37889062373143906,61305790721611591,99194853094755497,160500643816367088,259695496911122585,420196140727489673,679891637638612258,1100087778366101931,1779979416004714189]
m=1000000007
t=0
@njit(fastmath=True)
def s(f):
	tt=0
	x=0
	if f//9!=0:
		tt=45
		x=9
	for i in range(1,f//9):
		tt=(tt+((45*pow(10,i,m))%m+(x*9)%m)%m)%m
		x=x*10+9
	xx=f%9
	tt=(tt+(((xx*(xx+1))/2)%m+(x*xx)%m)%m)%m
	# print(tt)
	return tt

for f in tqdm(fib):
	t=(t+s(f))%m
print(t)
```
Here is a full traceback while running this code :

```
Traceback (most recent call last):
  File "test.py", line 23, in <module>
    t=(t+s(f))%m
  File "C:\Users\Neel\Anaconda3\envs\env_1\lib\site-packages\numba\dispatcher.py", line 401, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\Neel\Anaconda3\envs\env_1\lib\site-packages\numba\dispatcher.py", line 344, in error_rewrite
    reraise(type(e), e, None)
  File "C:\Users\Neel\Anaconda3\envs\env_1\lib\site-packages\numba\six.py", line 668, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function pow>) with argument(s) of type(s): (Literal[int](10), int64, Literal[int](1000000007))
Known signatures:
 * (float64, int64) -> float64
 * (float64, uint64) -> float64
 * (float32, float32) -> float32
 * (float64, float64) -> float64
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<built-in function pow>)
[2] During: typing of call at test.py (15)


File "test.py", line 15:
def s(f):
    <source elided>
        for i in range(1,f//9):
                tt=(tt+((45*math.pow(10,i,m))%m+(x*9)%m)%m)%m
  ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```
I presently have tried njit & jit both with functions pow, numpy.pow and math.pow, none of which work.
user: neel112358
issue_4908: state: open
title: RuntimeError: cannot cache function 'square': no locator available for file
body: When trying to import a numba-cached function from a python egg package, I get the following error message about no cache file locator being found:
```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 656, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 626, in _load_backward_compatible
  File "/home/username/.local/lib/python3.6/site-packages/mytestpackage-1.2.3-py3.6.egg/mytestpackage/mymodule.py", line 3, in <module>
  File "/home/username/.local/lib/python3.6/site-packages/numba/decorators.py", line 194, in wrapper
    disp.enable_caching()
  File "/home/username/.local/lib/python3.6/site-packages/numba/dispatcher.py", line 679, in enable_caching
    self._cache = FunctionCache(self.py_func)
  File "/home/username/.local/lib/python3.6/site-packages/numba/caching.py", line 614, in __init__
    self._impl = self._impl_class(py_func)
  File "/home/username/.local/lib/python3.6/site-packages/numba/caching.py", line 349, in __init__
    "for file %r" % (qualname, source_path))
RuntimeError: cannot cache function 'square': no locator available for file '/home/username/.local/lib/python3.6/site-packages/mytestpackage-1.2.3-py3.6.egg/mytestpackage/mymodule.py'
```

The bug occurs at least with numba versions 0.45.1 and 0.46.1.
The bug appears to be operating system-agnostic.
Exporting a user cache directory does not help: `export NUMBA_CACHE_DIR=/tmp`.
I believe that the various caching file locators fail because they assume that the python files are located in plain directories, when they can in fact be in an egg, for example [here](https://github.com/numba/numba/blob/master/numba/caching.py#L254):
```python
def from_function(cls, py_func, py_file):
    if not (os.path.exists(py_file) or getattr(sys, 'frozen', False)):
        # Perhaps a placeholder (e.g. "<ipython-XXX>")
        # stop function exit if frozen, since it uses a temp placeholder
        return
    self = cls(py_func, py_file)
    try:
        self.ensure_cache_path()
    except OSError:
        # Cannot ensure the cache directory exists or is writable
        return
    return self
```

To produce a minimal package and reproduce this bug, run this code in a shell:

```
echo "UEsDBBQDAAAAADd9fU8AAAAAAAAAAAAAAAAOAAAAbXl0ZXN0cGFja2FnZS9QSwMEFAMAAAAAvXx9TwAAAAAAAAAAAAAAABwAAABteXRlc3RwYWNrYWdlL215dGVzdHBhY2thZ2UvUEsDBAoDAAAAAMVqfU9D34g0AgAAAAIAAAAnAAAAbXl0ZXN0cGFja2FnZS9teXRlc3RwYWNrYWdlL19faW5pdF9fLnB5IApQSwMEFAMAAAgAuXx9TxKRbY9SAAAAUwAAACcAAABteXRlc3RwYWNrYWdlL215dGVzdHBhY2thZ2UvbXltb2R1bGUucHkdxbEKgCAQAND9vuJo0ohmEYI+oi0azE4y0OrywM8vesuL6Tq5YJa0OoDxv89HLKoJRgUz20U3HXrndxomFtKwUcDnFsekqraAH6YinLFiixVeUEsDBBQDAAAIALB8fU9A2V6/YwAAAI0AAAAWAAAAbXl0ZXN0cGFja2FnZS9zZXR1cC5weVWMSwqFMAxF51lF6EihCO857lqkaJSibUoTBXev+Bl4h+dcToiZiyILjIUjCumalXkRvM1NLI4hDV32/ewnEoCLVoDnko/kTNyVRJ+DsZfZqEjg5Myv+TftA9+G+xSr2kINB1BLAQI/AxQDAAAAADd9fU8AAAAAAAAAAAAAAAAOACQAAAAAAAAAEIDtQQAAAABteXRlc3RwYWNrYWdlLwoAIAAAAAAAAQAYAICaOR/DptUBgPSbIcOm1QGAmjkfw6bVAVBLAQI/AxQDAAAAAL18fU8AAAAAAAAAAAAAAAAcACQAAAAAAAAAEIDtQSwAAABteXRlc3RwYWNrYWdlL215dGVzdHBhY2thZ2UvCgAgAAAAAAABABgAgJBTl8Km1QEAizQiw6bVAYCQU5fCptUBUEsBAj8DCgMAAAAAxWp9T0PfiDQCAAAAAgAAACcAJAAAAAAAAAAggKSBZgAAAG15dGVzdHBhY2thZ2UvbXl0ZXN0cGFja2FnZS9fX2luaXRfXy5weQoAIAAAAAAAAQAYAIBuvZ6vptUBAIs0IsOm1QGAbr2er6bVAVBLAQI/AxQDAAAIALl8fU8SkW2PUgAAAFMAAAAnACQAAAAAAAAAIICkga0AAABteXRlc3RwYWNrYWdlL215dGVzdHBhY2thZ2UvbXltb2R1bGUucHkKACAAAAAAAAEAGACA3I6SwqbVAQCLNCLDptUBgNyOksKm1QFQSwECPwMUAwAACACwfH1PQNlev2MAAACNAAAAFgAkAAAAAAAAACCApIFEAQAAbXl0ZXN0cGFja2FnZS9zZXR1cC5weQoAIAAAAAAAAQAYAADebIjCptUBgJVG28Km1QEA3myIwqbVAVBLBQYAAAAABQAFACgCAADbAQAAAAA=" | base64 -d > mytestpackage.zip
unzip mytestpackage.zip
cd mytestpackage
python setup.py install --user
cd /tmp
python -c "import mytestpackage.mymodule"
```

Or alternatively, if you do not trust this base64-encoded zip-file, you can create a package manually. The directory structure is:
```
mytestpackage
├── mytestpackage
│   ├── __init__.py
│   └── mymodule.py
└── setup.py
```
The content of the file `mymodule.py` is:
```python
import numba

@numba.njit("f8(f8)", cache=True)
def square(x):
    return x * x
```
The content of the file `setup.py` is:
```python
from setuptools import setup, find_packages

setup(
    name="mytestpackage",
    version="1.2.3",
    packages=find_packages(),
)
```
The file `__init__.py` is empty.

Often it might be preferable to compile the functions ahead of time during setup with `numba.pycc` if the required features are available (e.g. no `parallel=True` (yet)).

Another workaround is to install the package with `pip install .`, which will not create an egg, instead of `python setup.py install`.
user: 99991
labels: caching: Issue involving caching
issue_4900: state: open
title: [4899] fixed issue with PyCallWrapper and inconsistent Python/nopython ownership trees
body: fixes #4899
user: asodeur
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
issue_4899: state: open
title: Callwrapper cleaning-up too soon
body: `callwrapper.PyCallWrapper` is currently cleaning-up the function arguments before boxing the return value. This can cause Python objects referenced via `nrt_meminfo_new_from_pyobject` and used in both arguments and return value to be destroyed too early (on the Python side) if the ownership tree on the Python and nopython side is inconsistent.

This is a bit of a corner case (and you might argue the ownership trees should not be inconsistent in the first place) but the required changes to `PyCallWrapper` too make this safe are minimal (see PR #4900). 


user: asodeur
issue_4884: state: open
title: Switch internal Numba RNG implementation (on CPU) to use new NumPy random C interface
body: Starting with NumPy 1.18, there is a C interface to call the RNG:

https://numpy.org/devdocs/reference/random/extending.html#numba

We should eventually migrate over to this and drop our internal implementation.  We need to figure out how to use it in a threadsafe manner, of course.
user: seibert
issue_4876: state: open
title: Struct spec/implementation of __cuda_array_interface__
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

It would be very useful to have a C-level `struct` implementation of `__cuda_array_interface__`. This can be handy when interfacing with lower level codes like C/C++ that are interested in the same information. Additionally this could be used in other languages as long as they have a way of interfacing with C (which is quite common). As a result this would be useful both for Python codes and in contexts outside of Python where the same information is still needed.
user: jakirkham
labels: CUDA: CUDA related issue/PR
issue_4873: state: open
title: Add functionality to a numba.typed.Dict
body: It would be very useful if we could create dictionaries with different types of data. I would also like to be able to add None to the dictionary value.
user: 1e-to
issue_4872: state: open
title: Is it possible to let a jit CPU function call a jit CUDA kernel?
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

I faced with a challenge that two CUDA kernels are in a loop of a normal python function. Kernels are called more than 100K times in this function. This slows the speed a lot since the for-loop is not efficient in python. But two kernels are called in different [num_block, thread_per_block] so that I cannot write all of them including the loop into one kernel. 

As I know, a jit function with non-python mode should only contain numba-supported functions or other jit functions principally.
But can a jit function call a cuda.jit kernel in the future?


<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: luckyyus
labels: CUDA: CUDA related issue/PR
issue_4869: state: open
title: Can not use vectorized, nopython functions (passed as arguments) inside njit'd functions
body: Not sure if this is a bug, outstanding issue, or by-design...

A similar problem was discussed in both #1007 and #1610 but those issues are now both closed. But, it looks like the issue still persists.

Versions
Win 10 x64 (build 18362)
Python 3.7.5
NumPy 1.17.3
Numba 0.46.0 
conda 4.7.12

The code:
```
from numba import njit, vectorize, float64
import numpy as np

@vectorize([float64(float64, float64)], nopython=True)
def func_1(x, y):
    
    return x*y

@vectorize([float64(float64, float64)], nopython=True)
def func_2(x, y):
    
    return 2.*x*y

@njit
def outer(x, y, func):
    
    return func(x, y)

xx = np.linspace(0., 10., 1000)
yy = 3.

print(outer(xx, yy, func_1))
# Same issue if using other function: print(outer(xx, yy, func_2))
```

Produces the error:
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-16-5fca407667b7> in <module>
     25 yy = 3.
     26 
---> 27 print(outer(xx, yy, func_2))

C:\ProgramData\Anaconda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    399                 e.patch_message(msg)
    400 
--> 401             error_rewrite(e, 'typing')
    402         except errors.UnsupportedError as e:
    403             # Something unsupported is present in the user code, add help info

C:\ProgramData\Anaconda3\lib\site-packages\numba\dispatcher.py in error_rewrite(e, issue_type)
    342                 raise e
    343             else:
--> 344                 reraise(type(e), e, None)
    345 
    346         argtypes = []

C:\ProgramData\Anaconda3\lib\site-packages\numba\six.py in reraise(tp, value, tb)
    666             value = tp()
    667         if value.__traceback__ is not tb:
--> 668             raise value.with_traceback(tb)
    669         raise value
    670 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type pyobject
[1] During: typing of argument at <ipython-input-16-5fca407667b7> (22)

File "<ipython-input-16-5fca407667b7>", line 22:
def outer(x, y, func):
    <source elided>
    
    return func(x, y)
    ^

This error may have been caused by the following argument(s):
- argument 2: cannot determine Numba type of <class 'numba.npyufunc.dufunc.DUFunc'>

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.`
```

The ultimate goal is to have slightly different vectorized functions (func_1, func_2, ...) that the user can pick from and then pass into a njit'd function that performs some other work on the result of calling that passed function.

Thank you for all your hard work on Numba!

Update 11/18/2019
I have found that changing the last part of the code above to  ...
```
@njit
def outer(x, y):
    
    return func_1(x, y)

xx = np.linspace(0., 10., 1000)
yy = 3.

print(outer(xx, yy))
```

... does work (which appears to be what #1610 was discussing). But it would be nice to be able to pass in a njit'd, vectorized function.
user: jrenaud90
issue_4831: state: open
title: Implement `.ravel()` on non-contiguous data
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Currently if you give `.ravel()` non-contiguous data [it will raise a `NotImplementedError`]( https://github.com/numba/numba/blob/bdd8e312a24c5b76ee4fe480abe553cff349aa51/numba/cuda/cudadrv/devicearray.py#L493 ). It would be nice to have this implemented.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: jakirkham
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_4830: state: open
title: cache=True for jitclasses
body: Hello and thanks for numba! :) 

i am not sure, that it is good and possible idea, but i think that cache=True for jitclasses can be handy. Compiling of jitclass with a lot of attributes take more than half of second.

```python
from numba import jitclass, float64
from time import time

@jitclass({x: float64 for x in "abcdefghijklmnop"})
class Foo:
    def __init__(self, bar):
        self.a = bar

start = time()
foo = Foo(0.1)
print(time()- start)
# result: 0.6192972660064697
```
user: dargen3
labels: caching: Issue involving caching
issue_4828: state: open
title: Implement .copy() for DeviceNDArray
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

It would be very useful to have `.copy()` for the obvious reason of copying data. 🙂 Though it would also be useful to provide a way to force data to be contiguous as may be required by later operations.
user: jakirkham
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_4820: state: open
title: Default Arguments jitclass in an njit method
body: Default arguments with a jitclass seem to work fine in normal python code, but not within a no-python jit function. As an example,
```

@jitclass([('x', int32), ('y', int32)])
class Test:
    def __init__(self, x, y=5):
        self.x = x
        self.y = y

@njit
def fails():
    l = Test(10)
```

If you call fails you'll get an error saying the constructor expected 3 arguments, but got 2. If you remove the njit line it works fine.
user: hmc-cs-mdrissi
issue_4814: state: open
title: structs not supported for jitclass
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I tried to use jitclass with struct types, as imported from numpy. However, it yields a long error message. Here is some demo code to reproduce:

```
import numpy as np

from numba import jitclass, types
from numba.numpy_support import from_dtype

names_and_offsets_dtype = np.dtype([ \
    ('field1', np.uint64), \
    ('field2', np.uint64)])

spec = [
    ('attr1', types.unicode_type),
    ('attr2', from_dtype(np.uint64)),
    ('attr3', from_dtype(names_and_offsets_dtype))
]

@jitclass(spec)
class demo():
    def __init__(self):
        print("yay")

tmp = demo()
```
When the line with attr3 is removed, the code does not yield an error.
user: xor2k
issue_4810: state: open
title: Performance improvements needed for transpose
body: While #4777 fixes the correctness of the typing of transpose, there are opportunities for performance improvement.  The return layout of the array is always `A`, which deoptimizes generated code by requiring stride arithmetic even on the innermost dimension.  In some scenarios, the `C` or `F` layout of the result can be deduced at compile time.

This issue is a reminder to do this.
user: seibert
labels: performance: performance related issue
issue_4807: state: open
title: Cache causes Segmentation Faults when generated in parallel
body: MacBook Pro 2018
MacOS Catalina 10.15
anaconda (pkgs-main repository)
Python 3.7.4
numba=0.46.0 
llvmlite=0.30.0

I'm running 6 dask distributed workers on localhost, 1 thread per worker.
I push to dask 9000 tasks which invoke pure-python functions , which in turn internally import and run 1600 functions, 1 function per module, decorated with ``@guvectorize(cache=True)``. 

Before starting, I clean all of my ``__pycache__`` directories. The decorated functions are not imported on the client, which means that the on-disk cache is generated for the first time on the dask workers. As multiple tasks run at the same time using the same decorated function, it is very likely that two python interpreters will import the same python module containing the decorated functions at the same time and, simultaneously, build and save the cache.


To clarify:

client.py:
```python
def f1(x):
    import worker1
    worker1.g(x)

[...]

def f1600(x):
    import worker1600
    worker1600.g(x)

def main():
    with distributed.LocalCluster(n_workers=6, threads_per_worker=1) as cluster:
        with distributed.Client(cluster) as client:
            tasks = [
                submit(f, x)
                for f in (f1, f2, f3, ... f1600)
                for x in range(6)
            ]
            client.gather(tasks)

if __name__ == '__main__':
    main()
```
worker1.py ~ worker1600.py:
```python
import numba

@numba.guvectorize(..., cache=True)
def g(x):
    ...
```

The dask workers randomly fail with Segmentation Fault; the same is reproduced when I later try running the same functions one by one by hand. Only deleting the cache files solves the issue.

If I instead build the cache serially first, and then start sending tasks to dask afterwards so that the workers don't rebuild the cache but just read it from disk, the crashes disappear.

user: crusaderky
issue_4806: state: open
title: Invalid result with parfor
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I'm trying to write map-reduce style wrapper above `prange` but I'm getting incorrect results, here is simple example (simple parallel sort):
```
import numba
import numpy

@numba.njit
def chunks(l, n):
    assert n > 0
    a = len(l) // n
    b = a + 1
    c = len(l) % n
    return [l[i * b : i * b + b] if i < c else l[i * a : i * a + a] for i in range(n)]

@numba.njit(parallel=True)
# @numba.njit
def map_reduce_chunked(arg, init_val, map_func, reduce_func):
    res = init_val
    c = chunks(arg, 4)
    for i in numba.prange(len(c)):
        val = map_func(c[i])
        res = reduce_func(res, val)
    return res

@numba.njit
def map_func(a):
    return numpy.asarray(sorted(a), numpy.int32)

@numba.njit
def reduce_func(list1, list2):
    size_1 = len(list1)
    size_2 = len(list2)
    res = numpy.empty(size_1 + size_2, numpy.int32)
    i, j, k = 0, 0, 0
    while i < size_1 and j < size_2:
        if list1[i] < list2[j]:
            res[k] = list1[i]
            i += 1
        else:
            res[k] = list2[j]
            j += 1

        k += 1

    while i < size_1:
        res[k] = list1[i]
        i += 1
        k += 1

    while j < size_2:
        res[k] = list2[j]
        j += 1
        k += 1

    return res

def bar(arr):
    return map_reduce_chunked(arr, numpy.empty(0, numpy.int32), map_func, reduce_func)

arr = numpy.asarray([a * -2 for a in range(100)])

print(arr)
print(bar(arr))
```
But it returns empty array as result. If I add print into `reduce_func` it shows thats last few calls happen with both input lists empty.

It works fine if I remove `parallel=True` part.

This reproducer is a bit cumbersome, I will try to reduce it more later.
user: Hardcode84
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_4805: state: open
title: Support np.roll's Axis argument
body: The current version of numba's np.roll implementation only supports the first two arguments. A piece of code I currently use requires axis. Assuming this part, https://github.com/numba/numba/blob/master/numba/targets/arraymath.py#L1800-L1820, of numba's code is the only thing that needs to be tweaked to make it work, I'd be willing to do this task as I need a faster np.roll regardless.
user: hmc-cs-mdrissi
issue_4797: state: open
title: CUDA API interoperability
body: Context: https://gitter.im/numba/numba?at=5da0d43a89acff6ff5db56eb

A question was raised recently for how to use a stream from CuPy in Numba's jit kernel. I also happened to run into the same question myself, and this was the workaround I had:
https://gist.github.com/leofang/4a043e5d94b4702d04fde2b9e7dcebbd
The `stream_cupy_to_numba()` function there allows the following simple usage:
```python
from numba import cuda
import cupy as cp

a = cp.random.random(100)
cp_stream = cp.cuda.stream.Stream()
nb_stream = stream_cupy_to_numba(cp_stream)
# ...define a @cuda.jit kernel...
kernel[grid, block, nb_stream](a)
```

However, it might be good for Numba to define a common interface to interoperate with other GPU libraries. First, we need a list of CUDA objects to be supported, and I think this list can be simple as this:
- device
- stream
- event

Second, in Numba one could initialize the CUDA object by accepting a 3rd party counterpart. Taking streams as example, this could be made valid I suppose:
```python
# passing the raw stream pointer to initialize a Numba stream  
# also need to tie the lifetime to the foreign object
nb_stream = cuda.stream(cp_stream.ptr, cp_stream)
```

(The title may not convey the essence of this task, so please feel free to reword it.)

user: leofang
labels: CUDA: CUDA related issue/PR
discussion: An issue requiring discussion
issue_4793: state: open
title: Vectorize function (with float64 argument) raising unexpected RuntimeWarning
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

When running the code below:

```python
from numba import vectorize, float64
import numpy as np

@vectorize([float64(float64)])
def f(xx):
    if xx == 0:
        return 0
    else:
        return np.log(xx)

f(np.zeros(3, dtype=np.float64))
```

I get `RuntimeWarning: divide by zero encountered in f`, even though `np.log` should not be called.

This does not occur if I switch to `float32` for the argument.
user: watsonjj
labels: llvm: LLVM related issues
issue_4790: state: open
title: Refactor Task. Flags mapping to jit options
body: Lack of mapping from `numba.compilers.Flags` back into `numba.targets.optinos.TargetOptions`  is causing compiler flag propagation awkward.
user: sklam
issue_4788: state: open
title: Performance tracking for hnswlib
body: Reported here: https://gitter.im/numba/numba?at=5dbeee13a3f0b17849ddaf09

CC @lmcinnes, thought it'd be easier to track on a ticket as the Numba channel gets a lot of traffic.

Objective is to make this go as fast as possible:
```python
@numba.njit(
    'f4(f4[::1],f4[::1])',
    fastmath=True,
    cache=True,
    locals={"result": numba.types.float32,
            "diff": numba.types.float32,
            "dim": numba.types.int32},
)
def squared_euclidean(x, y):
    r"""Squared euclidean distance.

    .. math::
        D(x, y) = \sum_i (x_i - y_i)^2
    """
    result = 0.0
    dim = x.shape[0]
    for i in range(dim):
        diff = x[i] - y[i]
        result += diff * diff
    return result
```

hand coded  C (including intrinsics) here https://github.com/nmslib/hnswlib/blob/master/hnswlib/space_l2.h

GCC and Clang output of the C source here:
https://godbolt.org/z/dg5mZn


Current Numba output for the above python function with `NUMBA_CPU_NAME="skylake-avx512" NUMBA_CPU_FEATURES=""`:
<details>

```asm
        .text
        .file   "<string>"
        .globl  _ZN8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE
        .p2align        4, 0x90
        .type   _ZN8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE,@function
_ZN8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE:
        movq    16(%rsp), %rax
        testl   %eax, %eax
        jle     .LBB0_1
        movq    64(%rsp), %r9
        movq    8(%rsp), %r11
        movl    %eax, %r8d
        addl    $-1, %r8d
        addq    $1, %r8
        cmpq    $64, %r8
        jae     .LBB0_4
        vxorps  %xmm0, %xmm0, %xmm0
        xorl    %esi, %esi
        jmp     .LBB0_12
.LBB0_1:
        vxorps  %xmm0, %xmm0, %xmm0
        vmovss  %xmm0, (%rdi)
        xorl    %eax, %eax
        retq
.LBB0_4:
        movq    %r8, %rsi
        andq    $-64, %rsi
        leaq    -64(%rsi), %rcx
        movq    %rcx, %rdx
        shrq    $6, %rdx
        addq    $1, %rdx
        movl    %edx, %r10d
        andl    $1, %r10d
        testq   %rcx, %rcx
        je      .LBB0_5
        subq    %r10, %rdx
        vxorps  %xmm0, %xmm0, %xmm0
        xorl    %ecx, %ecx
        vxorps  %xmm1, %xmm1, %xmm1
        vxorps  %xmm2, %xmm2, %xmm2
        vxorps  %xmm3, %xmm3, %xmm3
        .p2align        4, 0x90
.LBB0_7:
        vmovups (%r11,%rcx,4), %zmm4
        vmovups 64(%r11,%rcx,4), %zmm5
        vmovups 128(%r11,%rcx,4), %zmm6
        vmovups 192(%r11,%rcx,4), %zmm7
        vsubps  (%r9,%rcx,4), %zmm4, %zmm4
        vsubps  64(%r9,%rcx,4), %zmm5, %zmm5
        vsubps  128(%r9,%rcx,4), %zmm6, %zmm6
        vsubps  192(%r9,%rcx,4), %zmm7, %zmm7
        vmulps  %zmm4, %zmm4, %zmm4
        vaddps  %zmm0, %zmm4, %zmm0
        vmulps  %zmm5, %zmm5, %zmm4
        vaddps  %zmm1, %zmm4, %zmm1
        vmulps  %zmm6, %zmm6, %zmm4
        vaddps  %zmm2, %zmm4, %zmm2
        vmulps  %zmm7, %zmm7, %zmm4
        vaddps  %zmm3, %zmm4, %zmm3
        vmovups 256(%r11,%rcx,4), %zmm4
        vmovups 320(%r11,%rcx,4), %zmm5
        vmovups 384(%r11,%rcx,4), %zmm6
        vmovups 448(%r11,%rcx,4), %zmm7
        vsubps  256(%r9,%rcx,4), %zmm4, %zmm4
        vsubps  320(%r9,%rcx,4), %zmm5, %zmm5
        vsubps  384(%r9,%rcx,4), %zmm6, %zmm6
        vsubps  448(%r9,%rcx,4), %zmm7, %zmm7
        vmulps  %zmm4, %zmm4, %zmm4
        vaddps  %zmm0, %zmm4, %zmm0
        vmulps  %zmm5, %zmm5, %zmm4
        vaddps  %zmm1, %zmm4, %zmm1
        vmulps  %zmm6, %zmm6, %zmm4
        vaddps  %zmm2, %zmm4, %zmm2
        vmulps  %zmm7, %zmm7, %zmm4
        vaddps  %zmm3, %zmm4, %zmm3
        subq    $-128, %rcx
        addq    $-2, %rdx
        jne     .LBB0_7
        testq   %r10, %r10
        je      .LBB0_10
.LBB0_9:
        vmovups (%r11,%rcx,4), %zmm4
        vmovups 64(%r11,%rcx,4), %zmm5
        vmovups 128(%r11,%rcx,4), %zmm6
        vmovups 192(%r11,%rcx,4), %zmm7
        vsubps  (%r9,%rcx,4), %zmm4, %zmm4
        vsubps  64(%r9,%rcx,4), %zmm5, %zmm5
        vsubps  128(%r9,%rcx,4), %zmm6, %zmm6
        vsubps  192(%r9,%rcx,4), %zmm7, %zmm7
        vmulps  %zmm7, %zmm7, %zmm7
        vaddps  %zmm3, %zmm7, %zmm3
        vmulps  %zmm6, %zmm6, %zmm6
        vaddps  %zmm2, %zmm6, %zmm2
        vmulps  %zmm5, %zmm5, %zmm5
        vaddps  %zmm1, %zmm5, %zmm1
        vmulps  %zmm4, %zmm4, %zmm4
        vaddps  %zmm0, %zmm4, %zmm0
.LBB0_10:
        vaddps  %zmm0, %zmm1, %zmm0
        vaddps  %zmm0, %zmm2, %zmm0
        vaddps  %zmm0, %zmm3, %zmm0
        vextractf64x4   $1, %zmm0, %ymm1
        vaddps  %zmm1, %zmm0, %zmm0
        vextractf128    $1, %ymm0, %xmm1
        vaddps  %zmm1, %zmm0, %zmm0
        vpermilpd       $1, %xmm0, %xmm1
        vaddps  %zmm1, %zmm0, %zmm0
        vmovshdup       %xmm0, %xmm1
        vaddps  %xmm1, %xmm0, %xmm0
        cmpq    %rsi, %r8
        je      .LBB0_14
        subl    %esi, %eax
.LBB0_12:
        shlq    $2, %rsi
        .p2align        4, 0x90
.LBB0_13:
        vmovss  (%r11,%rsi), %xmm1
        vsubss  (%r9,%rsi), %xmm1, %xmm1
        leaq    4(%rsi), %rsi
        vfmadd231ss     %xmm1, %xmm1, %xmm0
        addl    $-1, %eax
        jg      .LBB0_13
.LBB0_14:
        vmovss  %xmm0, (%rdi)
        xorl    %eax, %eax
        vzeroupper
        retq
.LBB0_5:
        vxorps  %xmm0, %xmm0, %xmm0
        xorl    %ecx, %ecx
        vxorps  %xmm1, %xmm1, %xmm1
        vxorps  %xmm2, %xmm2, %xmm2
        vxorps  %xmm3, %xmm3, %xmm3
        testq   %r10, %r10
        jne     .LBB0_9
        jmp     .LBB0_10
.Lfunc_end0:
        .size   _ZN8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE, .Lfunc_end0-_ZN8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE

        .globl  _ZN7cpython8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE
        .p2align        4, 0x90
        .type   _ZN7cpython8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE,@function
_ZN7cpython8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset %rbp, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register %rbp
        pushq   %r15
        pushq   %r14
        pushq   %r12
        pushq   %rbx
        andq    $-32, %rsp
        subq    $192, %rsp
        .cfi_offset %rbx, -48
        .cfi_offset %r12, -40
        .cfi_offset %r14, -32
        .cfi_offset %r15, -24
        movq    %rsi, %rdi
        movabsq $.const.squared_euclidean, %rsi
        movabsq $PyArg_UnpackTuple, %rbx
        leaq    24(%rsp), %r8
        leaq    16(%rsp), %r9
        movl    $2, %edx
        movl    $2, %ecx
        xorl    %eax, %eax
        callq   *%rbx
        vxorps  %xmm0, %xmm0, %xmm0
        vmovups %ymm0, 56(%rsp)
        vmovaps %ymm0, 32(%rsp)
        vmovups %ymm0, 120(%rsp)
        vmovaps %ymm0, 96(%rsp)
        testl   %eax, %eax
        je      .LBB1_1
        movabsq $_ZN08NumbaEnv8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE, %rax
        cmpq    $0, (%rax)
        je      .LBB1_4
        movq    24(%rsp), %rdi
        vxorps  %xmm0, %xmm0, %xmm0
        vmovups %ymm0, 56(%rsp)
        vmovaps %ymm0, 32(%rsp)
        movabsq $NRT_adapt_ndarray_from_python, %r15
        leaq    32(%rsp), %rsi
        vzeroupper
        callq   *%r15
        testl   %eax, %eax
        jne     .LBB1_8
        cmpq    $4, 56(%rsp)
        jne     .LBB1_8
        movq    32(%rsp), %r14
        movq    64(%rsp), %rbx
        movl    72(%rsp), %r12d
        movq    16(%rsp), %rdi
        vxorps  %xmm0, %xmm0, %xmm0
        vmovups %ymm0, 120(%rsp)
        vmovaps %ymm0, 96(%rsp)
        leaq    96(%rsp), %rsi
        vzeroupper
        callq   *%r15
        testl   %eax, %eax
        jne     .LBB1_11
        cmpq    $4, 120(%rsp)
        jne     .LBB1_11
        movq    96(%rsp), %r15
        testl   %r12d, %r12d
        jle     .LBB1_13
        movq    128(%rsp), %rax
        cmpq    $64, %r12
        jae     .LBB1_16
        vxorps  %xmm0, %xmm0, %xmm0
        xorl    %ecx, %ecx
        jmp     .LBB1_19
.LBB1_13:
        vxorps  %xmm0, %xmm0, %xmm0
        jmp     .LBB1_21
.LBB1_16:
        movl    %r12d, %edx
        andl    $63, %edx
        movq    %r12, %rcx
        subq    %rdx, %rcx
        vxorps  %xmm0, %xmm0, %xmm0
        xorl    %esi, %esi
        vxorps  %xmm1, %xmm1, %xmm1
        vxorps  %xmm2, %xmm2, %xmm2
        vxorps  %xmm3, %xmm3, %xmm3
        .p2align        4, 0x90
.LBB1_17:
        vmovups (%rbx,%rsi,4), %zmm4
        vmovups 64(%rbx,%rsi,4), %zmm5
        vmovups 128(%rbx,%rsi,4), %zmm6
        vmovups 192(%rbx,%rsi,4), %zmm7
        vsubps  (%rax,%rsi,4), %zmm4, %zmm4
        vsubps  64(%rax,%rsi,4), %zmm5, %zmm5
        vsubps  128(%rax,%rsi,4), %zmm6, %zmm6
        vsubps  192(%rax,%rsi,4), %zmm7, %zmm7
        vmulps  %zmm4, %zmm4, %zmm4
        vaddps  %zmm0, %zmm4, %zmm0
        vmulps  %zmm5, %zmm5, %zmm4
        vaddps  %zmm1, %zmm4, %zmm1
        vmulps  %zmm6, %zmm6, %zmm4
        vaddps  %zmm2, %zmm4, %zmm2
        vmulps  %zmm7, %zmm7, %zmm4
        vaddps  %zmm3, %zmm4, %zmm3
        addq    $64, %rsi
        cmpq    %rsi, %rcx
        jne     .LBB1_17
        vaddps  %zmm0, %zmm1, %zmm0
        vaddps  %zmm0, %zmm2, %zmm0
        vaddps  %zmm0, %zmm3, %zmm0
        vextractf64x4   $1, %zmm0, %ymm1
        vaddps  %zmm1, %zmm0, %zmm0
        vextractf128    $1, %ymm0, %xmm1
        vaddps  %zmm1, %zmm0, %zmm0
        vpermilpd       $1, %xmm0, %xmm1
        vaddps  %zmm1, %zmm0, %zmm0
        vmovshdup       %xmm0, %xmm1
        vaddps  %xmm1, %xmm0, %xmm0
        testq   %rdx, %rdx
        je      .LBB1_20
        .p2align        4, 0x90
.LBB1_19:
        vmovss  (%rbx,%rcx,4), %xmm1
        vsubss  (%rax,%rcx,4), %xmm1, %xmm1
        leaq    1(%rcx), %rcx
        vfmadd231ss     %xmm1, %xmm1, %xmm0
        cmpq    %rcx, %r12
        jne     .LBB1_19
.LBB1_20:
        vcvtss2sd       %xmm0, %xmm0, %xmm0
.LBB1_21:
        vmovsd  %xmm0, 8(%rsp)
        movabsq $NRT_decref, %rbx
        movq    %r14, %rdi
        vzeroupper
        callq   *%rbx
        movq    %r15, %rdi
        callq   *%rbx
        movabsq $PyFloat_FromDouble, %rax
        vmovsd  8(%rsp), %xmm0
        callq   *%rax
.LBB1_2:
        leaq    -32(%rbp), %rsp
        popq    %rbx
        popq    %r12
        popq    %r14
        popq    %r15
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        vzeroupper
        retq
.LBB1_4:
        .cfi_def_cfa %rbp, 16
        movabsq $PyExc_RuntimeError, %rdi
        movabsq $".const.missing Environment", %rsi
        jmp     .LBB1_5
.LBB1_8:
        movabsq $PyExc_TypeError, %rdi
        movabsq $".const.can't unbox array from PyObject into native value.  The object maybe of a different type", %rsi
.LBB1_5:
        movabsq $PyErr_SetString, %rax
        vzeroupper
        callq   *%rax
        jmp     .LBB1_1
.LBB1_11:
        movabsq $PyExc_TypeError, %rdi
        movabsq $".const.can't unbox array from PyObject into native value.  The object maybe of a different type", %rsi
        movabsq $PyErr_SetString, %rax
        callq   *%rax
        movabsq $NRT_decref, %rax
        movq    %r14, %rdi
        callq   *%rax
.LBB1_1:
        xorl    %eax, %eax
        jmp     .LBB1_2
.Lfunc_end1:
        .size   _ZN7cpython8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE, .Lfunc_end1-_ZN7cpython8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE
        .cfi_endproc

        .weak   NRT_decref
        .p2align        4, 0x90
        .type   NRT_decref,@function
NRT_decref:
        .cfi_startproc
        testq   %rdi, %rdi
        je      .LBB2_2
        #MEMBARRIER
        lock            subq    $1, (%rdi)
        je      .LBB2_3
.LBB2_2:
        retq
.LBB2_3:
        #MEMBARRIER
        movabsq $NRT_MemInfo_call_dtor, %rax
        jmpq    *%rax
.Lfunc_end2:
        .size   NRT_decref, .Lfunc_end2-NRT_decref
        .cfi_endproc

        .type   _ZN08NumbaEnv8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE,@object
        .comm   _ZN08NumbaEnv8__main__21squared_euclidean$241E5ArrayIfLi1E1C7mutable7alignedE5ArrayIfLi1E1C7mutable7alignedE,8,8
        .type   .const.squared_euclidean,@object
        .section        .rodata,"a",@progbits
        .p2align        4
.const.squared_euclidean:
        .asciz  "squared_euclidean"
        .size   .const.squared_euclidean, 18

        .type   ".const.missing Environment",@object
        .p2align        4
".const.missing Environment":
        .asciz  "missing Environment"
        .size   ".const.missing Environment", 20

        .type   ".const.can't unbox array from PyObject into native value.  The object maybe of a different type",@object
        .p2align        4
".const.can't unbox array from PyObject into native value.  The object maybe of a different type":
        .asciz  "can't unbox array from PyObject into native value.  The object maybe of a different type"
        .size   ".const.can't unbox array from PyObject into native value.  The object maybe of a different type", 89


        .section        ".note.GNU-stack","",@progbits

```
</details>

Looks like Numba is managing to produce something similar to GCC, this is Numba:
```asm
.LBB1_17:
        vmovups (%rbx,%rsi,4), %zmm4
        vmovups 64(%rbx,%rsi,4), %zmm5
        vmovups 128(%rbx,%rsi,4), %zmm6
        vmovups 192(%rbx,%rsi,4), %zmm7
        vsubps  (%rax,%rsi,4), %zmm4, %zmm4
        vsubps  64(%rax,%rsi,4), %zmm5, %zmm5
        vsubps  128(%rax,%rsi,4), %zmm6, %zmm6
        vsubps  192(%rax,%rsi,4), %zmm7, %zmm7
        vmulps  %zmm4, %zmm4, %zmm4
        vaddps  %zmm0, %zmm4, %zmm0
        vmulps  %zmm5, %zmm5, %zmm4
        vaddps  %zmm1, %zmm4, %zmm1
        vmulps  %zmm6, %zmm6, %zmm4
        vaddps  %zmm2, %zmm4, %zmm2
        vmulps  %zmm7, %zmm7, %zmm4
        vaddps  %zmm3, %zmm4, %zmm3
        addq    $64, %rsi
        cmpq    %rsi, %rcx
        jne     .LBB1_17
        vaddps  %zmm0, %zmm1, %zmm0
        vaddps  %zmm0, %zmm2, %zmm0
        vaddps  %zmm0, %zmm3, %zmm0
        vextractf64x4   $1, %zmm0, %ymm1
        vaddps  %zmm1, %zmm0, %zmm0
        vextractf128    $1, %ymm0, %xmm1
        vaddps  %zmm1, %zmm0, %zmm0
        vpermilpd       $1, %xmm0, %xmm1
        vaddps  %zmm1, %zmm0, %zmm0
        vmovshdup       %xmm0, %xmm1
        vaddps  %xmm1, %xmm0, %xmm0
        testq   %rdx, %rdx
        je      .LBB1_20
        .p2align        4, 0x90
```
this is GCC
```asm
.L3:
        vmovups 32(%rdi), %ymm1
        vmovups 32(%rsi), %ymm3
        vmovups (%rdi), %ymm4
        vsubps  %ymm3, %ymm1, %ymm1
        vsubps  (%rsi), %ymm4, %ymm0
        addq    $64, %rdi
        vmulps  %ymm1, %ymm1, %ymm1
        addq    $64, %rsi
        vfmadd132ps     %ymm0, %ymm1, %ymm0
        vaddps  %ymm0, %ymm2, %ymm2
        cmpq    %rdi, %rax
        ja      .L3
        vshufps $85, %xmm2, %xmm2, %xmm3
        vaddss  %xmm3, %xmm2, %xmm0
        vunpckhps       %xmm2, %xmm2, %xmm3
        vshufps $255, %xmm2, %xmm2, %xmm1
        vaddss  %xmm1, %xmm3, %xmm1
        vextractf128    $0x1, %ymm2, %xmm2
        vshufps $85, %xmm2, %xmm2, %xmm3
        vaddss  %xmm1, %xmm0, %xmm0
        vaddss  %xmm3, %xmm2, %xmm1
        vunpckhps       %xmm2, %xmm2, %xmm3
        vshufps $255, %xmm2, %xmm2, %xmm2
        vaddss  %xmm2, %xmm3, %xmm2
        vaddss  %xmm2, %xmm1, %xmm2
        vaddss  %xmm2, %xmm0, %xmm0
        vzeroupper
        ret
```
as evident in the Compiler Explorer, Clang does something different.
user: stuartarchibald
labels: performance: performance related issue
issue_4786: state: open
title: Integer typing issues [was: "Return types for bit shift operators"]
body: I've got a bitshift return type question/ issue. I think the current return types are confusing, and would like permission to change them, but realize there might be more context. I've come across this while trying to resolve some typing issues for my gcd pr.

Right now, bit shifting will upcast to `typemax(lhs, intp)`. This is weird for a few cases, like `types.uint8(255) << 1`. I would expect `254: uint8` in that case, but get `510: uint64`. [Comments on the code make this look intentional](https://github.com/numba/numba/blob/b26b19df632d9302f740d39c5f00032dd70f356d/numba/typing/builtins.py#L296-L312).

This is a little similar to what numpy does:

```python
assert np.uint8(255) << 1 == 510
```

However, numpy seems to use type promotion for this, so getting the expected behaviour is possible. Numba does not allow this.

```python
assert np.uint8(255) << np.uint8(1) == 254
assert njit(lambda : np.uint8(255) << np.uint8(1) != 254)() 
```

Apart from giving unexpected values, I think the implicit upcasting is confusing and can lead to performance problems (due to rounds of casting) for binary algorithms. Can I change this behaviour, or are there implications I'm not seeing?

I think it would make sense to mimic numpy's behaviour here. Ideally, I think the result type of the bitshift operators should only depend on the `lhs`, but this could get complicated since it's different behaviour than the ecosystem.
user: ivirshup
labels: discussion: An issue requiring discussion
issue_4773: state: open
title: jitclass member array assignments do not type promote
body: Hi Everyone! 

As I think the error is pretty self-explanatory I'll go without much further explanation:

## POC
```python
import numpy as np
import numba


@numba.jitclass([
    ("arr", numba.float64[:, :, :]),
    ("n", numba.int64)
])
class Area:
    def __init__(self, n: int = 10):
        self.n = n
        self.arr = np.empty((self.n, self.n, self.n))


if __name__ == '__main__':
    area = Area()
    area.arr = area.arr < .5  # <--
```

## Expected Outcome

The `.arr` field behaves like a numpy array and performs an element-wise comparison

## Actual Outcome

It crashes:

```
/usr/local/Cellar/python/3.7.3/bin/python3 /Users/maxmunzel/Desktop/spider/spider/poc.py
/Users/maxmunzel/Desktop/spider/spider/poc.py:17: RuntimeWarning: invalid value encountered in less
  area.arr = area.arr < .5
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/numba/errors.py", line 717, in new_error_context
    yield
  File "/usr/local/lib/python3.7/site-packages/numba/lowering.py", line 260, in lower_block
    self.lower_inst(inst)
  File "/usr/local/lib/python3.7/site-packages/numba/lowering.py", line 406, in lower_inst
    return impl(self.builder, (target, value))
  File "/usr/local/lib/python3.7/site-packages/numba/targets/base.py", line 620, in wrapped
    return impl(self, builder, sig, args, attr)
  File "/usr/local/lib/python3.7/site-packages/numba/targets/imputils.py", line 163, in res
    return real_impl(context, builder, sig, args, attr)
  File "/usr/local/lib/python3.7/site-packages/numba/jitclass/base.py", line 440, in set_attr_impl
    setattr(data, _mangle_attr(attr), val)
  File "/usr/local/lib/python3.7/site-packages/numba/cgutils.py", line 164, in __setattr__
    self[self._datamodel.get_field_position(field)] = value
  File "/usr/local/lib/python3.7/site-packages/numba/cgutils.py", line 178, in __setitem__
    value = self._cast_member_from_value(index, value)
  File "/usr/local/lib/python3.7/site-packages/numba/cgutils.py", line 251, in _cast_member_from_value
    return model.as_data(self._builder, val)
  File "/usr/local/lib/python3.7/site-packages/numba/datamodel/models.py", line 569, in as_data
    struct = builder.insert_value(struct, el, [i])
  File "/usr/local/lib/python3.7/site-packages/llvmlite/ir/builder.py", line 937, in insert_value
    instr = instructions.InsertValue(self.block, agg, value, idx, name=name)
  File "/usr/local/lib/python3.7/site-packages/llvmlite/ir/instructions.py", line 652, in __init__
    % (typ, list(indices), agg.type, elem.type))
TypeError: Can only insert double* at [4] in {i8*, i8*, i64, i64, double*, [3 x i64], [3 x i64]}: got i8*

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/casparfriedrich/Desktop/spider/spider/poc.py", line 17, in <module>
    area.arr = area.arr < .5
  File "/usr/local/lib/python3.7/site-packages/numba/dispatcher.py", line 420, in _compile_for_args
    raise e
  File "/usr/local/lib/python3.7/site-packages/numba/dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/usr/local/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/numba/dispatcher.py", line 768, in compile
    cres = self._compiler.compile(args, return_type)
  File "/usr/local/lib/python3.7/site-packages/numba/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "/usr/local/lib/python3.7/site-packages/numba/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "/usr/local/lib/python3.7/site-packages/numba/dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "/usr/local/lib/python3.7/site-packages/numba/compiler.py", line 528, in compile_extra
    return pipeline.compile_extra(func)
  File "/usr/local/lib/python3.7/site-packages/numba/compiler.py", line 326, in compile_extra
    return self._compile_bytecode()
  File "/usr/local/lib/python3.7/site-packages/numba/compiler.py", line 385, in _compile_bytecode
    return self._compile_core()
  File "/usr/local/lib/python3.7/site-packages/numba/compiler.py", line 365, in _compile_core
    raise e
  File "/usr/local/lib/python3.7/site-packages/numba/compiler.py", line 356, in _compile_core
    pm.run(self.state)
  File "/usr/local/lib/python3.7/site-packages/numba/compiler_machinery.py", line 328, in run
    raise patched_exception
  File "/usr/local/lib/python3.7/site-packages/numba/compiler_machinery.py", line 319, in run
    self._runPass(idx, pass_inst, state)
  File "/usr/local/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/numba/compiler_machinery.py", line 281, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/usr/local/lib/python3.7/site-packages/numba/compiler_machinery.py", line 268, in check
    mangled = func(compiler_state)
  File "/usr/local/lib/python3.7/site-packages/numba/typed_passes.py", line 380, in run_pass
    NativeLowering().run_pass(state) # TODO: Pull this out into the pipeline
  File "/usr/local/lib/python3.7/site-packages/numba/typed_passes.py", line 325, in run_pass
    lower.lower()
  File "/usr/local/lib/python3.7/site-packages/numba/lowering.py", line 179, in lower
    self.lower_normal_function(self.fndesc)
  File "/usr/local/lib/python3.7/site-packages/numba/lowering.py", line 220, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/usr/local/lib/python3.7/site-packages/numba/lowering.py", line 245, in lower_function_body
    self.lower_block(block)
  File "/usr/local/lib/python3.7/site-packages/numba/lowering.py", line 260, in lower_block
    self.lower_inst(inst)
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/local/lib/python3.7/site-packages/numba/errors.py", line 725, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/usr/local/lib/python3.7/site-packages/numba/six.py", line 669, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Can only insert double* at [4] in {i8*, i8*, i64, i64, double*, [3 x i64], [3 x i64]}: got i8*

File "<string>", line 3:
<source missing, REPL/exec in use?>

[1] During: lowering "(__numba_self_).arr = __numba_val" at <string> (3)

-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.46.0.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!



Process finished with exit code 1
```

## Setup

```bash
$pip freeze | grep numba
numba==0.46.0
$pip freeze | grep numpy
numpy==1.15.4
$python3 --version
Python 3.7.4
```

<img width="698" alt="Screenshot 2019-11-01 at 18 38 53" src="https://user-images.githubusercontent.com/5411096/68043989-dcda3680-fcd6-11e9-956c-557ffabc7cbd.png">


## Final thoughts

I hope this helps, if you have further questions feel free to ask. 

**Thank you for providing and developing Numba! It really sets a high bar in terms of performance, features and ergonomics, that I haven't found anywhere else :)**
 
user: maxmunzel
issue_4772: state: open
title: String rjust/ljust/center slow to compile
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

String functions rjust/ljust/center seem very slow to compile for some reason.
```python
In [1]: %time numba.njit(lambda s: s.rjust(5))("AA")
CPU times: user 4.59 s, sys: 45.1 ms, total: 4.63 s
Wall time: 4.63 s
Out[1]: '   AA'
```
user: ehsantn
labels: performance - compile time: Performance issue occurring at compile time.
issue_4759: state: open
title: NUMBA_DISABLE_JIT breaks @generated_jit
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG). (no: 0.45.1)
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I'm using `numba.generated_jit` as suggested in [this conversation](https://gitter.im/numba/numba?at=5db0223be1c5e91508bcbcec). I'd like to do a CI run with `NUMBA_DISABLE_JIT=1` to improve my coverage a little, however the functions decorated with `generated_jit` now behave very differently:

With `NUMBA_DISABLE_JIT`
```python
In [1]: import os

In [3]: os.environ['NUMBA_DISABLE_JIT'] = '1'

In [4]: import numba

In [5]: @numba.generated_jit(nopython=True)
   ...: def foo(value, other_value):
   ...:     return lambda value, other_value: 3
   ...:

In [6]: foo(1, 2)
Out[6]: <function __main__.foo.<locals>.<lambda>(value, other_value)>
```
Without `NUMBA_DISABLE_JIT`:
```python
In [1]: import os

In [4]: import numba

In [5]: @numba.generated_jit(nopython=True)
   ...: def foo(value, other_value):
   ...:     return lambda value, other_value: 3
   ...:

In [6]: foo(1, 2)
Out[6]: 3
```
user: eric-wieser
issue_4758: state: open
title: convert float to string within numba function
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba
![image](https://user-images.githubusercontent.com/5416611/67744862-a9d93e00-fa5d-11e9-9d3a-05efee1f89dc.png)
- [x] I have included below a minimal working reproducer.

```pyton
import numpy as np
import numba as nb

@nb.njit(nogil=True)
def func():
    my_array = np.empty(6, dtype=np.dtype("U20"))
    my_array[0] = np.str(2.35646)
    return my_array


if __name__ == '__main__':
    a = func()
    print(a)
```

I would have expected the conversion to go without trouble but I'm getting this error message
```
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<class 'str'>) with argument(s) of type(s): (float64)
```

user: elChapoSing
issue_4752: state: open
title: Profiling only the running time of a jit-decorated function
body: ## Feature request

I would like to be able to profile the running time of some function I've decorated with `@jit`. But the time of the call unsurprisingly includes the compilation time. My work-around is to call the function twice, as in:

```python
@jit(nopython=False)
def f(...):
    # some time-consuming function
    ...

f(...)   # <-- throw-away call

start = time.time()
y = f(...)
end = time.time()

print(end - start)
```

Is there a way to avoid the throw-away call? For instance, a feature such as `f.precompile()` to compile and cache `f` without invoking it? I understand there is AOT compilation as well, but that only supports a subset of JIT features and requires additional markup? Thanks for your help!
user: arvoelke
issue_4749: state: open
title: Allow casting numpy scalars
body: From [gitter](https://gitter.im/numba/numba?at=5db266f2a03ae1584f04f64d):
I'm running into the below error:
```
TypeError: No matching definition for argument type(s) array(float64, 0d, C), float64, float64, float64, float64, float64
```
My function is jit compiled to accept float64args. I'm passing it to an external routine which internally casts one of the args to a 0d numpy array and hence I get the above error.

It would be great if there were some way to tell numba to cast numpy scalars to their underlying type.

user: dhirschfeld
issue_4740: state: open
title: Structured array of jitclass instances (jitclass <-> dtype)
body: ## Feature request

I would like to have arrays of jitclasses, ideally that could be passed back to python code as a numpy array with a structured dtype. As a point of reference, I'm thinking of how Julia does arrays – especially when the elements are "bits types". I definitely don't think this is something that would be quick to implement or be pre 1.0 – especially the parts about overloading ufuncs. I could also be missing something fundamental that makes this impossible. As an example, I might like to have an array of rational numbers:

```python
from numba import types, njit, jitclass

@jitclass([("num", types.int64), ("den", types.int64)])
class Rational(object):
    mutable = False  # Also would be nice
    def __init__(self, num, den):
        g = np.gcd(num, den)  # Not currently in numba
        self.num = num // g
        self.den = den // g

@njit 
def foo(): 
    return np.array([Rational(x, 2) for x in range(1, 11, 2)]) 

a = foo()  # a.dtype should be like Rational.class_type.struct
```

It'd be nice if I could define some operation (like addition) over these, and automatically get features like ufuncs. E.g. something like:

```python
import operators as op
from numba.extending import overload

@njit
def _add_rationals(x, y):
    g = np.gcd(x.den, y.den)
    xd = x.den // g
    yd = y.den // g
    return Rational((x.num * yd) + (y.num * xd), (x.den * yd))

@overload(op.add)  # Not sure how overloading ufuncs should work
def add_rationals(x, y):
    x_rational = isinstance(x, Rational)
    y_rational = isinstance(y, Rational)
    if x_rational & y_rational:
        return _add_rationals
    elif x_rational:
        return lambda x, y: _add_rationals(x, Rational(y))
    elif y_rational:
        return lambda x, y: _add_rationals(Rational(x), y)

a_plus_one = njit(lambda x: x + 1)(a)  
# Would be very cool if this could also work in python code
```

While this would be useful just in compiled code, if these arrays were available python code they could be written to array stores like hdf5, zarr, or arrow:

```python
import pyarrow as pa

toarrow = pa.array(a_plus_one)
fromarrow = arrow.to_numpy().view(Rational)
```

I think this could allow for some very cool interop.
user: ivirshup
issue_4735: state: open
title: LoweringError when yielding multiple elements from an njit function
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I tried simplifying this example, but I wasn't able to reproduce with a slimmed down version.

```
In [7]: import numba

In [8]: numba.__version__
Out[8]: '0.45.1'

In [11]: class FixedWindowIndexer:
    ...:
    ...:     @staticmethod
    ...:     @numba.njit(nogil=True)
    ...:     def get_window_bounds(
    ...:         num_values=0,
    ...:         window_size=0,
    ...:         min_periods=None,
    ...:         center=None,
    ...:         closed=None,
    ...:         win_type=None,
    ...:     ):
    ...:         for i in range(window_size):
    ...:             yield 0, i + 1
    ...:         for i in range(1, num_values - window_size + 1):
    ...:             yield i, i + window_size
    ...:

In [12]: for start, end in FixedWindowIndexer().get_window_bounds(10, 2):
    ...:     print(start, end)
    ...:
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    661     try:
--> 662         yield
    663     except NumbaError as e:

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    257                                    loc=self.loc, errcls_=defaulterrcls):
--> 258                 self.lower_inst(inst)
    259

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/lowering.py in lower_inst(self, inst)
    300             ty = self.typeof(inst.target.name)
--> 301             val = self.lower_assign(ty, inst)
    302             self.storevar(val, inst.target.name)

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    486         elif isinstance(value, ir.Yield):
--> 487             res = self.lower_yield(ty, value)
    488             self.incref(ty, res)

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/lowering.py in lower_yield(self, retty, inst)
    509         # return
--> 510         self.call_conv.return_value(self.builder, retval)
    511

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/targets/callconv.py in return_value(self, builder, retval)
    343         assert retval.type == retptr.type.pointee, \
--> 344             (str(retval.type), str(retptr.type.pointee))
    345         builder.store(retval, retptr)

AssertionError: ('{i64, i64}', '[2 x i64]')

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-12-0a51e19ecb08> in <module>
----> 1 for start, end in FixedWindowIndexer().get_window_bounds(10, 2):
      2     print(start, end)
      3

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    393                     e.patch_message(''.join(e.args) + help_msg)
    394             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 395             raise e
    396
    397     def inspect_llvm(self, signature=None):

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    350                 argtypes.append(self.typeof_pyval(a))
    351         try:
--> 352             return self.compile(tuple(argtypes))
    353         except errors.TypingError as e:
    354             # Intercept typing error that may be due to an argument

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, sig)
    691
    692             self._cache_misses[sig] += 1
--> 693             cres = self._compiler.compile(args, return_type)
    694             self.add_overload(cres)
    695             self._cache.save_overload(sig, cres)

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     74
     75     def compile(self, args, return_type):
---> 76         status, retval = self._compile_cached(args, return_type)
     77         if status:
     78             return retval

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in _compile_cached(self, args, return_type)
     88
     89         try:
---> 90             retval = self._compile_core(args, return_type)
     91         except errors.TypingError as e:
     92             self._failed_cache[key] = e

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in _compile_core(self, args, return_type)
    106                                       args=args, return_type=return_type,
    107                                       flags=flags, locals=self.locals,
--> 108                                       pipeline_class=self.pipeline_class)
    109         # Check typing error if object mode is used
    110         if cres.typing_error is not None and not flags.enable_pyobject:

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    970     pipeline = pipeline_class(typingctx, targetctx, library,
    971                               args, return_type, flags, locals)
--> 972     return pipeline.compile_extra(func)
    973
    974

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    388         self.lifted = ()
    389         self.lifted_from = None
--> 390         return self._compile_bytecode()
    391
    392     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    901         """
    902         assert self.func_ir is None
--> 903         return self._compile_core()
    904
    905     def _compile_ir(self):

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    888         self.define_pipelines(pm)
    889         pm.finalize()
--> 890         res = pm.run(self.status)
    891         if res is not None:
    892             # Early pipeline completion

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    264                     # No more fallback pipelines?
    265                     if is_final_pipeline:
--> 266                         raise patched_exception
    267                     # Go to next fallback pipeline
    268                     else:

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    255                 try:
    256                     event("-- %s" % stage_name)
--> 257                     stage()
    258                 except _EarlyPipelineCompletion as e:
    259                     return e.result

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in stage_nopython_backend(self)
    762         """
    763         lowerfn = self.backend_nopython_mode
--> 764         self._backend(lowerfn, objectmode=False)
    765
    766     def stage_compile_interp_mode(self):

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    701             self.library.enable_object_caching()
    702
--> 703         lowered = lowerfn()
    704         signature = typing.signature(self.return_type, *self.args)
    705         self.cr = compile_result(

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in backend_nopython_mode(self)
    688                 self.calltypes,
    689                 self.flags,
--> 690                 self.metadata)
    691
    692     def _backend(self, lowerfn, objectmode):

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags, metadata)
   1141         lower = lowering.Lower(targetctx, library, fndesc, interp,
   1142                                metadata=metadata)
-> 1143         lower.lower()
   1144         if not flags.no_cpython_wrapper:
   1145             lower.create_cpython_wrapper(flags.release_gil)

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/lowering.py in lower(self)
    181
    182             self.genlower.lower_init_func(self)
--> 183             self.genlower.lower_next_func(self)
    184             if self.gentype.has_finalizer:
    185                 self.genlower.lower_finalize_func(self)

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/generators.py in lower_next_func(self, lower)
    151
    152         # Lower the generator's Python code
--> 153         entry_block_tail = lower.lower_function_body()
    154
    155         # Add block for StopIteration on entry

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/lowering.py in lower_function_body(self)
    241             bb = self.blkmap[offset]
    242             self.builder.position_at_end(bb)
--> 243             self.lower_block(block)
    244
    245         self.post_lower()

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    256             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    257                                    loc=self.loc, errcls_=defaulterrcls):
--> 258                 self.lower_inst(inst)
    259
    260     def create_cpython_wrapper(self, release_gil=False):

/anaconda3/envs/pandas-2s-dev/lib/python3.7/contextlib.py in __exit__(self, type, value, traceback)
    128                 value = type()
    129             try:
--> 130                 self.gen.throw(type, value, traceback)
    131             except StopIteration as exc:
    132                 # Suppress StopIteration *unless* it's the same exception that

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    668         from numba import config
    669         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 670         six.reraise(type(newerr), newerr, tb)
    671
    672

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660
    661 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
('{i64, i64}', '[2 x i64]')

File "<ipython-input-11-96084293c3ed>", line 14:
    def get_window_bounds(
        <source elided>
        for i in range(window_size):
            yield 0, i + 1
            ^

[1] During: lowering "$12.7 = yield $12.6" at <ipython-input-11-96084293c3ed> (14)
-------------------------------------------------------------------------------

```

user: mroeschke
issue_4730: state: open
title: Refactor call table code to replace with `find_call_name` or similar.
body: As noted in https://github.com/numba/numba/pull/4718#issuecomment-543718268
user: stuartarchibald
issue_4719: state: open
title: Supporting DLPack
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

It would be really useful if we could construct `DeviceNDArray` objects from [DLPack objects]( https://github.com/dmlc/dlpack ). Similarly it would be useful if we could convert `DeviceNDArray` objects to DLPack objects. This would allow for another path of sharing data with deep learning frameworks.
user: jakirkham
labels: CUDA: CUDA related issue/PR
issue_4716: state: open
title: How to json a nested dictionary?
body: Here is my code:
-------------------------------------------------------
import json
from numba import njit, typeof, typed, types
d1 = typed.Dict.empty(
    key_type=types.float64,
    value_type=types.float64,
)
d2 = typed.Dict.empty(
    key_type=types.float64,
    value_type=typeof(d1), 
)
@njit
def foo(d2):
    d2[2.] = {3.: 4.}
    return d2
d2=foo(d2)
with open('f:/a','w')as f:
    json.dump(d2,f)
-------------------------------------------------------------------
And here is the error:Object of type 'Dict' is not JSON serializable

and here is my solution:
------------------------------------------------------------------
d2=dict(d2)
for key,value in d2.items():
    d2[key]=dict(value)
--------------------------------------------------------------------
and it worked.
My question is：Is there a more elegant way for doing this?Since if my dict has a deeper structure,
(say:
d3 = typed.Dict.empty(
    key_type=types.float64,
    value_type=typeof(d2), ))
i have to use nested for-loops for type-casting,and process of casting cannot be done in jit mode,my way may not be so effective. 



user: scirocc
issue_4713: state: open
title: Numba is not detecting the icc_rt libraries when installed with pip
body: Hello, I am trying to take advantage of Intel SVML. However, installing icc_rt by using pip (through PyCharm) does not make numba utilizes it since `numba -s`  says SVML is False as below.  [This instruction](http://numba.pydata.org/numba-doc/latest/user/performance-tips.html#intel-svml) only gives a way to install with conda. Is there any way to do it without conda? 

```
System info:
--------------------------------------------------------------------------------
__Time Stamp__
2019-10-15 07:41:22.709866

__Hardware Information__
Machine                                       : x86_64
CPU Name                                      : skylake
Number of accessible CPU cores                : 12
Listed accessible CPUs cores                  : 0-11
CFS restrictions                              : None
CPU Features                                  : 
64bit adx aes avx avx2 bmi bmi2 clflushopt cmov cx16 f16c fma fsgsbase invpcid
lzcnt mmx movbe pclmul popcnt prfchw rdrnd rdseed sahf sgx sse sse2 sse3 sse4.1
sse4.2 ssse3 xsave xsavec xsaveopt xsaves

__OS Information__
Platform                                      : Linux-5.0.0-31-generic-x86_64-with-Ubuntu-18.04-bionic
Release                                       : 5.0.0-31-generic
System Name                                   : Linux
Version                                       : #33~18.04.1-Ubuntu SMP Tue Oct 1 10:20:39 UTC 2019
OS specific info                              : Ubuntu18.04bionic
glibc info                                    : glibc 2.25

__Python Information__
Python Compiler                               : GCC 8.3.0
Python Implementation                         : CPython
Python Version                                : 3.6.8
Python Locale                                 : en_US UTF-8

__LLVM information__
LLVM version                                  : 8.0.0

__CUDA Information__
Found 1 CUDA devices
id 0    b'GeForce GTX 1050 Ti with Max-Q Design'                              [SUPPORTED]
                      compute capability: 6.1
                           pci device id: 0
                              pci bus id: 1
Summary:
	1/1 devices are supported
CUDA driver version                           : 10010
CUDA libraries:
Finding cublas from System
	ERROR: can't locate lib
Finding cusparse from System
	named  libcusparse.so.10.3.0.243
Finding cufft from System
	named  libcufft.so.10.1.1.243
Finding curand from System
	named  libcurand.so.10.1.1.243
Finding nvvm from System
	named  libnvvm.so.3.3.0
Finding libdevice from System
	searching for compute_20...	ok
	searching for compute_30...	ok
	searching for compute_35...	ok
	searching for compute_50...	ok

__ROC Information__
ROC available                                 : False
Error initialising ROC due to                 : No ROC toolchains found.
No HSA Agents found, encountered exception when searching:
Error at driver init: 
NUMBA_HSA_DRIVER /opt/rocm/lib/libhsa-runtime64.so is not a valid file path.  Note it must be a filepath of the .so/.dll/.dylib or the driver:

__SVML Information__
SVML state, config.USING_SVML                 : False
SVML library found and loaded                 : False
llvmlite using SVML patched LLVM              : True
SVML operational                              : False

__Threading Layer Information__
TBB Threading layer available                 : True
OpenMP Threading layer available              : False
+--> Disabled due to                          : Unknown import problem.
Workqueue Threading layer available           : True

__Numba Environment Variable Information__
None set.

__Conda Information__
ERROR: The install method you used for conda--probably either `pip install conda`
or `easy_install conda`--is not compatible with using conda as an application.
If your intention is to install conda as a standalone application, currently
supported install methods include the Anaconda installer and the miniconda
installer.  You can download the miniconda installer from
https://conda.io/miniconda.html.

Conda not present/not working.
Error was Command '['conda', 'info', '--json']' returned non-zero exit status 1.

--------------------------------------------------------------------------------
If requested, please copy and paste the information between
the dashed (----) lines, or from a given specific section as
appropriate.

=============================================================
IMPORTANT: Please ensure that you are happy with sharing the
contents of the information present, any information that you
wish to keep private you should remove before sharing.
=============================================================
```
user: sogoogos
labels: wheels: Issue with wheels
installation: issue with installation
issue_4706: state: open
title: np.heaviside in `no_python` mode
body: Hi,

`np.heaviside(x1, x2)` (https://docs.scipy.org/doc/numpy/reference/generated/numpy.heaviside.html) does not seem to be supported in `no_python` mode.

I would be very interested to see how it could be implemented in Numba! Nearly only modification in the pure-Python reimplementation of Numpy? Can I look at examples of similar functions in Numba code?

user: paugier
issue_4705: state: open
title: Feature request: Support `str(<int>)` and more generally `str`.
body: This is my python code:
```python
import random
#         A B C D E F G H K J
myList = [0,1,2,3,4,5,6,7,8,9]

def scramble(aList):
  while True:
    randomlist = []
    newList = []
    length = len(aList)
    while length!=len(randomlist):
      rand = random.randint(0, length-1)
      if rand not in randomlist:
        randomlist.append(rand)
    for i in range(len(aList)):
      newList.append(aList[randomlist[i]])
    myList = newList
    GHF = (myList[6]*100 + myList[7]*10 +myList[5])
    JEF = (myList[9]*100 + myList[4]*10 +myList[5])
    AJF = (myList[0]*100 + myList[9]*10 +myList[5])
    JDE = (myList[9]*100 + myList[3]*10 +myList[4])*10
    FBD = (myList[5]*100 + myList[1]*10 +myList[3])*100
    add = (FBD+JDE+AJF)
    FCAKF= int(str(myList[5])+str(myList[2])+str(myList[0])+str(myList[8])+str(myList[5]))
    if (JEF*GHF)==FCAKF and len(str(JEF))==len(str(GHF))==3 and add==FCAKF:
      print('  ',GHF)
      print(' X',JEF)
      print('---------')
      print('  ',AJF)
      print(' ',JDE)
      print('',FBD)
      print('',FCAKF)
      break
scramble(myList)
```

====================================================================

This is the error:
```
Traceback (most recent call last):
  File "/Users/m3hdi/Documents/Python3/numba_test.py", line 38, in <module>
    scramble(myList)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/dispatcher.py", line 376, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/dispatcher.py", line 343, in error_rewrite
    reraise(type(e), e, None)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/six.py", line 658, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'str': cannot determine Numba type of <class 'type'>

File "Documents/Python3/numba_puzzle.py", line 26:
def scramble(aList):
    <source elided>
    add = (FBD+JDE+AJF)
    FCAKF= int(str(myList[5])+str(myList[2])+str(myList[0])+str(myList[8])+str(myList[5]))
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```
user: ghost
issue_4698: state: open
title: Serializing typed Lists and Dicts?
body: Question: I have preprocessed a large amount of data (Levenshtein matches, array locations, etc.) that I've stored as python object pickles. When my program runs, it performs operations on a subset of that data, and first goes through and pulls out the data needed by the later processing, gets the intersections of sets, etc.. I've sped the process up a bit using a numba njit method, but would like to 1) be able to run that method in parallel processes and 2) not have to import the python objects/loop through them each time the program runs to build the numba objects.

Multiprocessing can be accomplished using a python method as an intermediary between the pool and numba, but I am running this on Windows at the moment, which has spawned, rather than forked processes. Trying to read four copies of the pickled objects in/building the nested numba Lists and Dicts crashes my system.

How can you serialize, say, an object of type DictType[unicode_type,ListType[unicode_type]] or a ListType[reflected set(int64)] in order to reduce some of these costs? Trying to use pickle obviously results in an error that MemInfo pointers can't be pickled, and I've searched the source code for hours, seeing things like, boxing and unboxing, and reduce() but haven't made much headway figuring out what parameters like (typ, val, c) mean and making sense of it all. Can anyone help?
user: JackMcCoy
issue_4694: state: open
title: Default `None` argument treatment is different in type-inference and in lowering
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This code:

```python
from numba.extending import overload, overload_method
from numba import njit, types
import numpy as np
import traceback

@overload(np.mean)
@overload_method(types.Array, 'mean')
def array_mean(arr, axis=None):
    print('-' * 80)
    print("THERE", arr, axis)
    if axis is None or isinstance(axis, types.Omitted):
        traceback.print_stack()

        def mean_impl(arr, axis=None):
            print("JERE")

        return mean_impl
    else:
        def mean_impl(arr, axis=None):
            print("HERE")

        return mean_impl



@njit
def foo():
    return np.ones(10).mean()

foo()
```

Will print:

```
--------------------------------------------------------------------------------
THERE array(float64, 1d, C) None
  File "./numba/try_mean.py", line 30, in <module>
    foo()
  File "./numba/numba/dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "./numba/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "./numba/numba/dispatcher.py", line 768, in compile
    cres = self._compiler.compile(args, return_type)
  File "./numba/numba/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "./numba/numba/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "./numba/numba/dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "./numba/numba/compiler.py", line 528, in compile_extra
    return pipeline.compile_extra(func)
  File "./numba/numba/compiler.py", line 326, in compile_extra
    return self._compile_bytecode()
  File "./numba/numba/compiler.py", line 385, in _compile_bytecode
    return self._compile_core()
  File "./numba/numba/compiler.py", line 356, in _compile_core
    pm.run(self.state)
  File "./numba/numba/compiler_machinery.py", line 319, in run
    self._runPass(idx, pass_inst, state)
  File "./numba/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "./numba/numba/compiler_machinery.py", line 281, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "./numba/numba/compiler_machinery.py", line 268, in check
    mangled = func(compiler_state)
  File "./numba/numba/typed_passes.py", line 94, in run_pass
    state.locals)
  File "./numba/numba/typed_passes.py", line 66, in type_inference_stage
    infer.propagate()
  File "./numba/numba/typeinfer.py", line 943, in propagate
    errors = self.constraints.propagate(self)
  File "./numba/numba/typeinfer.py", line 148, in propagate
    constraint(typeinfer)
  File "./numba/numba/typeinfer.py", line 465, in __call__
    self.resolve(typeinfer, typevars, fnty)
  File "./numba/numba/typeinfer.py", line 485, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "./numba/numba/typeinfer.py", line 1354, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "./numba/numba/typing/context.py", line 199, in resolve_function_type
    res = self._resolve_user_function_type(func, args, kws)
  File "./numba/numba/typing/context.py", line 251, in _resolve_user_function_type
    return func.get_call_type(self, args, kws)
  File "./numba/numba/types/functions.py", line 210, in get_call_type
    out = template.apply(args, kws)
  File "./numba/numba/typing/templates.py", line 234, in apply
    sig = generic(args, kws)
  File "./numba/numba/typing/templates.py", line 809, in generic
    sig = self._resolve_impl_sig(typ, attr, args, kws)
  File "./numba/numba/typing/templates.py", line 756, in _resolve_impl_sig
    disp, sig_args = self._get_dispatcher(self.context, typ, attr, sig_args, sig_kws)
  File "./numba/numba/typing/templates.py", line 736, in _get_dispatcher
    pyfunc = cls._overload_func(*sig_args, **sig_kws)
  File "./numba/try_mean.py", line 12, in array_mean
    traceback.print_stack()
--------------------------------------------------------------------------------
THERE array(float64, 1d, C) omitted(default=None)
  File "./numba/try_mean.py", line 30, in <module>
    foo()
  File "./numba/numba/dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "./numba/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "./numba/numba/dispatcher.py", line 768, in compile
    cres = self._compiler.compile(args, return_type)
  File "./numba/numba/dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "./numba/numba/dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "./numba/numba/dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "./numba/numba/compiler.py", line 528, in compile_extra
    return pipeline.compile_extra(func)
  File "./numba/numba/compiler.py", line 326, in compile_extra
    return self._compile_bytecode()
  File "./numba/numba/compiler.py", line 385, in _compile_bytecode
    return self._compile_core()
  File "./numba/numba/compiler.py", line 356, in _compile_core
    pm.run(self.state)
  File "./numba/numba/compiler_machinery.py", line 319, in run
    self._runPass(idx, pass_inst, state)
  File "./numba/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "./numba/numba/compiler_machinery.py", line 281, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "./numba/numba/compiler_machinery.py", line 268, in check
    mangled = func(compiler_state)
  File "./numba/numba/typed_passes.py", line 380, in run_pass
    NativeLowering().run_pass(state) # TODO: Pull this out into the pipeline
  File "./numba/numba/typed_passes.py", line 325, in run_pass
    lower.lower()
  File "./numba/numba/lowering.py", line 179, in lower
    self.lower_normal_function(self.fndesc)
  File "./numba/numba/lowering.py", line 220, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "./numba/numba/lowering.py", line 245, in lower_function_body
    self.lower_block(block)
  File "./numba/numba/lowering.py", line 260, in lower_block
    self.lower_inst(inst)
  File "./numba/numba/lowering.py", line 303, in lower_inst
    val = self.lower_assign(ty, inst)
  File "./numba/numba/lowering.py", line 465, in lower_assign
    return self.lower_expr(ty, value)
  File "./numba/numba/lowering.py", line 927, in lower_expr
    res = self.lower_call(resty, expr)
  File "./numba/numba/lowering.py", line 719, in lower_call
    res = self._lower_call_normal(fnty, expr, signature)
  File "./numba/numba/lowering.py", line 898, in _lower_call_normal
    res = impl(self.builder, argvals, self.loc)
  File "./numba/numba/targets/base.py", line 1132, in __call__
    res = self._imp(self._context, builder, self._sig, args, loc=loc)
  File "./numba/numba/targets/base.py", line 1157, in wrapper
    return fn(*args, **kwargs)
  File "./numba/numba/typing/templates.py", line 790, in method_impl
    disp, sig_args = cls._get_dispatcher(typing_context, typ, attr, sig.args, {})
  File "./numba/numba/typing/templates.py", line 736, in _get_dispatcher
    pyfunc = cls._overload_func(*sig_args, **sig_kws)
  File "./numba/try_mean.py", line 12, in array_mean
    traceback.print_stack()
JERE
```

Showing that `None` is seen in typing. But, `Omitted(default=None)` is seen in lowering.
user: sklam
issue_4688: state: open
title: Add support for @classmethod in jitclass
body: ## Feature request

Is there a plan to support `@classmethod`s in `jitclass`?

`@classmethod`s are very useful to provide alternative initialization procedures.
One can get around them by defining a function, but it's not ideal.
user: GiorgioBalestrieri
issue_4676: state: open
title: CUDA decorator/compiler argument to set literal precision
body: I think this has been raised a few times but usually its in the context of converting every float to either a float32 or float64. If you want to do 32 bit operations (or anything other than 64 bit) with literals the current work around is to add np.TYPE32 to all literals in order to do 32 bit operations. The fact that literals almost always cause a cast to 64 often slows down kernels and does so in a very non-obvious way (I have seen a number of sample code snippets posted online where users add float64/int64 literals to float32/int32 inputs and don't realize that this is slowing down their code). It would be helpful if, in the cuda.jit decorator (or somewhere else perhaps), we could specify the precision of all literals in the kernel (the default can be 64 bit to maintain consistency with current code). I don't know how the python -> ptx is done but I would imagine that just setting all literals to a specific precision wouldn't be that hard (if someone can show me in Numba where this could be changed I can give it a try). If the default precision of a literal is changed, it also shouldn't cause any major problems (as far as I can tell) as, if an operation is performed on input data with the literal, it will just be cast up if necessary anyway.
user: uchytilc
labels: CUDA: CUDA related issue/PR
performance - run time: Performance issue occurring at run time.
issue_4665: state: open
title: Mod on uint64 near max values gives wrong result
body: Reproducible test case:
```
import numpy as np
import numba

def test_max_mod():
    return np.mod(np.uint64(np.iinfo(np.uint64).max), np.uint64(16)) 

@numba.jit
def test_max_mod_jit():
    return np.mod(np.uint64(np.iinfo(np.uint64).max), np.uint64(16)) 

test_max_mod(), test_max_mod_jit()
```
(15, 18446744073709551615)
```
numba.__version__
```
'0.45.1'

Took me quite some time to strip down the issue to this, for smaller values of uint64 mod works fine so only a fraction of results were broken.

Any suggestion for a workaround? (any bitwise right rotation or something)?
It was my first usage of numba and the speedup was great (>10x on GBs of data), but this prevents me using it...

user: miloslen
issue_4663: state: open
title: Accessing a numpy array defined in a module using the module name prefix fails in nopython mode
body: Suppose there is a module `nmod.py`:

```
import numpy as np
narr = np.array([1, 2, 5])
```

Then the following code works just fine in both _object_ and _nopython_ mode:

```
import numpy as np
from numba import jit
from nmod import narr
@jit(nopython=True)
def numba_test():
    return np.sum(narr)
print(numba_test())
```

Output:
`8`

However, accessing `narr `with module name prefix fails in  _nopython_ mode:

```
import numpy as np
from numba import jit
import nmod
@jit(nopython=True)
def numba_test():
    return np.sum(nmod.narr)
print(numba_test())
```

Output:
```
Traceback (most recent call last):
  File "C:\Users\User\venv\lib\site-packages\numba\errors.py", line 662, in new_error_context
    yield
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 258, in lower_block
    self.lower_inst(inst)
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 301, in lower_inst
    val = self.lower_assign(ty, inst)
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 459, in lower_assign
    return self.lower_expr(ty, value)
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 1009, in lower_expr
    impl = self.context.get_getattr(ty, expr.attr)
  File "C:\Users\User\venv\lib\site-packages\numba\targets\base.py", line 588, in get_getattr
    llval = self.get_constant(attrty, pyval)
  File "C:\Users\User\venv\lib\site-packages\numba\targets\base.py", line 510, in get_constant
    return self.get_constant_generic(None, ty, val)
  File "C:\Users\User\venv\lib\site-packages\numba\targets\base.py", line 500, in get_constant_generic
    return impl(self, builder, ty, val)
  File "C:\Users\User\venv\lib\site-packages\numba\targets\arrayobj.py", line 2383, in constant_array
    return context.make_constant_array(builder, ty, pyval)
  File "C:\Users\User\venv\lib\site-packages\numba\targets\base.py", line 1015, in make_constant_array
    data = cgutils.global_constant(builder, ".const.array.data", consts)
  File "C:\Users\User\venv\lib\site-packages\numba\cgutils.py", line 876, in global_constant
    module = builder_or_module.module
AttributeError: 'NoneType' object has no attribute 'module'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:/Users/User/.../ntest.py", line 9, in <module>
    print(numba_test())
  File "C:\Users\User\venv\lib\site-packages\numba\dispatcher.py", line 395, in _compile_for_args
    raise e
  File "C:\Users\User\venv\lib\site-packages\numba\dispatcher.py", line 352, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "C:\Users\User\venv\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Users\User\venv\lib\site-packages\numba\dispatcher.py", line 693, in compile
    cres = self._compiler.compile(args, return_type)
  File "C:\Users\User\venv\lib\site-packages\numba\dispatcher.py", line 76, in compile
    status, retval = self._compile_cached(args, return_type)
  File "C:\Users\User\venv\lib\site-packages\numba\dispatcher.py", line 90, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "C:\Users\User\venv\lib\site-packages\numba\dispatcher.py", line 108, in _compile_core
    pipeline_class=self.pipeline_class)
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 972, in compile_extra
    return pipeline.compile_extra(func)
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 390, in compile_extra
    return self._compile_bytecode()
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 903, in _compile_bytecode
    return self._compile_core()
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 890, in _compile_core
    res = pm.run(self.status)
  File "C:\Users\User\venv\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 266, in run
    raise patched_exception
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 257, in run
    stage()
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 764, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 703, in _backend
    lowered = lowerfn()
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 690, in backend_nopython_mode
    self.metadata)
  File "C:\Users\User\venv\lib\site-packages\numba\compiler.py", line 1143, in native_lowering_stage
    lower.lower()
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 177, in lower
    self.lower_normal_function(self.fndesc)
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 218, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 243, in lower_function_body
    self.lower_block(block)
  File "C:\Users\User\venv\lib\site-packages\numba\lowering.py", line 258, in lower_block
    self.lower_inst(inst)
  File "C:\Users\User\AppData\Local\Programs\Python\Python37\lib\contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\Users\User\venv\lib\site-packages\numba\errors.py", line 670, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "C:\Users\User\venv\lib\site-packages\numba\six.py", line 659, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
'NoneType' object has no attribute 'module'

File "ntest.py", line 8:
def numba_test():
    return np.sum(nmod.narr)
    ^

[1] During: lowering "$0.4 = getattr(value=$0.3, attr=narr)" at C:/Users/User/.../ntest.py (8)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.45.1.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```

In _object_ mode programs runs with the warning:

```
import numpy as np
from numba import jit
import nmod
@jit
def numba_test():
    return np.sum(nmod.narr)
print(numba_test())
```

Output:
```
C:/Users/User/.../ntest.py:5: NumbaWarning: 
Compilation is falling back to object mode WITH looplifting enabled because Function numba_test failed at nopython mode lowering due to: 'NoneType' object has no attribute 'module'

File "ntest.py", line 8:
def numba_test():
    return np.sum(nmod.narr)
    ^

[1] During: lowering "$0.4 = getattr(value=$0.3, attr=narr)" at C:/Users/User/.../ntest.py (8)
  @jit
C:\Users\User\venv\lib\site-packages\numba\compiler.py:742: NumbaWarning: Function "numba_test" was compiled in object mode without forceobj=True.

File "ntest.py", line 7:
# @jit(nopython=True)
def numba_test():
^

  self.func_ir.loc))
C:\Users\User\venv\lib\site-packages\numba\compiler.py:751: NumbaDeprecationWarning: 
Fall-back from the nopython compilation path to the object mode compilation path has been detected, this is deprecated behaviour.

For more information visit http://numba.pydata.org/numba-doc/latest/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit

File "ntest.py", line 7:
# @jit(nopython=True)
def numba_test():
^

  warnings.warn(errors.NumbaDeprecationWarning(msg, self.func_ir.loc))
8

```

Aliasing the module doesn't help:

```
import nmod as nm
...
    return np.sum(nm.narr)
```
Also tried different numpy functions with the same result.
user: serge-tochilov
issue_4647: state: open
title: help diagnosing a GPU performance issue
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I am coding a simple algorithm in numba and raw CUDA C using `cupy`. I am seeing a 3x performance difference, which is a lot. 

The code below outputs on my local P100:

```bash
$ python demo_cupy_brute_rawkernel.py 1000000
cupy+CUDA events: 11133.681315104166 ms
cupy+CUDA wall  : 15018.668174743652 ms
numba events: 34106.19140625 ms
numba wall  : 45484.97438430786 ms
```

Here is the code:

```python
import sys
import time

import cupy as cp
import numpy as np
from numba import cuda

source_code = """\
extern "C"{

__global__ void brute_force_pairs_kernel(
    float* x1, float* y1, float* z1, float* w1,
    float* x2, float* y2, float* z2, float* w2,
    float* rbins_squared, float* result,
    int n1, int n2, int nbins) {

    size_t start = threadIdx.x + blockIdx.x * blockDim.x;
    size_t stride = blockDim.x * gridDim.x;

    for (size_t i = start; i < n1; i += stride) {
        float px = x1[i];
        float py = y1[i];
        float pz = z1[i];
        float pw = w1[i];

        for (size_t j = 0; j < n2; j++) {
            float qx = x2[j];
            float qy = y2[j];
            float qz = z2[j];
            float qw = w2[j];

            float dx = px - qx;
            float dy = py - qy;
            float dz = pz - qz;
            float wprod = pw * qw;
            float dsq = dx * dx + dy * dy + dz * dz;

            int k = nbins - 1;
            while (dsq <= rbins_squared[k]) {
                atomicAdd(&(result[k-1]), wprod);
                k -= 1;
                if (k <= 0) break;
            }
        }
    }
}

}
"""

# compile and load CUDA kernel using CuPy
brute_force_pairs_kernel = cp.RawKernel(
    source_code, 'brute_force_pairs_kernel')

# parameters
blocks = 512
threads = 512
if len(sys.argv) > 1:
    npoints = int(sys.argv[1])
else:
    npoints = 100_000
n1 = npoints
n2 = npoints

# make the data
DEFAULT_RBINS_SQUARED = (np.logspace(
    np.log10(0.1/1e3), np.log10(40/1e3), 20)**2).astype(np.float32)
rng = np.random.RandomState(seed=42)
x1, y1, z1, w1 = rng.uniform(size=(4, n1)).astype(np.float32)
x2, y2, z2, w2 = rng.uniform(size=(4, n1)).astype(np.float32)

# array init
result = np.zeros_like(DEFAULT_RBINS_SQUARED)[:-1].astype(np.float32)

d_x1 = cp.asarray(x1, dtype=cp.float32)
d_y1 = cp.asarray(y1, dtype=cp.float32)
d_z1 = cp.asarray(z1, dtype=cp.float32)
d_w1 = cp.asarray(w1, dtype=cp.float32)

d_x2 = cp.asarray(x2, dtype=cp.float32)
d_y2 = cp.asarray(y2, dtype=cp.float32)
d_z2 = cp.asarray(z2, dtype=cp.float32)
d_w2 = cp.asarray(w2, dtype=cp.float32)

d_rbins_squared = cp.asarray(DEFAULT_RBINS_SQUARED, dtype=cp.float32)
d_result_cp = cp.asarray(result, dtype=cp.float32)

# for GPU timing using CuPy
start = cp.cuda.Event()
end = cp.cuda.Event()
timing_cp = 0
timing_cp_wall = 0

# running the kernel using CuPy's functionality
for i in range(4):
    if i > 0:  # warm-up not needed if using RawModule
        start.record()
        _s = time.time()
    brute_force_pairs_kernel(
        (blocks,), (threads,),
        (d_x1, d_y1, d_z1, d_w1,
         d_x2, d_y2, d_z2, d_w2,
         d_rbins_squared, d_result_cp,
         cp.int32(d_x1.shape[0]),
         cp.int32(d_x2.shape[0]),
         cp.int32(d_rbins_squared.shape[0]))
    )
    if i > 0:  # warm-up not needed if using RawModule
        end.record()
        end.synchronize()
        _e = time.time()
        timing_cp += cp.cuda.get_elapsed_time(start, end)
        timing_cp_wall += (_e - _s)

print('cupy+CUDA events:', timing_cp/3, 'ms')
print('cupy+CUDA wall  :', timing_cp_wall/3*1000, 'ms')
d_result_cp = d_result_cp.copy()


# for GPU timing using Numba
@cuda.jit
def count_weighted_pairs_3d_cuda(
        x1, y1, z1, w1, x2, y2, z2, w2, rbins_squared, result):
    start = cuda.grid(1)
    stride = cuda.gridsize(1)

    n1 = x1.shape[0]
    n2 = x2.shape[0]
    nbins = rbins_squared.shape[0]

    for i in range(start, n1, stride):
        px = x1[i]
        py = y1[i]
        pz = z1[i]
        pw = w1[i]
        for j in range(n2):
            qx = x2[j]
            qy = y2[j]
            qz = z2[j]
            qw = w2[j]
            dx = px-qx
            dy = py-qy
            dz = pz-qz
            wprod = pw*qw
            dsq = dx*dx + dy*dy + dz*dz

            k = nbins - 1
            while dsq <= rbins_squared[k]:
                cuda.atomic.add(result, k-1, wprod)
                k -= 1
                if k <= 0:
                    break


start = cuda.event()
end = cuda.event()
timing_nb = 0
timing_nb_wall = 0

d_x1 = cuda.to_device(x1.astype(np.float32))
d_y1 = cuda.to_device(y1.astype(np.float32))
d_z1 = cuda.to_device(z1.astype(np.float32))
d_w1 = cuda.to_device(w1.astype(np.float32))

d_x2 = cuda.to_device(x2.astype(np.float32))
d_y2 = cuda.to_device(y2.astype(np.float32))
d_z2 = cuda.to_device(z2.astype(np.float32))
d_w2 = cuda.to_device(w2.astype(np.float32))

d_rbins_squared = cuda.to_device(
    DEFAULT_RBINS_SQUARED.astype(np.float32))
d_result_nb = cuda.device_array_like(result.astype(np.float32))


# running the Numba jit kernel
# this works because CuPy arrays have the __cuda_array_interface__ attribute,
# which is accepted by Numba kernels, so you don't have to create the arrays
# again using Numba's API
for i in range(4):
    if i > 0:
        start.record()
        _s = time.time()
    count_weighted_pairs_3d_cuda[blocks, threads](
        d_x1, d_y1, d_z1, d_w1,
        d_x2, d_y2, d_z2, d_w2,
        d_rbins_squared, d_result_nb)
    if i > 0:
        end.record()
        end.synchronize()
        _e = time.time()
        timing_nb += cuda.event_elapsed_time(start, end)
        timing_nb_wall += (_e - _s)

print('numba events:', timing_nb/3, 'ms')
print('numba wall  :', timing_nb_wall/3*1000, 'ms')

# print(count_weighted_pairs_3d_cuda.inspect_types())

# check that the CUDA kernel agrees with the Numba kernel
assert cp.allclose(d_result_cp, d_result_nb, rtol=5E-4)
```

user: beckermr
labels: CUDA: CUDA related issue/PR
performance: performance related issue
issue_4635: state: open
title: np.argsort still slowing down by jit 
body: ```
@jit(nopython=True)
def f2(x):
    return np.argsort(np.argsort(x)) + 1.0

v1 = np.random.randn(10000)

%timeit f2(v1)
1.68 ms ± 13.5 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
%timeit f2.py_func(v1)
1.24 ms ± 11.6 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

np.__version__ : '1.17.2'
numba.__version__: '0.45.1'

user: isaac-you
labels: performance: performance related issue
issue_4632: state: open
title: Unable to broadcast argument 1 to output array
body: This code
```
@jit(nopython=True)
def _sgd_batch(learning_rate, w, xtrain, ytrain):
    for i in range(xtrain.shape[1]):
        wx = w*xtrain[:,i]
        error = wx - ytrain[:,i]
        for j in range(w.shape[0]):
            w[j,:] = w[j,:]-learning_rate*error[j]*np.transpose(xtrain[:,i])
    return w
```

throws a `ValueError: unable to broadcast argument 1 to output array` exception when called with the following parameters: ```learning_rate``` is a scalar, ```w``` is a 3x1000 matrix, xtrain is a 1000 x 10k matrix, and ytrain is a 3 x 100k matrix.  When I run it without ```@jit``` it works just fine.  It doesn't appear to have anything to do with `w` because reordering the parameters doesn't change anything.

There doesn't seem to be any google-discoverable documentation on this error message.  I'd be happy to write up a couple paragraphs if someone can explain to me what's going on and what causes this error message.  Again, without `@jit` it is fine so it's not an underlying Numpy broadcast problem.

Thanks,
Andrew
user: andrew-pomerance
labels: bug - miscompile: Bugs: miscompile
issue_4625: state: open
title: DUfunc ufunc methods don't work unless method already compiled
body: While investigating #4578 and #4504, I found out that DUfuncs created without signatures will throw an error when ufunc methods are called. I just found out that if a compiled method exists, the ufunc methods will work. Example:

```python
from numba import vectorize
import numpy as np

x = np.arange(10)
y = np.arange(10)[::-1]

@vectorize
def vec_no_sig(a, b):
    return a + b

# ufunc methods not working:

vec_no_sig.reduce(x)
# ---------------------------------------------------------------------------
# TypeError                                 Traceback (most recent call last)
# <ipython-input-2-0c5e4c1d85bc> in <module>
# ----> 1 vec_no_sig.reduce(x)

# TypeError: No loop matching the specified signature and casting was found 
# for ufunc vec_no_sig

vec_no_sig.outer(x, y)
# ---------------------------------------------------------------------------
# TypeError                                 Traceback (most recent call last)
# <ipython-input-3-08e6d706b1f6> in <module>
# ----> 1 vec_no_sig.outer(x, y)

# TypeError: ufunc 'vec_no_sig' not supported for the input types, and the 
# inputs could not be safely coerced to any supported types according to 
# the casting rule ''safe''

# Now, after compilation:
vec_no_sig(x, y)

# These work
vec_no_sig.reduce(x)
vec_no_sig.outer(x, y)
```

I think if no matching signature could be found for a compiled function inside a ufunc method call for a DUfunc, numba would try and compile one instead of bailing.
user: ivirshup
issue_4624: state: open
title: Support optional arguments axis, dtype and out for numpy.cumsum
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [y ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [y ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I somehow cannot use numpy.cumsum in no python mode.
Reproducer:
```
from numba import jit
import numpy as np

@jit(nopython=True)
def error():
    weights = np.ones((100, 100))
    np.cumsum(weights, 0, float, weights)

error()
```
user: yujianll
issue_4608: state: open
title: Accept overloaded functions as parameter
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

Related to https://github.com/numba/numba/issues/4602

Request: automatically jitting numba supported functions used in arguments for dispatcher.

For example:

```python
In [1]: from numba import njit

In [2]: import numpy as np

In [3]: @njit
   ...: def foo(fn, arr):
   ...:     return fn(arr)
   ...:

In [4]: @njit
   ...: def call_jitted(arr):
   ...:     return foo(np.sum, arr)
   ...:

In [5]: call_jitted(np.ones(4))  # works fine
Out[5]: 4.0
```

but the below fails:

```python
In [6]: foo(np.sum, np.ones(4))
...
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type pyobject
[1] During: typing of argument at <ipython-input-3-3df5be7cc64d> (3)

File "<ipython-input-3-3df5be7cc64d>", line 3:
def foo(fn, arr):
    return fn(arr)
    ^

```

This issue suggests that the above behavior inconsistency be fixed.
user: sklam
issue_4603: state: open
title: Property setter ignored
body: Although the docs state that property getters and setters are supported, the setter seems to be ignored in this example.

Without the `jitclass` decorator it behaves as expected &mdash; assigning to the property writes to the backing array.

```python
import numpy as np
import numba as nb

@nb.jitclass(( ('_data', nb.int64[:]), ))
class Demo:
    def __init__(self):
        self._data = np.array([0])

    @property
    def data(self):
        return self._data

    @data.setter
    def data(self, a):
        self._data[:] = a


if __name__ == '__main__':
    D = Demo()
    D.data = 1
    print(D.data)
```

With the decorator, we get a [long error message](https://github.com/numba/numba/files/3640401/demo_stderr.txt) ending with:

```
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast int64 to array(int64, 1d, A): %".16" = load i64, i64* %"__numba_val"

File "<string>", line 3:
<source missing, REPL/exec in use?>

During: lowering "(__numba_self_).data = __numba_val" at <string> (3)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.45.1.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```

This is on Win10, Numba 0.45.1 (conda latest).
user: joelkoerwer
issue_4600: state: open
title: Inconsistent error reporting for out of range indexing with parallel vs serial and lists vs arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the _master_ version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I'm observing inconsistent error behavior with parallel and serial out-of-range indexing dependent on whether operating on reflected list vs numpy array:

## Minimal reproducer

```
import numpy as np
from numba import njit, prange

@njit(parallel=False)
def out_of_bounds_serial(array):
    for i in prange(len(array)+1):
        array[i]

@njit(parallel=True)
def out_of_bounds_parallel(array):
    for i in prange(len(array)+1):
        array[i]

out_of_bounds_serial([1,2,3])                ## IndexError: getitem out of range
out_of_bounds_serial(np.array([1,2,3]))      ## No error
out_of_bounds_parallel([1,2,3])              ## No error
out_of_bounds_parallel(np.array([1,2,3]))    ## No error
```

user: rborder
issue_4590: state: open
title: Cache numba.cuda functions on repeated deserialization
body: As of https://github.com/numba/numba/issues/3026 , Numba kindly returns the same function when an equivalent bytestring is deserialized many times.  This is great for systems like Dask, which may send around the same numba function many times.

Currently, it looks like this isn't being done for numba.cuda functions, which ends up being a bottleneck in Dask + Numba GPU workloads.

cc @seibert 
user: mrocklin
labels: CUDA: CUDA related issue/PR
performance - run time: Performance issue occurring at run time.
issue_4587: state: open
title: Support njitting partial functions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

https://github.com/numba/numba/issues/2916 describes that `**kwargs` is not supported in njit functions.

```
In [10]: from numba import njit

In [11]: @njit
    ...: def f(func, args, kwargs):
    ...:     return func(*args, **kwargs)
    ...:

In [12]: @njit
    ...: def my_func(*args, **kwargs):
    ...:     return list(*args)
    ...:

In [13]: f(my_func, (1, 2, 3), {'a': 1, 'b': 2})
NotImplementedError: Failed in nopython mode pipeline (step: analyzing bytecode)
CALL_FUNCTION_EX with **kwargs not supported

In [14]: numba.__version__
Out[14]: '0.45.1'

```

Related to https://github.com/numba/numba/issues/4570, I am trying to use `partial` to bind the kwargs earlier.

```
In [23]: from functools import partial

In [24]: def my_func(*args, **kwargs):
    ...:     return list(args)
    ...:

In [25]: my_func_partial = partial(my_func, **{'a':2})

In [26]: njit(my_func_partial)

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-26-6bdaac92077c> in <module>
----> 1 njit(my_func_partial)

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/decorators.py in njit(*args, **kws)
    222         warnings.warn('forceobj is set for njit and is ignored', RuntimeWarning)
    223     kws.update({'nopython': True})
--> 224     return jit(*args, **kws)
    225
    226

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/decorators.py in jit(signature_or_function, locals, target, cache, pipeline_class, **options)
    159                    targetoptions=options, **dispatcher_args)
    160     if pyfunc is not None:
--> 161         return wrapper(pyfunc)
    162     else:
    163         return wrapper

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/decorators.py in wrapper(func)
    175         disp = dispatcher(py_func=func, locals=locals,
    176                           targetoptions=targetoptions,
--> 177                           **dispatcher_args)
    178         if cache:
    179             disp.enable_caching()

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in __init__(self, py_func, locals, targetoptions, impl_kind, pipeline_class)
    581
    582         _DispatcherBase.__init__(self, arg_count, py_func, pysig, can_fallback,
--> 583                                  exact_match_required=False)
    584
    585         functools.update_wrapper(self, py_func)

/anaconda3/envs/pandas-2s-dev/lib/python3.7/site-packages/numba/dispatcher.py in __init__(self, arg_count, py_func, pysig, can_fallback, exact_match_required)
    207
    208         argnames = tuple(pysig.parameters)
--> 209         default_values = self.py_func.__defaults__ or ()
    210         defargs = tuple(OmittedArg(val) for val in default_values)
    211         try:

AttributeError: 'functools.partial' object has no attribute '__defaults__'
```

Is there a better workaround for what I am trying to accomplish?
user: mroeschke
issue_4585: state: open
title: Strange NumbaPerformanceWarning for numpy @ operator.
body: I am using the `Numba-0.45.1` with `python-3.7.3`

```python
import numpy as np

from numba import njit


@njit
def do_dot():
    X = np.asfortranarray(np.ones((3, 4)))
    B = np.ones((4, 5))
    X[:, :] @ B[:, :]
    X @ B


if __name__ == '__main__':
    do_dot()
```

Run the python program above, `X[:, :] @ B[:, :]` will raise `NumbaPerformanceWarning`, while `X @ B` raise nothing. The behavior is very strange.
```
test.py:10: NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 2d, A))
  X[:, :] @ B[:, :]
/usr/local/lib/python3.7/site-packages/numba/typing/npydecl.py:967: NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 2d, A))
  warnings.warn(NumbaPerformanceWarning(msg))
```
user: EthanZhangYi
labels: performance: performance related issue
issue_4584: state: open
title: Typed list of arrays much slower than a reflected list
body: I am using Python 3.6.8 with Numba 0.45.1. The following (very contrived) example demonstrates the problem:

```python
import numpy as np
from numba import njit
from numba.typed import List
import time

def make_array_lists(shapes):

    typed_list = List()
    reflected_list = []

    for shape in shapes:
        typed_list.append(np.zeros(shape, dtype=np.float64))
        reflected_list.append(np.zeros(shape, dtype=np.float64))

    return typed_list, reflected_list

@njit(cache=True)
def mutate_array_list(array_list):

    for j in range(len(array_list)):
        dim0, dim1 = array_list[j].shape
        for row in range(dim0):
            for col in range(dim1):
                array_list[j][row, col] += 1


if __name__ == "__main__":

    array_shapes = [(200,200), (300,300), (400,400)]
    nrun = 1000

    typed_list, reflected_list = make_array_lists(array_shapes)

    t0 = time.time()
    [mutate_array_list(typed_list) for i in range(nrun)]
    average_time = (time.time() - t0)/nrun
    print("Typed list took {:.6f} seconds per run.".format(average_time))

    t0 = time.time()
    [mutate_array_list(reflected_list) for i in range(nrun)]
    average_time = (time.time() - t0)/nrun
    print("Reflected list took {:.6f} seconds per run.".format(average_time))
```

The output of the above is:

```
Typed list took 0.014759 seconds per run.
Reflected list took 0.000316 seconds per run.
```
user: JSKenyon
labels: performance: performance related issue
issue_4580: state: open
title: Incompatible shape for array on vector function
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

## Bug

I have the following helper function to vectorize a 2D matrix. If I run it without `numba` it works well. 

```
def mat2vec(matrix):
  
  #Return vectorised matrix
  return(matrix.transpose().reshape(matrix.shape[0]*matrix.shape[1],1))

# Example:
matrix = np.random.randn(3,3)
print(matrix)
print(mat2vec(matrix))
```

If I run it with `@numba.jit(nopython=True)` prepended to the function I get:

```
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
<ipython-input-46-bce81c0a0a5c> in <module>()
      8 matrix = np.random.randn(3,3)
      9 print(matrix)
---> 10 print(mat2vec(matrix))

NotImplementedError: incompatible shape for array
```

Apologies if this is documented behaviour/a non-issue and I have misunderstood but I cannot work out why this happens.
user: TomMaullin
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_4563: state: open
title: Unicode Array codegen triggers LLVM bug on PPC64LE
body: For reasons unknown, the unicode array implementation triggers an instruction selection bug in LLVM 7.1.0.  (Due to other bugs, we can't use LLVM 8 with ppc64le)  The errors generated looks like this:
```
python: /home/buildbot/miniconda2/conda-bld/llvmdev_1557502076934/work/lib/Target/PowerPC/PPCISelLowering.cpp:5902: llvm::SDValue llvm::PPCTargetLowering::LowerCall_64SVR4(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, bool, bool, const llvm::SmallVectorImpl<llvm::ISD::OutputArg>&, const llvm::SmallVectorImpl<llvm::SDValue>&, const llvm::SmallVectorImpl<llvm::ISD::InputArg>&, const llvm::SDLoc&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::ImmutableCallSite) const: Assertion `HasParameterArea && "Parameter area must exist to pass an argument in memory."' failed.
```
Later, these tests are reported as crashing:
```
multiprocessing.context.TimeoutError: Tests didn't finish before timeout (or crashed):
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_contains_getitem2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_equal_getitem_value'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_hash'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_notequal_getitem_value'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_add'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_center1'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_center2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_endswith'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_find'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_iadd'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_ljust1'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_ljust2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_lstrip1'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_lstrip2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_rjust1'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_rjust2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_rstrip1'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_rstrip2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_split2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_split3'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_startswith'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_strip1'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_strip2'
- 'numba.tests.test_unicode_array.TestUnicodeArray.test_return_zfill'
```

For now we are going to skip these tests on ppc64le and include a message in the release notes.  We will need to follow up and see if maybe LLVM 9 solves this (and the other) issues, or try to bisect which part of the codegen is producing the problematic pattern and try fiddling with instruction ordering to avoid it.
user: seibert
labels: llvm: LLVM related issues
issue_4552: state: open
title: datetimes don't implement __hash__
body: Datetimes don't have a hash in Numba, but they do in NumPy. It should be simple to fix this: Implement the hash as `hash(dt.view(np.int64))`.

Reproducer:

```python
import numpy as np
import numba as nb

def dt_test(x):
    a = set()
    a.add(x)

dt_test(np.datetime64(0, 'ms')) # Works

dt_test_nb = nb.njit(dt_test)
dt_test_nb(0) # Works
dt_test_nb(np.datetime64(0, 'ms')) # Doesn't
```

If someone is willing to give me some pointers I'd be happy to make a PR to fix this.
user: hameerabbasi
labels: good second issue: A good issue for second time contributors
bug - failure to compile: Bugs: failed to compile valid code
issue_4549: state: open
title: Disabling on-disk cache
body: Although `NUMBA_CACHE_DIR` allows us to move the cache directory to another location, I think that for HPC systems we actually want to have a mechanism for disabling caching completely.  We sometimes run mpi4py applications with >100K processes, and it is much better to have all those processes independently spend a few seconds compiling things rather than trying to read them from disk.

Is there any hope of a "`NUMBA_CACHE_DISABLE`" switch to forcibly override any `cache=True` options globally?

_Originally posted by @tskisner in https://github.com/numba/numba/issues/3470#issuecomment-530038481_
user: sklam
issue_4546: state: open
title: Using Numba to generate LLVM/NVVM IR for different targets
body: ## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

In the [Remote Backend Compiler project (RBC)](https://github.com/xnd-project/rbc), the numba package is used to convert Python functions to LLVM/NVVM IR format that are used by an execution server (OmnisciDB, for instance) to compile and run the corresponding code on CPU and CUDA devices. Since the CUDA execution model is implemented within the execution server, numba is used for producing function definitions in LLVM IR (for CPU targets) or NVVM IR (for CUDA device targets) formats. As a UI, RBC provides a factory of Python function decorators that is analogous to `numba.jit(nopython=True)` but that handles only the LLVM/NVVM IR generation step, plus code transmissions to the execution server. Note that dispatching, machine code generation, and execution are all handled by the execution server (that is, numba implementation of the CUDA execution model is not used).

The aim of this issue is to find a code path in numba to facilitate the LLVM/NVVM IR generation for the RBC model described above. The current status is as follows.

In RBC, `numba.targets.registry.cpu_target` is used as the entry point for LLVM IR generation (see [compile_to_LVVM](https://github.com/xnd-project/rbc/blob/master/rbc/irtools.py#L36) function). This has worked out great as it supports `njit` extensions like operator `overload`, etc. For NVVM IR generation, using `numba.cuda.descriptor.CUDATargetDesc` turned out to be too limited. For instance, overloading Python operators is not supported/implemented for CUDA targets.

As a temporary workaround to the NVVM IR generation limitations, `numba.targets.registry.cpu_target` can be used: the LLVM IR is turned to NVVM IR by resetting triple and data_layout to the corresponding device-specific values. However, this workaround is problematic as the generated LLVM IR may not be legal NVVM IR.

Thoughts? Suggestions?
user: pearu
issue_4543: state: open
title: Request Numba to be able to accept keyword args with Print
body: Especially to enable Flushing a Print statement.  But also end=' ' would be useful.  Thanks.
user: phedwards
issue_4542: state: open
title: numba doesn't raise exception for broadcast error with += 
body: Originally from https://github.com/numba/numba/pull/4432#issuecomment-527571792

```py
>>> def test1(a, b):
...     a += b
>>> def test2(a, b):
...     return a + b
>>> @njit
... def test1_jit(a, b):
...     a += b
>>> @njit
... def test2_jit(a, b):
...     return a + b
>>> test1(np.empty((3, 4)), np.empty((3, 5)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in test1
ValueError: operands could not be broadcast together with shapes (3,4) (3,5) (3,4)
>>> test2(np.empty((3, 4)), np.empty((3, 5)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in test2
ValueError: operands could not be broadcast together with shapes (3,4) (3,5)
>>> test1_jit(np.empty((3, 4)), np.empty((3, 5)))
>>> test2_jit(np.empty((3, 4)), np.empty((3, 5)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unable to broadcast argument 1 to output array
File "<stdin>", line 3,
```

The issue is `test1_jit`, which should raise an exception.

As an aside, the error line for `test2_jit` is messed up somehow. 
user: asmeurer
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_4537: state: open
title: Function arguments and key arguments lost with @vectorize
body: ## Feature request

Say I have a function
```
def function(a, b):
   return a + b
```
when I use my IDE, or hit Shift+Tab I get
```
Signature: function(a, b)
Docstring: <no docstring>
File:      ~/Desktop/<ipython-input-13-5d21c0b6520b>
Type:      function
```

However, when I decorate the function with `@vectorize` this handy information gets lost (i.e. the number of arguments and their names:
```
Call signature:  function(*args, **kwargs)
Type:            DUFunc
String form:     <numba._DUFunc 'function'>
File:            ~/dev/python36/lib/python3.6/site-packages/numba/npyufunc/dufunc.py
Docstring:       <no docstring>
Class docstring:
Dynamic universal function (DUFunc) intended to act like a normal
Numpy ufunc, but capable of call-time (just-in-time) compilation
of fast loops specialized to inputs.
```

Would it be possible to maintain this information? Particularly when a user imports sets of functions from a library, it's nice to have this information when typing...

Thanks!
user: fferroni
labels: discussion: An issue requiring discussion
issue_4535: state: open
title: `while True:` causes 'missing Environment'
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

The presence of `while True` causes a `RuntimeError: missing Environment`. In the example below, `test()` works but `test2()` causes the error. 

```
from numba import njit

@njit
def test():
    1+1

@njit
def test2():
    while True:
        1 + 1
```

- [x ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).



<!--


-->

user: rprechelt
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_4531: state: open
title: so slow,why!
body: I try to write NMS in faster-rcnn with numba,and vs with cupy,but I find that numba slow 10X vs cupy,why?
This is my code:
```
from __future__ import absolute_import
from numba import guvectorize,vectorize,cuda
import numpy as np
import numba as nb
import torch
from _nms_gpu_post import _nms_gpu_post
@cuda.jit(device=True)
def DIVUP(m,n):
     return ((m) // (n) + ((m) % (n) > 0))

@cuda.jit(device=True)   
def devIoU(bbox_a,bbox_b):
    top = max(bbox_a[0], bbox_b[0])
    bottom = min(bbox_a[2], bbox_b[2])
    left = max(bbox_a[1], bbox_b[1])
    right = min(bbox_a[3], bbox_b[3])
    height = max(bottom - top, 0)
    width = max(right - left, 0)
    area_i = height * width
    area_a = (bbox_a[2] - bbox_a[0]) * (bbox_a[3] - bbox_a[1])
    area_b = (bbox_b[2] - bbox_b[0]) * (bbox_b[3] - bbox_b[1])
    return area_i / (area_a + area_b - area_i)

@cuda.jit
def nms_kernel(n_bbox, dev_bbox,dev_mask):
    thresh=0.7
    row_start = cuda.blockIdx.y
    col_start = cuda.blockIdx.x
    threadsPerBlock =64
    row_size =min(n_bbox - row_start * threadsPerBlock, threadsPerBlock)
    col_size =min(n_bbox - col_start * threadsPerBlock, threadsPerBlock)

    block_bbox=cuda.shared.array((256),dtype=nb.float32)
    if  cuda.threadIdx.x < col_size:
        block_bbox[cuda.threadIdx.x * 4 + 0] =dev_bbox[(threadsPerBlock * col_start + cuda.threadIdx.x) * 4 + 0]
        block_bbox[cuda.threadIdx.x * 4 + 1] =dev_bbox[(threadsPerBlock * col_start + cuda.threadIdx.x) * 4 + 1]
        block_bbox[cuda.threadIdx.x * 4 + 2] =dev_bbox[(threadsPerBlock * col_start + cuda.threadIdx.x) * 4 + 2]
        block_bbox[cuda.threadIdx.x * 4 + 3] =dev_bbox[(threadsPerBlock * col_start + cuda.threadIdx.x) * 4 + 3]
    
    cuda.syncthreads()

    if  cuda.threadIdx.x < row_size:
        cur_box_idx = threadsPerBlock * row_start + cuda.threadIdx.x
        cur_box = dev_bbox[cur_box_idx * 4:cur_box_idx * 4+4]
        i = 0
        t = np.int64(0)
        
        start = 0
        if row_start == col_start:
            start = cuda.threadIdx.x + 1
        
        for  i in range( start ,col_size ):
            if devIoU(cur_box, block_bbox [i * 4:i * 4+4]) >= thresh:
                t |= np.int64(1)<< i
            
        col_blocks = DIVUP(n_bbox, threadsPerBlock)
        dev_mask[cur_box_idx * col_blocks + col_start] = t
```

Then,test in jupyter:
```
bbox=np.load("bbox.npy")
n_bbox = bbox.shape[0]
threads_per_block = 64
col_blocks = np.ceil(n_bbox / threads_per_block).astype(np.int32)
blocks = (col_blocks, col_blocks, 1)
threads = (threads_per_block, 1, 1)

mask_dev = cuda.device_array((n_bbox * col_blocks,), dtype=np.uint64)
bbox=bbox.reshape(-1)
bbox =cuda.to_device(bbox)

%timeit nms_kernel[blocks, threads](n_bbox, bbox, mask_dev)
```
The result is :
```
15.2 ms ± 108 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
``` 
But I try with cuoy,the result is:
```
1.32 ms ± 15 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```
What is the problem?
user: fmscole
labels: CUDA: CUDA related issue/PR
performance - run time: Performance issue occurring at run time.
issue_4528: state: open
title: Faster array indexing (closer to what Numpy can do)
body: ## Feature request

- [x] I am using the latest released version of Numba (0.45.1).
- [x] I have included below a minimal working reproducer


### Problem

First reported [here](https://stackoverflow.com/questions/57810101/how-can-i-make-numba-access-arrays-as-fast-as-numpy-can?noredirect=1#comment102053602_57810101).

Basically Numpy is 60% faster than Numba for array access/modification on large arrays. I was wondering if there were low hanging fruits there to close the gap. I illustrate the problem below with array copy but it should be understood that copy is not actually the focus.

### Minimum working example

```
import numpy as np
import numba as nb

def copyto_numpy(a, b):
    np.copyto(a, b, 'no')

@nb.jit(nopython=True, fastmath=True, nogil=True)
def copyto_numba(a, b):
    N = len(a)
    for i in range(N):
        b[i] = a[i]

@nb.jit(nopython=True, fastmath=True, nogil=True)
def copyto_numba2(a, b):
    b[:] = a

a = np.random.rand(2**20)
b = np.empty_like(a)
copyto_numpy(a, b)
copyto_numba(a, b)
copyto_numba2(a, b)

%timeit copyto_numpy(a, b)
%timeit copyto_numba(a, b)
%timeit copyto_numba2(a, b)
```
```
1.23 ms ± 11 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
1.99 ms ± 14.9 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
1.97 ms ± 48.5 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

I understand that ``np.copyto`` is highly optimised, however the underlying mechanism (vectorized array access) is pretty straight forward and there might be optimisation opportunities ready to be seized.
user: gdonval
labels: performance: performance related issue
issue_4524: state: open
title: Numba fails to understand float('inf')
body: Numba does not understand the code `float('inf')`

Running the following code
```
from numba import njit

@njit
def my_inf():
    return float('inf')

x = my_inf()
```
returns
```
TypingError: Invalid use of Function(<class 'float'>) with argument(s) of type(s): (Literal[str](inf))
 * parameterized
In definition 0:
    TypeError: float() only support for numbers
    raised from C:\Users\Luca.amerio\AppData\Local\Continuum\anaconda3\lib\site-packages\numba\typing\builtins.py:880
In definition 1:
    TypeError: float() only support for numbers
    raised from C:\Users\Luca.amerio\AppData\Local\Continuum\anaconda3\lib\site-packages\numba\typing\builtins.py:880
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<class 'float'>)
[2] During: typing of call at C:/Users/Luca.amerio/Documents/GitLab/Surface pressure mapping and modal integration/numba_bug.py (13)
```

The "problem" is that `float('inf')` is the **only** native python way to obtain infinity.

At the moment, the only workaround is to use the `numpy.inf`. The following code is indeed working
```
from numba import njit
from numpy import inf

@njit
def my_inf():
    return inf

x = my_inf()
```
user: LucaAmerio
labels: good second issue: A good issue for second time contributors
issue_4522: state: open
title: jitclass vs njit decorator performance
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I'm working with @jreback and @DiegoAlbertoTorres to use numba in pandas for rolling operations. I've noticed my implementation that uses `jitclass` is slower than just using a single `njit` function. 

The performance comparisons can be seen in these ASV benchmarks in https://github.com/twosigma/pandas/pull/21#issuecomment-526962495. TLDR: My `jitclass` implementation is about 4x slower than my single `njit` implementation (and the `njit` implementation is 2x slower than pandas cython implementation).

Is there any performance tips to close the gap between `jitclass` and `njit` functions? https://github.com/numba/numba/issues/2166#issuecomment-413228860 mentions attribute access. `nogil` access in `njit`? Maybe #4055 is related?

I've attached my implementations below (as simple as I could make them).

Single `njit` rolling mean function:

```
import numba
import numpy as np

aggregation_signature = (numba.float64[:], numba.int64[:], numba.int64[:], numba.int64)

@numba.njit(aggregation_signature, nogil=True, parallel=True)
def rolling_mean_method(
    values: np.ndarray,
    begin: np.ndarray,
    end: np.ndarray,
    minimum_periods: int,
) -> np.ndarray:
    """Perform a generic rolling aggregation"""
    result = np.empty(len(begin))
    previous_start = -1
    previous_end = -1
    count = 0
    total = 0
    for i, (start, stop) in enumerate(zip(begin, end)):
        if previous_start == -1 and previous_end == -1:
            # First aggregation over the values
            for j in numba.prange(values[start:stop].shape[0]):
                value = values[j]
                if not np.isnan(value):
                    count += 1
                    total += value
        else:
            # Subsequent aggregations are calculated based on prior values
            for value in values[previous_start : start]:
                if not np.isnan(value):
                    count -= 1
                    total -= value
            for value in values[previous_end : stop]:
                if not np.isnan(value):
                    count += 1
                    total += value
        previous_start = start
        previous_end = stop
        val = np.nan
        if count and count >= minimum_periods:
            val = total / count
        result[i] = val
    return result
```

Two `jitclass` routines with a top level `njit` function:

```
import numba
import numpy as np

agg_type = numba.deferred_type()

base_aggregator_spec = (
    ("values", numba.float64[:]),
    ("min_periods", numba.uint64),
    ("agg", agg_type),
    ("previous_start", numba.int64),
    ("previous_end", numba.int64),
)

@numba.jitclass(base_aggregator_spec)
class SubtractableAggregator:
    def __init__(self, values: np.ndarray, min_periods: int, agg) -> None:
        self.values = values
        self.min_periods = min_periods
        self.agg = agg
        self.previous_start = -1
        self.previous_end = -1

    def query(self, start: int, stop: int) -> Optional[Scalar]:
        """Compute a value based on changes in bounds."""
        if self.previous_start == -1 and self.previous_end == -1:
            # First aggregation over the values
            for value in self.values[start:stop]:
                self.agg.step(value)
        else:
            # Subsequent aggregations are calculated based on prior values
            for value in self.values[self.previous_start : start]:
                self.agg.invert(value)
            for value in self.values[self.previous_end : stop]:
                self.agg.step(value)
        self.previous_start = start
        self.previous_end = stop
        if self.agg.count >= self.min_periods:
            return self.agg.finalize()
        return np.nan

mean_spec = (("count", numba.uint64), ("total", numba.float64))

@numba.jitclass(mean_spec)
class Mean:
    def __init__(self) -> None:
        self.count = 0
        self.total = 0

    def step(self, value) -> None:
        if not np.isnan(value):
            self.count += 1
            self.total += value

    def invert(self, value) -> None:
        """Used only in subtractable kernels."""
        if not np.isnan(value):
            self.count -= 1
            self.total -= value

    def finalize(self) -> Optional[float]:
        if not self.count:
            return None
        return self.total / self.count

    def make_aggregator(self, values: np.ndarray, min_periods: int):
        aggregator = SubtractableAggregator(values, min_periods, self)
        return aggregator

agg_type.define(Mean.class_type.instance_type)

aggregation_signature = (numba.float64[:], numba.int64[:], numba.int64[:], numba.int64)

@numba.njit(aggregation_signature, nogil=True, parallel=True)
def rolling_mean_class(
    values: np.ndarray,
    begin: np.ndarray,
    end: np.ndarray,
    minimum_periods: int,
) -> np.ndarray:
    """Perform a generic rolling aggregation"""
    aggregator = Mean().make_aggregator(values, minimum_periods)
    result = np.empty(len(begin))
    for i, (start, stop) in enumerate(zip(begin, end)):
        result[i] = aggregator.query(start, stop)
    return result
```
user: mroeschke
labels: performance: performance related issue
issue_4521: state: open
title: Document how to use tuples with `numba.typed.List` and `numba.typed.Dict`
body: ## Feature request

Right now, the docs for `numba.typed.Dict` say that:

> Acceptable key/value types include but are not limited to: unicode strings, arrays, scalars, tuples.

But there are no examples of how to actually use it with tuples! I couldn't find how to construct a numba "tuple" class -- i had hoped that:
```python
numba.typed.Dict.empty(
    key_type=(numba.types.unicode_type, numba.types.int32), 
    value_type=numba.types.float32, 
)
```

would work, but that fails at runtime (constructing the dictionary works fine, but actually inserting anything into it fails).

I ended up just using `numba.typeof` instead, but it'd be nice to have an example in the documentation!

(Thanks for this great feature BTW! This massively expands the places where I can use Numba!)
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: alanhdu
issue_4515: state: open
title: Segfault when importing numba in conda environment
body: While trying to figure out what is causing https://github.com/lmcinnes/pynndescent/issues/70, I've realized something very strange.

Importing numba causes a segfault:
```
> python -c 'import numba' 
zsh: segmentation fault (core dumped)  python -c 'import numba'
```

However, this only happens in a conda environment. I can get this segfault consistently by setting up the environment like this:

```
conda create --name tmp python=3.7.4
conda activate tmp
pip install numba
python -c 'import numba'  # segfault
```

However, if I set up the environment using `virtualenv`, everything is fine:

```
virtualenv venv
source venv/bin/activate
pip install numba
python -c 'import numba'  # NO segfault
```

In both cases, the exact same packages are installed

```
> pip freeze
llvmlite==0.29.0
numba==0.45.1
numpy==1.17.1
```

Additionally, `llvmlite` doesn't seem to be the problem, since I can run `python -c 'import llvmlite'` without segfaulting.

At first, I suspected this had something to do with the new numpy version since it started failing at about the same time as the 1.17 release, but I can reproduce the segfault by downgrading numpy both to 1.16.4 and 1.15.4, so the issue must lie in numba somewhere.

I'm running Arch Linux x86_64 using Kernel: 5.2.11-arch1-1-ARCH.
user: pavlin-policar
labels: wheels: Issue with wheels
bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_4514: state: open
title: Unable to use typed.Dict with jitclass?
body: Here's an example:

```python
import numba as nb
from numba.types import DictType
from numba.typed import Dict

@nb.jitclass({
    'x': nb.int64,
})
class Foo:
    def __init__(self, x):
        self.x = x
        
@nb.jitclass({
    'y': DictType(nb.int64, Foo), 
})
class Bar:
    def __init__(self):
        self.y = Dict.empty(key_type=nb.int64, value_type=Foo)
        
Bar()
```

which results in

```python
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.typeinfer.CallConstraint object at 0x7f44052766a0>.
Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast DictType[int64,jitclass.Foo#7f440522cf98<x:int64>] to DictType[int64,<class 'numba.jitclass.base.Foo'>]: %".66" = load {i8*, i8*}, {i8*, i8*}* %"$0.7"

File "<ipython-input-27-c05e523fcce9>", line 13:
    def __init__(self):
        self.y = Dict.empty(key_type=nb.int64, value_type=Foo)
        ^

[1] During: lowering "(self).y = $0.7" at <ipython-input-27-c05e523fcce9> (13)
[2] During: resolving callee type: jitclass.Bar#7f44052646a0<y:DictType[int64,<class 'numba.jitclass.base.Foo'>]>
[3] During: typing of call at <string> (3)
```

Also, it doesn't seem possible to simply create `Dict.empty()` where value type is a jitclass:

```python
>>> Dict.empty(key_type=nb.int64, value_type=Foo)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type pyobject
[1] During: typing of argument at .../numba/typed/typeddict.py (20)

File ".../numba/typed/typeddict.py", line 20:
def _make_dict(keyty, valty):
    return dictobject._as_meminfo(dictobject.new_dict(keyty, valty))
    ^
```
user: aldanor
issue_4507: state: open
title: Call cuda code From Device Function?
body: My project use Cuda to accelerate via Numba, and now has some performance issues. Is there an convient way to call cuda lib(eg. [cuBLAS](https://docs.nvidia.com/cuda/cublas/index.html), [cub](https://github.com/NVlabs/cub), etc.) from device function? 
1. load the cuda code as string, like the pycuda
2. pack these cuda funtion as so(dll)file, and wrap them  like the numba.cuda.cudadrv source code
 
or any other feasible sulotion?  
I have been reading the Numba's doc and did not get a clue. I also tried to read Numba's source code, but it may take sometime to digest the whole python to llvm process. Any hints will be appreciated.
user: zhengle2008
labels: CUDA: CUDA related issue/PR
issue_4505: state: open
title: Trouble converting between list and array with string values
body: Numba doesn't currently allow converting from a typed list of strings to an array of strings or from and array of strings to a typed list of strings. I think allowing that would be useful.

Here's the error from converting an array of unicode to a typed list:

```python
import numba
import numpy as np

@numba.njit
def foo(x):
    return list(x)

foo(np.array(list("abc")))
```

The full resulting traceback is about 500 lines, so I've put it [in a gist](https://gist.github.com/ivirshup/50c966dd031a89b9bde055403aadb09e), but here's the last bit:

```python

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Failed in nopython mode pipeline (step: nopython mode backend)
<numba.datamodel.models.UnicodeCharSeq object at 0x12121cef0>

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/listobj.py", line 464:
    def list_impl(iterable):
        res = []
        ^

[1] During: lowering "$0.1 = build_list(items=[])" at /usr/local/lib/python3.7/site-packages/numba/targets/listobj.py (464)
[2] During: lowering "$0.3 = call $0.1(x, func=$0.1, args=[Var(x, <ipython-input-1-9ba5acf21b48> (6))], kws=(), vararg=None)" at <ipython-input-1-9ba5acf21b48> (6)
```

For converting a list to an array:

```python
@numba.njit 
def baz(x): 
    return np.array(x)

baz(list("abc"))
```

<details>
<summary> Traceback </summary>

```python
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-17-0e3e46e565a7> in <module>
----> 1 baz(list("abc"))

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375 
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344 
    345         argtypes = []

/usr/local/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function array>) with argument(s) of type(s): (reflected list(unicode_type))
 * parameterized
In definition 0:
    NotImplementedError: unicode_type cannot be represented as a Numpy dtype
    raised from /usr/local/lib/python3.7/site-packages/numba/numpy_support.py:150
In definition 1:
    NotImplementedError: unicode_type cannot be represented as a Numpy dtype
    raised from /usr/local/lib/python3.7/site-packages/numba/numpy_support.py:150
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<built-in function array>)
[2] During: typing of call at <ipython-input-16-1850252d5042> (3)


File "<ipython-input-16-1850252d5042>", line 3:
def baz(x):
    return np.array(x)
    ^

```

</details>

I think this is related to not being able to use the elements of a string np.array as keys in a typed dict.

```python
@numba.njit
def bar(x):
    d = {}
    for k, v in zip(x, np.arange(len(x))):
        d[k] = v
    return d

bar(np.array(list("abc")))
```

<details>
<summary> Traceback </summary>

```python
TypingError                               Traceback (most recent call last)
<ipython-input-13-610c1321b729> in <module>
----> 1 bar(np.array(list("abc")))

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375 
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344 
    345         argtypes = []

/usr/local/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function setitem>) with argument(s) of type(s): (DictType[undefined,undefined], [unichr x 1], int64)
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function hash>) with argument(s) of type(s): ([unichr x 1])
 * parameterized
In definition 0:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute '__hash__' of type [unichr x 1]

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

[1] During: typing of get attribute at /usr/local/lib/python3.7/site-packages/numba/targets/hashing.py (64)

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

    raised from /usr/local/lib/python3.7/site-packages/numba/typeinfer.py:927
In definition 1:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute '__hash__' of type [unichr x 1]

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

[1] During: typing of get attribute at /usr/local/lib/python3.7/site-packages/numba/targets/hashing.py (64)

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

    raised from /usr/local/lib/python3.7/site-packages/numba/typeinfer.py:927
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<built-in function hash>)
[2] During: typing of call at /usr/local/lib/python3.7/site-packages/numba/dictobject.py (677)


File "../../../../usr/local/lib/python3.7/site-packages/numba/dictobject.py", line 677:
    def impl(d, key, value):
        <source elided>
        castedval = _cast(value, valty)
        status = _dict_insert(d, castedkey, hash(castedkey), castedval)
        ^

    raised from /usr/local/lib/python3.7/site-packages/numba/typeinfer.py:927
In definition 3:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function hash>) with argument(s) of type(s): ([unichr x 1])
 * parameterized
In definition 0:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute '__hash__' of type [unichr x 1]

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

[1] During: typing of get attribute at /usr/local/lib/python3.7/site-packages/numba/targets/hashing.py (64)

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

    raised from /usr/local/lib/python3.7/site-packages/numba/typeinfer.py:927
In definition 1:
    TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute '__hash__' of type [unichr x 1]

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

[1] During: typing of get attribute at /usr/local/lib/python3.7/site-packages/numba/targets/hashing.py (64)

File "../../../../usr/local/lib/python3.7/site-packages/numba/targets/hashing.py", line 64:
    def impl(obj):
        return obj.__hash__()
        ^

    raised from /usr/local/lib/python3.7/site-packages/numba/typeinfer.py:927
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<built-in function hash>)
[2] During: typing of call at /usr/local/lib/python3.7/site-packages/numba/dictobject.py (677)


File "../../../../usr/local/lib/python3.7/site-packages/numba/dictobject.py", line 677:
    def impl(d, key, value):
        <source elided>
        castedval = _cast(value, valty)
        status = _dict_insert(d, castedkey, hash(castedkey), castedval)
        ^

    raised from /usr/local/lib/python3.7/site-packages/numba/typeinfer.py:927
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of setitem at <ipython-input-8-6e07a0e29476> (5)

File "<ipython-input-8-6e07a0e29476>", line 5:
def bar(x):
    <source elided>
    for k, v in zip(x, np.arange(len(x))):
        d[k] = v

```

</details>
user: ivirshup
issue_4504: state: open
title: Errors with various `reduce` calls
body: After [asking on gitter](https://gitter.im/numba/numba?at=5d68c09e375cc34fdee2a5de) about whether my usage of `reduce` was supported, @stuartarchibald asked me to open this issue here. 

The basic issue is that I'd like to use `functools.reduce`, but was running into some errors. Here are three implementations I've tried and the errors they throw:

```python
from numba import njit
from functools import reduce
from operator import add
import numpy as np

a = np.arange(100)

@njit
def sumnumba1(it):
    return reduce(add, it, 0)

sumnumba1(a)
```

<details>
<summary> Traceback (ValueError, invalid reduction function) </summary>

```python
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-2-06d54deac5b5> in <module>
      3     return reduce(add, it, 0)
      4 
----> 5 sumnumba1(a)

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    393                     e.patch_message(''.join(e.args) + help_msg)
    394             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 395             raise e
    396 
    397     def inspect_llvm(self, signature=None):

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    350                 argtypes.append(self.typeof_pyval(a))
    351         try:
--> 352             return self.compile(tuple(argtypes))
    353         except errors.TypingError as e:
    354             # Intercept typing error that may be due to an argument

/usr/local/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, sig)
    691 
    692             self._cache_misses[sig] += 1
--> 693             cres = self._compiler.compile(args, return_type)
    694             self.add_overload(cres)
    695             self._cache.save_overload(sig, cres)

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     74 
     75     def compile(self, args, return_type):
---> 76         status, retval = self._compile_cached(args, return_type)
     77         if status:
     78             return retval

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_cached(self, args, return_type)
     88 
     89         try:
---> 90             retval = self._compile_core(args, return_type)
     91         except errors.TypingError as e:
     92             self._failed_cache[key] = e

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_core(self, args, return_type)
    106                                       args=args, return_type=return_type,
    107                                       flags=flags, locals=self.locals,
--> 108                                       pipeline_class=self.pipeline_class)
    109         # Check typing error if object mode is used
    110         if cres.typing_error is not None and not flags.enable_pyobject:

/usr/local/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    970     pipeline = pipeline_class(typingctx, targetctx, library,
    971                               args, return_type, flags, locals)
--> 972     return pipeline.compile_extra(func)
    973 
    974 

/usr/local/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    388         self.lifted = ()
    389         self.lifted_from = None
--> 390         return self._compile_bytecode()
    391 
    392     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

/usr/local/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    901         """
    902         assert self.func_ir is None
--> 903         return self._compile_core()
    904 
    905     def _compile_ir(self):

/usr/local/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    888         self.define_pipelines(pm)
    889         pm.finalize()
--> 890         res = pm.run(self.status)
    891         if res is not None:
    892             # Early pipeline completion

/usr/local/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

/usr/local/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    264                     # No more fallback pipelines?
    265                     if is_final_pipeline:
--> 266                         raise patched_exception
    267                     # Go to next fallback pipeline
    268                     else:

/usr/local/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    255                 try:
    256                     event("-- %s" % stage_name)
--> 257                     stage()
    258                 except _EarlyPipelineCompletion as e:
    259                     return e.result

/usr/local/lib/python3.7/site-packages/numba/compiler.py in stage_inline_pass(self)
    619                                             self.parfor_diagnostics.replaced_fns,
    620                                             typed_pass)
--> 621         inline_pass.run()
    622         # Remove all Dels, and re-run postproc
    623         post_proc = postproc.PostProcessor(self.func_ir)

/usr/local/lib/python3.7/site-packages/numba/inline_closurecall.py in run(self)
     71 
     72                         if guard(self._inline_reduction,
---> 73                                  work_list, block, i, expr, call_name):
     74                             modified = True
     75                             break # because block structure changed

/usr/local/lib/python3.7/site-packages/numba/ir_utils.py in guard(func, *args, **kwargs)
   1376     """
   1377     try:
-> 1378         return func(*args, **kwargs)
   1379     except GuardException:
   1380         return None

/usr/local/lib/python3.7/site-packages/numba/inline_closurecall.py in _inline_reduction(self, work_list, block, i, expr, call_name)
    124                             "three arguments including initial "
    125                             "value required")
--> 126         check_reduce_func(self.func_ir, expr.args[0])
    127         def reduce_func(f, A, v):
    128             s = v

/usr/local/lib/python3.7/site-packages/numba/inline_closurecall.py in check_reduce_func(func_ir, func_var)
    223     if not (hasattr(reduce_func, 'code')
    224             or hasattr(reduce_func, '__code__')):
--> 225         raise ValueError("Invalid reduction function")
    226     f_code = (reduce_func.code if hasattr(reduce_func, 'code')
    227                                     else reduce_func.__code__)

ValueError: Failed in nopython mode pipeline (step: inline calls to locally defined closures)
Invalid reduction function
```

</details>

```python
@njit
def sumnumba2(it):
    return reduce(np.add, it, 0)

sumnumba2(a)
```

<details>
<summary> Traceback (KeyError) </summary>

```python
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-3-7adadecb5d72> in <module>
      3     return reduce(np.add, it, 0)
      4 
----> 5 sumnumba2(a)

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    393                     e.patch_message(''.join(e.args) + help_msg)
    394             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 395             raise e
    396 
    397     def inspect_llvm(self, signature=None):

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    350                 argtypes.append(self.typeof_pyval(a))
    351         try:
--> 352             return self.compile(tuple(argtypes))
    353         except errors.TypingError as e:
    354             # Intercept typing error that may be due to an argument

/usr/local/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, sig)
    691 
    692             self._cache_misses[sig] += 1
--> 693             cres = self._compiler.compile(args, return_type)
    694             self.add_overload(cres)
    695             self._cache.save_overload(sig, cres)

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     74 
     75     def compile(self, args, return_type):
---> 76         status, retval = self._compile_cached(args, return_type)
     77         if status:
     78             return retval

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_cached(self, args, return_type)
     88 
     89         try:
---> 90             retval = self._compile_core(args, return_type)
     91         except errors.TypingError as e:
     92             self._failed_cache[key] = e

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_core(self, args, return_type)
    106                                       args=args, return_type=return_type,
    107                                       flags=flags, locals=self.locals,
--> 108                                       pipeline_class=self.pipeline_class)
    109         # Check typing error if object mode is used
    110         if cres.typing_error is not None and not flags.enable_pyobject:

/usr/local/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    970     pipeline = pipeline_class(typingctx, targetctx, library,
    971                               args, return_type, flags, locals)
--> 972     return pipeline.compile_extra(func)
    973 
    974 

/usr/local/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    388         self.lifted = ()
    389         self.lifted_from = None
--> 390         return self._compile_bytecode()
    391 
    392     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

/usr/local/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    901         """
    902         assert self.func_ir is None
--> 903         return self._compile_core()
    904 
    905     def _compile_ir(self):

/usr/local/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    888         self.define_pipelines(pm)
    889         pm.finalize()
--> 890         res = pm.run(self.status)
    891         if res is not None:
    892             # Early pipeline completion

/usr/local/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

/usr/local/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    264                     # No more fallback pipelines?
    265                     if is_final_pipeline:
--> 266                         raise patched_exception
    267                     # Go to next fallback pipeline
    268                     else:

/usr/local/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    255                 try:
    256                     event("-- %s" % stage_name)
--> 257                     stage()
    258                 except _EarlyPipelineCompletion as e:
    259                     return e.result

/usr/local/lib/python3.7/site-packages/numba/compiler.py in stage_inline_pass(self)
    619                                             self.parfor_diagnostics.replaced_fns,
    620                                             typed_pass)
--> 621         inline_pass.run()
    622         # Remove all Dels, and re-run postproc
    623         post_proc = postproc.PostProcessor(self.func_ir)

/usr/local/lib/python3.7/site-packages/numba/inline_closurecall.py in run(self)
     71 
     72                         if guard(self._inline_reduction,
---> 73                                  work_list, block, i, expr, call_name):
     74                             modified = True
     75                             break # because block structure changed

/usr/local/lib/python3.7/site-packages/numba/ir_utils.py in guard(func, *args, **kwargs)
   1376     """
   1377     try:
-> 1378         return func(*args, **kwargs)
   1379     except GuardException:
   1380         return None

/usr/local/lib/python3.7/site-packages/numba/inline_closurecall.py in _inline_reduction(self, work_list, block, i, expr, call_name)
    124                             "three arguments including initial "
    125                             "value required")
--> 126         check_reduce_func(self.func_ir, expr.args[0])
    127         def reduce_func(f, A, v):
    128             s = v

/usr/local/lib/python3.7/site-packages/numba/inline_closurecall.py in check_reduce_func(func_ir, func_var)
    221         raise ValueError("Reduce function cannot be found for njit \
    222                             analysis")
--> 223     if not (hasattr(reduce_func, 'code')
    224             or hasattr(reduce_func, '__code__')):
    225         raise ValueError("Invalid reduction function")

/usr/local/lib/python3.7/site-packages/numba/ir.py in __getattr__(self, name)
    305         if name.startswith('_'):
    306             return Inst.__getattr__(self, name)
--> 307         return self._kws[name]
    308 
    309     def __setattr__(self, name, value):

KeyError: "Failed in nopython mode pipeline (step: inline calls to locally defined closures)\n'code'"
```

</details>

```python
@njit
def sumnumba3(it):
    return np.add.reduce(it)

sumnumba3(a)
```

<details>
<summary> Traceback (TypingError) </summary>

```python
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-4-47423639c0e1> in <module>
      3     return np.add.reduce(it)
      4 
----> 5 sumnumba3(a)

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375 
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344 
    345         argtypes = []

/usr/local/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'reduce' of type Function(<ufunc 'add'>)

File "<ipython-input-4-47423639c0e1>", line 3:
def sumnumba3(it):
    return np.add.reduce(it)
    ^

[1] During: typing of get attribute at <ipython-input-4-47423639c0e1> (3)

File "<ipython-input-4-47423639c0e1>", line 3:
def sumnumba3(it):
    return np.add.reduce(it)
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```

</details>

As [pointed out on gitter](https://gitter.im/numba/numba?at=5d68e8882efeca1df51e1247), the first two errors seem to be caused by `numba` expecting the function passed to `reduce` was defined locally.

I think the third example has more to do with the extent of `ufunc` support in `numba`, and might be a separate issue.

I ran these examples with `numba v0.45.1` and `numpy v1.17.1`.
user: ivirshup
issue_4503: state: open
title: Support the array_equals / array_equiv numpy function
body: # Feature request

Hello,

I'm trying to use numba inside of a personnal project, since I does a lot of numpy on very big arrays and python doesn't like that at all, even with numpy arrays. But I'm surprised and annoyed by the lack of several basic functions : array_equals, array_equiv.

For example : 
```python
def _get_color_bitmask2(color: np.ndarray, image: np.ndarray) -> np.ndarray:
    bitmask = []
    for line_idx in range(image.size):
        linemask = []
        for pixel_idx in range(image[line_idx].size):
            linemask.append(np.array_equal(image[line_idx,pixel_idx],color))
        bitmask.append(linemask)
    return np.array(bitmask)
```
won't work, `Use of unsupported NumPy function 'numpy.array_equal' or unsupported use of the function.` where this 
```python
def _get_color_bitmask2(color: np.ndarray, image: np.ndarray) -> np.ndarray:
    bitmask = []
    for line_idx in range(image.size):
        linemask = []
        for pixel_idx in range(image[line_idx].size):
            linemask.append(np.all(image[line_idx,pixel_idx]==color))
        bitmask.append(linemask)
    return np.array(bitmask)
```
will, even if the latest is a lot less safer. You should maybe consider binding or implementing them.

Thank you :+1: 
user: antonincms
issue_4500: state: open
title: GUFuncs created in __main__ are not serializable
body: (I thought that I had raised this before, but I couldn't find anything, so here it is again)

When I make a GUFunc with Numba using `numba.guvectorize`, that function is only serializable if it is part of a module.  This is, I expect, actually a problem upstream with numpy gufuncs, but raising it here made sense.  Here is a minimal reproducer:

### Process 1

```python
import numba, pickle
@numba.guvectorize([(numba.int64[:], numba.int64, numba.int64[:])], '(n),()->(n)')
def g(x, y, res):
    for i in range(x.shape[0]):
        res[i] = x[i] + y
pickle.dumps(g)
```
```
b'\x80\x03cnumpy.core\n_ufunc_reconstruct\nq\x00X\x0b\x00\x00\x00__mp_main__q\x01X\x01\x00\x00\x00gq\x02\x86q\x03Rq\x04.'
```

### Process 2

```python
import pickle
pickle.loads(b'\x80\x03cnumpy.core\n_ufunc_reconstruct\nq\x00X\x0b\x00\x00\x00__mp_main__q\x01X\x01\x00\x00\x00gq\x02\x86q\x03Rq\x04.')
```
```python-traceback
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-2-2ce3d034c167> in <module>
----> 1 pickle.loads(b'\x80\x03cnumpy.core\n_ufunc_reconstruct\nq\x00X\x0b\x00\x00\x00__mp_main__q\x01X\x01\x00\x00\x00gq\x02\x86q\x03Rq\x04.')

~/miniconda/envs/dev/lib/python3.7/site-packages/numpy/core/__init__.py in _ufunc_reconstruct(module, name)
    122     # nested. This makes it possible to pickle non-toplevel ufuncs such as
    123     # scipy.special.expit for instance.
--> 124     mod = __import__(module, fromlist=[name])
    125     return getattr(mod, name)
    126
```
user: mrocklin
issue_4499: state: open
title: Accept Numpy (1.17+) Generator and BitGenerator objects in jitted code
body: Numpy 1.17 introduced a new `random` module, with new `Generator` and `BitGenerator` objects. The old `RandomState` is preserved for backwards compatibility. As far as I can tell, the new module does not have any global state, but rather relies on explicit instantiation and passing of `Generator` instances.
Therefore it would be very useful if these instance could be passed to a jitted function. This would not only allow jitted functions to access the faster random number generators, and preserve Numpy overall compatibility but also address #3249.

user: luk-f-a
issue_4497: state: open
title: Add unicode types in the documention
body: Currently the unicode type is not mentioned in section 2.1 of the documentation, making it harder to know what the correct signature is for jitclasses and other places where a type is required. 

I am guessing the right place is either 2.1.3.3 or 2.1.4.
user: luk-f-a
labels: good second issue: A good issue for second time contributors
issue_4496: state: open
title: isinstance on jitclass instances returns False on parent class
body: `isinstance` correctly recognizes the direct class but not the parent class

```
import numba

class rv_parent:
    def __init__(self):
        pass

@numba.jitclass(spec=[])
class norm_gen(rv_parent):
    pass

norm = norm_gen()

isinstance(norm, rv_parent)  #False, should be True
```
user: luk-f-a
issue_4495: state: open
title: Jitclass method call fails with keyword argument
body: 
Hi, currently jitclasses allow methods to be declared with keyword arguments, but unlike njit functions, it is not possible to call these methods with keyword arguments. The problem ocurs with and without default values
```python
import numba
@numba.jitclass(spec=[])
class norm_gen():
    
    def __init__(self):
        pass
    
    def foo(self, loc=0, size=1):
        return size
    
    def bar(self, loc, size):
        return size
    
norm = norm_gen()
#all these fail
norm.foo(loc=0, size=10)
norm.foo(size=10)
norm.bar(loc=0, size=10)
#this works
norm.foo(0, 10)
```
user: luk-f-a
issue_4494: state: open
title: `lower_constant` and `lower_cast` should probably return new references
body: ## Feature request
Currently `@lower_constant` and `@lower_cast` expect the implementation to return borrowed references. This makes it tricky to implement lowering constants and casts for memory managed types as you cannot just use native constructors (if available). For casting there might even be edge cases that cannot be implemented at all (#3492).

It would be great if the following naive implementation strategy for lowering constants and casts worked. Assume we have an existing (maybe memory managed) Numba type `AType` and a new extension type `BType` with a native constuctor `B(a: A)`.

Lowering a constant `B` might look like:
```python
@lower_constant(BType)
def lower_constant_b(context, builder, typ, pyval):
    a = pyval.a  # assuming B has an attribute a and constant AType can be lowered
    def lower_b_impl():
        return B(a) 
    return context.compile_internal(builder, lower_b_impl, typ(), [])  # returns new ref
```
Casting `AType` to `BType` could be implemented like
```python
@lower_cast(types.Number, UnitType)
def cast_a_to_b(context, builder, fromty, toty, val):
    def cast_a_b_impl(a):
        return B(a)
    return context.compile_internal(builder, lower_b_impl, totyp(fromty), [val])  # returns new ref
```
Withe the current refcounting conventions the implementations above will leak memory. In some cases you can avoid the memory leak by punting on the refcount pruning pass and simply call `context.nrt.decref` on the result of `compile_internal`. However, this will not work in general (for example casting tuples will not work) and crash the interpreter.




user: asodeur
issue_4492: state: open
title: No matching definition when using `deferred_type`
body: In answering a question on Stackoverflow, I came across an issue that I don't fully understand. Disregarding whether you actually need to use a `deferred_type`, the following fails:

```python
import numpy as np
import numba as nb

spec = [('x', nb.float64)]

@nb.jitclass(spec)
class EarthModel:
    def __init__(self, x):
        self.x = x

earth_model_type = nb.deferred_type()
earth_model_type.define(EarthModel.class_type.instance_type)


@nb.jit(nb.float64(nb.float64[:, :], nb.float64[:, :], nb.float64[:, :], earth_model_type))
def test(x, y, z, em):
    return em.x
```

when running:

```python
em = EarthModel(9.9)
x = np.random.normal(size=(3,3))
y = np.random.normal(size=(3,3))
z = np.random.normal(size=(3,3))

test(x, y, z, em)
```

with the error:

```python
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-15-d98a87d86d5c> in <module>
      4 z = np.random.normal(size=(3,3))
      5 
----> 6 test(x, y, z, em)

~/miniconda2/envs/numba-latest/lib/python3.7/site-packages/numba/dispatcher.py in _explain_matching_error(self, *args, **kws)
    498         msg = ("No matching definition for argument type(s) %s"
    499                % ', '.join(map(str, args)))
--> 500         raise TypeError(msg)
    501 
    502     def _search_new_conversions(self, *args, **kws):

TypeError: No matching definition for argument type(s) array(float64, 2d, C), array(float64, 2d, C), array(float64, 2d, C), instance.jitclass.EarthModel#6231b36d8<x:float64>
```

If you instead allow numba to jit the function without supplying types:

```python
import numpy as np
import numba as nb

spec = [('x', nb.float64)]

@nb.jitclass(spec)
class EarthModel:
    def __init__(self, x):
        self.x = x

@nb.jit(nopython=True)
def test(x, y, z, em):
    return em.x
```

and then this works and the result of `test.signatures` is:

```python
[(array(float64, 2d, C),
  array(float64, 2d, C),
  array(float64, 2d, C),
  instance.jitclass.EarthModel#623186470<x:float64>)]
```

so the types look pretty similar. Of course everything works fine if you specify the types, but instead define `earth_model_type = EarthModel.class_type.instance_type` directly instead of using the `deferred_type`. 
user: synapticarbors
labels: discussion: An issue requiring discussion
issue_4490: state: open
title: Error while instanciating a jitclass with optional arguments in a jit function 
body: I'm currently implementing some data-structures using numba jitclass and I got an error while instanciating a jitclass with optional arguments in the `__init__` method : 

```python
from numba import jitclass, jit, int32

@jitclass([('size', int32)])
class Vector:
    # aims to be a C++ like vector implementation 
    
    def __init__(self, size=0):
        self.size = size
    
    # [...] append, pop, __getitem__, __setitem__

@jit(nopython=True)
def doThings():
    v = Vector() # FAILS
    # But this works: v = Vector(0)
    # and calling Vector() outside of jit function works
    return v

doThings()
```

I'm using : 
- numba 0.45.1 
- Python 3.6.3 :: Anaconda custom (64-bit)
- windows 10 x64 with an intell processor 

Here is a shortened traceback : 
```
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

[...]

TypeError: invalid number of args: expected 2, got 1

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)

[...]

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
invalid number of args: expected 2, got 1

File "<ipython-input-16-be997a828aa8>", line 17:
def doThings():
    v = Vector() # FAILS
    ^

[1] During: lowering "$0.2 = call $0.1(func=$0.1, args=[], kws=(), vararg=None)" at <ipython-input-16-be997a828aa8> (17)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.45.1.
```

user: cakedev0
issue_4488: state: open
title: numba.errors.LoweringError: Failed in object mode pipeline (step: object mode backend) array.3
body: Here's the simplified code that produces the error,
```python
import numpy as np
from numba import jit
geomList  = np.stack( np.mgrid[0.1:5.0:50j,0:180:181j], axis=2).reshape(-1,2)


@jit
def func():
    dist = np.array([geomList[30] for i in range(30)])
    return dist

print func()
```
produces this error
```
Traceback (most recent call last):
  File "/home/koushik/CODES/numba_error.py", line 12, in <module>
    print func()
  File "/home/koushik/.local/lib/python2.7/site-packages/numba/dispatcher.py", line 369, in _compile_for_args
    raise e
numba.errors.LoweringError: Failed in object mode pipeline (step: object mode backend)
array.3

File "numba_error.py", line 8:
def func():
    dist = np.array([geomList[30] for i in range(30)])
    ^

[1] During: lowering "$38.5 = array.3" at /home/koushik/CODES/numba_error.py (8)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
```
is this a numba error or am I doing something wrong?
user: Koushikphy
issue_4481: state: open
title: function accelerated by jit can not use lambda
body: I got an error while using jit accelerating.
This is code.
```
import numba
@numba.jit
def cal(times):
    result = []
    for x in range(times):
        weights = np.random.random(times)
        weights /= np.sum(weights)
        result.append((x, weights))
    sorted_result = sorted(result, key = lambda x: x[1][1], reverse=True)
    return sorted_result
%time cal(2000)
```

Errors:
```
<ipython-input-122-b303690e2279>:2: NumbaWarning: 
Compilation is falling back to object mode WITH looplifting enabled because Function "cal" failed type inference due to: Invalid use of Function(<built-in function sorted>) with argument(s) of type(s): (list((int64, array(float64, 1d, C))), key=Literal[Expr](make_function(name=$const62.4, code=<code object <lambda> at 0x1c3aaac5d0, file "<ipython-input-122-b303690e2279>", line 9>, closure=None, defaults=None)), reverse=bool)
 * parameterized
In definition 0:
    TypeError: typer() got an unexpected keyword argument 'key'
    raised from /Users/mashuaiwei/anaconda3/lib/python3.7/site-packages/numba/typing/templates.py:263
In definition 1:
    ValueError: cannot determine Numba type of <class 'numba.ir.Expr'>
    raised from /Users/mashuaiwei/anaconda3/lib/python3.7/site-packages/numba/typing/context.py:367
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<built-in function sorted>)
[2] During: typing of call at <ipython-input-122-b303690e2279> (9)


File "<ipython-input-122-b303690e2279>", line 9:
def cal(times):
    <source elided>
        result.append((x, weights))
    sorted_result = sorted(result, key = lambda x: x[1][1], reverse=True)
    ^

  @numba.jit
<ipython-input-122-b303690e2279>:2: NumbaWarning: 
Compilation is falling back to object mode WITHOUT looplifting enabled because Function "cal" failed type inference due to: cannot determine Numba type of <class 'numba.dispatcher.LiftedLoop'>

File "<ipython-input-122-b303690e2279>", line 5:
def cal(times):
    <source elided>
    result = []
    for x in range(times):
    ^

  @numba.jit
---------------------------------------------------------------------------
UnsupportedError                          Traceback (most recent call last)
<timed eval> in <module>

~/anaconda3/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    352         except errors.UnsupportedError as e:
    353             # Something unsupported is present in the user code, add help info
--> 354             error_rewrite(e, 'unsupported_error')
    355         except (errors.NotDefinedError, errors.RedefinedError,
    356                 errors.VerificationError) as e:

~/anaconda3/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    316                 raise e
    317             else:
--> 318                 reraise(type(e), e, None)
    319 
    320         argtypes = []

~/anaconda3/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

UnsupportedError: Failed in object mode pipeline (step: object mode frontend)
Failed in object mode pipeline (step: ensure IR is legal prior to lowering)
Numba encountered the use of a language feature it does not support in this context: <lambda> (op code: make_function not supported). If the feature is explicitly supported it is likely that the result of the expression (<lambda>) is being used in an unsupported manner.

File "<ipython-input-122-b303690e2279>", line 9:
def cal(times):
    <source elided>
        result.append((x, weights))
    sorted_result = sorted(result, key = lambda x: x[1][1], reverse=True)
    ^

Unsupported functionality was found in the code Numba was trying to compile.

If this functionality is important to you please file a feature request at:
https://github.com/numba/numba/issues/new
```
user: fenglinxiu
issue_4479: state: open
title: np.argsort and ndarray.argsort only on 1-D data
body: ```
@numba.njit
def argsort(X):
    # return np.argsort(X)
    return X.argsort()
```

Both of the above will fail if `X` is not 1-D.

The support page at https://numba.pydata.org/numba-doc/dev/reference/numpysupported.html states that this should work.
user: sleighsoft
issue_4478: state: open
title: Support for new const arrays /  ndarray.setflags
body: AFAIK, there's no way to return a new const-array from an njit function:
```
import numba
import numpy as np
@numba.jit(nopython=True)
def f():
    x = np.empty(10, dtype=np.bool_)
    x.setflags(write=False)  # Unknown attribute 'setflags' of type array(bool, 1d, C)
    return x
f()
```

Immutability is fundamental to safe, well designed, easy-to-reason-about APIs, and would a helpful addition.
user: stuz5000
issue_4473: state: open
title: Type hints for Numba code base
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
The upcoming deprecation of Python 2 enables us to use type hints for the code base. Should we start using them?

Pandas for example is adding type hints quite quickly: https://github.com/pandas-dev/pandas/labels/Typing
and they are strongly encouraging it: https://github.com/pandas-dev/pandas/pull/27050/files

user: ehsantn
labels: discussion: An issue requiring discussion
issue_4471: state: open
title: Array order check is too strict
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).


Numpy identifies `1 x n` or `n x 1` matrices as both C- and F-contiguous. Such matrices fail to pass numba's contiguity check as F-contiguous.

Code example
```python
>>> from numba import njit                                                      
>>> import numpy as np                                                          
>>>                                                                             
>>> # This definition generates a warning                                       
>>> @njit('f8[:, :], f8[:]') 
... def prod(A, x): 
...     return A.T @ x 
...                                                                             
<ipython-input-9-ed5020607679>:3: NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 1d, A))
  return A.T @ x
/Users/lizli/anaconda3/lib/python3.7/site-packages/numba/typing/npydecl.py:967: NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 1d, A))
  warnings.warn(NumbaPerformanceWarning(msg))
>>> # OK, I will be more specific              
>>> @njit('f8[::1, :], f8[::1]') 
... def prod(A, x): 
...     return A.T @ x 
...                                                                             
>>> # All good                                                                  
>>> prod(np.zeros((2, 2), order='F'), np.zeros(2))                              
array([0., 0.])
>>> # But there are cases where the matrix can be both C and F                  
>>> A = np.zeros((2, 1), order='F')                                             
>>> print(A.flags)                                                              
  C_CONTIGUOUS : True
  F_CONTIGUOUS : True
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
>>> prod(A, np.zeros(2))                                                        
Traceback (most recent call last):
  File "<ipython-input-18-e21ff4da4503>", line 1, in <module>
    prod(A, np.zeros(2))
  File "/Users/lizli/anaconda3/lib/python3.7/site-packages/numba/dispatcher.py", line 466, in _explain_matching_error
    raise TypeError(msg)
TypeError: No matching definition for argument type(s) array(float64, 2d, C), array(float64, 1d, C)

>>>              
```

Further information:
* Python 3.7.3
* Numpy 1.16.4
* Numba 0.44.1


user: lzlarryli
issue_4470: state: open
title: Can't create a numpy array from a numpy array
body: - [X] I am using the latest released version of Numba.
- [X] I have included below a minimal working reproducer.

The [numpy support page](https://numba.pydata.org/numba-doc/dev/reference/numpysupported.html#other-functions) says that `numpy.array` is supported (in the 2 first arguments only, those being the object and dtype arguments).  But if the input is an array, (which is first on the list of acceptable arguments to [`numpy.array`](https://docs.scipy.org/doc/numpy/reference/generated/numpy.array.html)), numba raises a TypingError, complaining that `Function(<built-in function array>)` cannot be used with array arguments.

A workaround seems to be to use `np.asarray(a).copy()`, but this is an awkward mangling of numpy's semantics, and goes against the ethos of allowing numba to compile standard python code.

Here's the reproducer:
```python
import numpy as np
import numba

@numba.njit
def test(a):
    b = np.array(a)

test(np.array([1.0, 2, 3]))
```
(With `jit`, the error turns into a big ugly warning for the same reasons.)  And here's the output:
```python-traceback
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-3-11d0a4b9c30a> in <module>
      6     b = np.array(a)
      7 
----> 8 test(np.array([1.0, 2, 3]))

~/.continuum/anaconda3.7/envs/science/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375 
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

~/.continuum/anaconda3.7/envs/science/lib/python3.6/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344 
    345         argtypes = []

~/.continuum/anaconda3.7/envs/science/lib/python3.6/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function array>) with argument(s) of type(s): (array(float64, 1d, C))
 * parameterized
In definition 0:
    TypingError: array(float64, 1d, C) not allowed in a homogeneous sequence
    raised from /Users/boyle/.continuum/anaconda3.7/envs/science/lib/python3.6/site-packages/numba/typing/npydecl.py:460
In definition 1:
    TypingError: array(float64, 1d, C) not allowed in a homogeneous sequence
    raised from /Users/boyle/.continuum/anaconda3.7/envs/science/lib/python3.6/site-packages/numba/typing/npydecl.py:460
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<built-in function array>)
[2] During: typing of call at <ipython-input-3-11d0a4b9c30a> (6)


File "<ipython-input-3-11d0a4b9c30a>", line 6:
def test(a):
    b = np.array(a)
    ^
```
user: moble
issue_4469: state: open
title: Issue using differently shaped NumPy array
body: From the mailinglist:

> I am writing a 2D physics solver with Python/Numba and ran into a problem with
> Numba. Maybe someone can help me find a work around.
> 
> The problem is the following; I am trying to pass a list of numpy structured
> array (same data type) but with different sizes to a @numba.njit function.
> Numba complains about heterogeneous list (because the numpy structured array
> have different sizes).
> 
> If I replace the list of numpy structured array with a tuple containing numpy
> structure array, Numba compiles the function but error at execution.
> 
> In C, I would pass a list of pointers and it would not be an issue.
> I am wondering if it is an issue or a feature not yet implemented.

Reproducer is:

```python
"""
@author: Vincent Bonnet
@description : Experimentations with Numba
"""

import numba
import numpy as np

def allocate_particles_as_sof(num_particles):
    '''
    Allocate particle data as a structure of array (sof)
    '''
    array_dtype = []
    for name in ['x', 'v', 'f']:
        array_dtype.append((name, np.float32, (num_particles, 2)))

    particle_data = np.zeros(1, dtype=np.dtype(array_dtype))
    return particle_data

@numba.njit
def print_first_particle_system(array_data):
    '''
    '''
    indices = [0, 1, 2] # silly but trigger issue
    print(array_data[indices[0]][0]['x'])

# WORKS - only because array have same size
particle_data0 = allocate_particles_as_sof(10)
particle_data1 = allocate_particles_as_sof(10)
my_array = [particle_data0, particle_data1]
print_first_particle_system(my_array)

# DOESN'T WORK - array do not have same size
# ERROR 1 - can't unbox heterogeneous list
#particle_data0 = allocate_particles_as_sof(10)
#particle_data1 = allocate_particles_as_sof(15)
#my_array = [particle_data0, particle_data1]
#print_first_particle_system(my_array)

# DOESN'T WORK - array do not have same size
# ERROR 2 - Invalid use of Function(<built-in function getitem>)
#particle_data0 = allocate_particles_as_sof(10)
#particle_data1 = allocate_particles_as_sof(15)
#my_array = [particle_data0, particle_data1]
#print_first_particle_system(tuple(my_array))
```
user: esc
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_4466: state: open
title: Support passing scalars by reference to ctypes/cffi methods
body: Some external libraries expose methods that require passing scalars by reference (instead of by value). It would be good to support this in numba as well.

When using ctypes, this could use [`ctypes.byref`](https://docs.python.org/3/library/ctypes.html#ctypes.byref).

```python
In [1]: import ctypes

In [2]: libc = ctypes.CDLL("libc.dylib")

In [3]: i = ctypes.c_int()

In [4]: f = ctypes.c_float()

In [5]: s = ctypes.create_string_buffer(b'\000' * 32)

In [6]: print(i.value, f.value, repr(s.value))
0 0.0 b''

In [7]: libc.sscanf(b"1 3.14 Hello", b"%d %f %s", ctypes.byref(i), ctypes.byref(f), s)
Out[7]: 3

In [8]: print(i.value, f.value, repr(s.value))
1 3.140000104904175 b'Hello'
```

`cffi` doesn't expose object types for pointers, but an equivalent example is:

```
In [26]: import cffi

In [27]: ffi = cffi.FFI()

In [28]: ffi.cdef("int sscanf ( const char * s, const char * format, ...);")

In [29]: C = ffi.dlopen(None)

In [30]: i = ffi.new("int *")

In [31]: f = ffi.new("float *")

In [32]: C.sscanf(b"1 3.14", b"%d %f", i, f)
Out[32]: 2

In [33]: i[0]  # cffi uses indexing with 0 as dereference
Out[33]: 1

In [34]: f[0]
Out[34]: 3.140000104904175
```

Numba may want to expose its own pointer/ref type to allow use with both ctypes and cffi wrapped functions.
user: jcrist
issue_4465: state: open
title: Overload with kwargs provides inconsistent type arguments
body: When overloading functions with keyword arguments, `overload` has some non-ergonomic issues:

- The function signature of `overload_foo` must match the signature of `foo` (including kwarg defaults), otherwise numba errors. This means that the keyword defaults must be the corresponding values, not the types

- If the keyword isn't specified in the call, the `overload_foo` function receives the default value instead of the type of that value. This means that logic in `overload_foo` must be able to handle both numba types and default values.

```python
In [1]: def add(a, b=1):
   ...:     return a + b
   ...:

In [2]: import numba as nb

In [3]: @nb.extending.overload(add)
   ...: def overload_add(a, b=1):
   ...:     print("a is %r" % a)
   ...:     print("b is %r" % b)
   ...:     return add
   ...:

In [4]: @nb.jit(nopython=True)
   ...: def test_nokwarg(a):
   ...:     return add(a)
   ...:

In [5]: @nb.jit(nopython=True)
   ...: def test_kwarg(a, b):
   ...:     return add(a, b=b)
   ...:

In [6]: test_nokwarg(1)  # Ideally b would also be `int64` but instead it's a 1 value
a is int64
b is 1
Out[6]: 2

In [7]: test_kwarg(1, 2)
a is int64
b is int64
Out[7]: 3
```

Trying to specify the default types as the kwarg defaults in `overload_add` results in an error:

```python
In [12]: def add(a, b=1):
    ...:     return a + b
    ...:

In [13]: @nb.extending.overload(add)
    ...: def overload_add(a, b=nb.types.int64):
    ...:     print("a is %r" % a)
    ...:     print("b is %r" % b)
    ...:     return add
    ...:

In [14]: @nb.jit(nopython=True)
    ...: def test_nokwarg(a):
    ...:     return add(a)
    ...:

In [15]: test_nokwarg(1)
a is int64
b is int64
a is int64
b is int64
a is int64
b is int64
a is int64
b is int64

---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-15-e4b612b2c427> in <module>
----> 1 test_nokwarg(1)

~/miniconda3/envs/numba-blis/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

~/miniconda3/envs/numba-blis/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344
    345         argtypes = []

~/miniconda3/envs/numba-blis/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<function add at 0x1171d91e0>) with argument(s) of type(s): (int64)
 * parameterized
In definition 0:
    InternalError: Typing and implementation arguments differ in keyword argument default values.
Typing signature:         (a, b=int64)
Implementation signature: (a, b=1)
Difference: {<Parameter "b=int64">, <Parameter "b=1">}
    raised from /Users/jcrist/miniconda3/envs/numba-blis/lib/python3.7/site-packages/numba/typing/templates.py:417
In definition 1:
    InternalError: Typing and implementation arguments differ in keyword argument default values.
Typing signature:         (a, b=int64)
Implementation signature: (a, b=1)
Difference: {<Parameter "b=int64">, <Parameter "b=1">}
    raised from /Users/jcrist/miniconda3/envs/numba-blis/lib/python3.7/site-packages/numba/typing/templates.py:417
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<function add at 0x1171d91e0>)
[2] During: typing of call at <ipython-input-14-2a1aab79f9d3> (3)


File "<ipython-input-14-2a1aab79f9d3>", line 3:
def test_nokwarg(a):
    return add(a)
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```

A few options to make this nicer

- Always wrap any unspecified argument default values with `Omitted` and forward to `overload_foo` (as is done in `generated_jit`, but not `overload`). This is my preference.
- Always type and forward the default kwargs and pass them to `overload_foo` (so the overload function would never receive its own defaults, all types would always be passed in)
- Allow specifying type objects instead of values as kwarg defaults in `overload_foo`
user: jcrist
labels: discussion: An issue requiring discussion
issue_4460: state: open
title: nb.deferred_type for jitclass does not work with any built-in method
body: ### nb.defered_type does not work with special method __getitem__
```python
next_type = nb.deferred_type()
@nb.jitclass(spec=[
    ('next', next_type),
])
class Node(object):
    def __init__(self):
        self.next = [self]
    
    def get_next(self):
        return self.next[0]

next_type.define(nb.types.List(Node.class_type.instance_type))

node = Node()
node.next[0]  # OK

node.get_next()  # Error
```

```
TypingError                               Traceback (most recent call last)
<ipython-input-53-244b6721f5e8> in <module>
----> 1 NIL.get_next()

D:\ProgramData\Anaconda3\lib\site-packages\numba\jitclass\boxing.py in wrapper(*args, **kwargs)
     60     @wraps(func)
     61     def wrapper(*args, **kwargs):
---> 62         return method(*args, **kwargs)
     63 
     64     return wrapper

D:\ProgramData\Anaconda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375 
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

D:\ProgramData\Anaconda3\lib\site-packages\numba\dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344 
    345         argtypes = []

D:\ProgramData\Anaconda3\lib\site-packages\numba\six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function getitem>) with argument(s) of type(s): (none, Literal[int](0))
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    All templates rejected with literals.
In definition 9:
    All templates rejected without literals.
In definition 10:
    All templates rejected with literals.
In definition 11:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of intrinsic-call at <ipython-input-51-b3677d56155c> (17)
[2] During: typing of static-get-item at <ipython-input-51-b3677d56155c> (17)

File "<ipython-input-51-b3677d56155c>", line 17:
    def get_next(self):
        <source elided>
        l = self.next.extend([self for i in range(0)])
        return l[0]
        ^

[1] During: resolving callee type: BoundFunction((<class 'numba.types.misc.ClassInstanceType'>, 'get_next') for instance.jitclass.Node#242f82b86a0<value:float64,next:DeferredType#2486654699224,width:list(int64)>)
[2] During: typing of call at <string> (3)

[3] During: resolving callee type: BoundFunction((<class 'numba.types.misc.ClassInstanceType'>, 'get_next') for instance.jitclass.Node#242f82b86a0<value:float64,next:DeferredType#2486654699224,width:list(int64)>)
[4] During: typing of call at <string> (3)


File "<string>", line 3:
<source missing, REPL/exec in use?>

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```
user: bohan-gsm
issue_4457: state: open
title: `objmode` block does not work inside a closure
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```pycon

In [23]: %paste                                                                                                                 
        @njit
        def impl():
            def bar():
                with objmode():
                    print("hi")
            return bar()
        impl()

UnsupportedError: Failed in nopython mode pipeline (step: nopython frontend)
Unsupported constraint encountered: enter_with $phi4.1

File "<ipython-input-23-7d67dadce523>", line 4:
    def bar():
        with objmode():
        ^
```

user: stuartarchibald
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_4456: state: open
title: `objmode` context manager has to be a global else it is not identified correctly
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```pycon
In [10]: from numba import njit, objmode                                                                                        

In [11]: @njit 
    ...: def impl(): 
    ...:     with objmode(): 
    ...:         print("hi") 
    ...:     return 
    ...:                                                                                                                        

In [12]: impl()                                                                                                                 
hi

In [13]: def gen(): 
    ...:     from numba import objmode 
    ...:     def impl(): 
    ...:         with objmode(): 
    ...:             print("hi") 
    ...:         return 
    ...:     return impl 
    ...:                                                                                                                        

In [14]: njit(gen())()  
CompilerError: Failed in nopython mode pipeline (step: Handle with contexts)
Illegal use of context-manager.

File "<ipython-input-13-fbc5f66fa1a1>", line 4:
    def impl():
        with objmode():
```
expect the above is the result of the `with_lifting` matching on global for `objmode` whereas it ought to match on freevar too.
user: stuartarchibald
labels: objectmode: object mode related issue
bug - failure to compile: Bugs: failed to compile valid code
issue_4454: state: open
title: Incorrect results on openblas for np.dot with out parameter
body: When calling `np.dot` with the `out` parameter the same as one of the input parameters, the corresponding array is set to all zeros when using `openblas`, but correct when using `mkl`.

**Example**

```python
In [1]: %paste
import numpy as np
import numba as nb

x = np.random.normal(size=(3, 3))

y = np.random.normal(size=(3, 3))

@nb.jit(nopython=True)
def itermatmul(a, b, n):
    for _ in range(n):
        np.dot(a, b, out=a)


print(x)
got = x.copy()
expect = x.copy()
itermatmul(got, y, 10)
itermatmul.py_func(expect, y, 10)

print('got')
print(got)
print('expect')
print(expect)

## -- End pasted text --
[[-0.82968404  1.29267932 -0.36438949]
 [ 0.00357495  0.78423584 -0.91562765]
 [ 0.1003191  -0.82464142 -0.64630126]]
got
[[0. 0. 0.]
 [0. 0. 0.]
 [0. 0. 0.]]
expect
[[ 189.76923021 -101.10688022 -185.96415419]
 [ 540.73726898 -285.20245698 -527.84770944]
 [ 189.61821806  -98.71992944 -183.23659256]]
```

**Versions**

```python
In [2]: nb.__version__
Out[2]: '0.45.1'

In [3]: np.__version__
Out[3]: '1.17.0'
```
user: jcrist
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_4452: state: open
title: Predictable RNG sequences under prange.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

In a `prange` loop it'd be useful if when `np.random.seed(xyz)` is called on the main thread if the launched threads then had e.g. `xyz + thread index` as their seed so as to create predictable per-thread streams. Example:

```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def foo():
    N = 100
    ret = np.empty((N,))
    np.random.seed(1234)
    for i in prange(N):
        # set TLS seed to `1234 + thread index`
        ret[i] = np.random.rand()
    return np.sort(ret)
```

user: stuartarchibald
issue_4449: state: open
title: Incorrect output dtype for operations on arrays and scalars
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest ~~released~~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Looks like output dtype is incorrect when an operation has array and scalar inputs (see below). This happens for both integer and float types, and seems different than the [integer typing semantic issue](https://numba.pydata.org/numba-doc/dev/proposals/integer-typing.html).

np.testing functions don't seem to check for dtype matching, so this is easy to miss. I came across this issue since pd.testing functions do check for dtype matching.
```python
In [36]: A = np.arange(5, dtype=np.int32)

In [37]: numba.njit(lambda A: A+1)(A).dtype
Out[37]: dtype('int64')

In [38]: (A+1).dtype
Out[38]: dtype('int32')
```
<details><summary>numba -s output</summary>
<p>
__Time Stamp__
2019-08-14 15:46:31.280166

__Hardware Information__
Machine                                       : x86_64
CPU Name                                      : skylake
CPU count                                     : 16
CPU Features                                  :
64bit adx aes avx avx2 bmi bmi2 clflushopt cmov cx16 f16c fma fsgsbase invpcid
lzcnt mmx movbe pclmul popcnt prfchw rdrnd rdseed rtm sahf sgx sse sse2 sse3
sse4.1 sse4.2 ssse3 xsave xsavec xsaveopt xsaves

__OS Information__
Platform                                      : Darwin-18.7.0-x86_64-i386-64bit
Release                                       : 18.7.0
System Name                                   : Darwin
Version                                       : Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64
OS specific info                              : 10.14.6   x86_64

__Python Information__
Python Compiler                               : Clang 4.0.1 (tags/RELEASE_401/final)
Python Implementation                         : CPython
Python Version                                : 3.7.3
Python Locale                                 : en_US UTF-8

__LLVM information__
LLVM version                                  : 8.0.0

__CUDA Information__
CUDA driver library cannot be found or no CUDA enabled devices are present.
Error class: <class 'numba.cuda.cudadrv.error.CudaSupportError'>

__ROC Information__
ROC available                                 : False
Error initialising ROC due to                 : No ROC toolchains found.
Available Toolchains                          : ROC command line tools
No HSA Agents found, encountered exception when searching:
Error at driver init:

HSA is not currently supported on this platform (darwin).
:

__SVML Information__
SVML state, config.USING_SVML                 : False
SVML library found and loaded                 : False
llvmlite using SVML patched LLVM              : True
SVML operational                              : False

__Threading Layer Information__
TBB Threading layer available                 : False
+--> Disabled due to                          : Unknown import problem.
OpenMP Threading layer available              : False
+--> Disabled due to                          : Unknown import problem.
Workqueue Threading layer available           : True

__Numba Environment Variable Information__
NUMBA_DEBUG_ARRAY_OPT                         : 1

__Conda Information__
conda_build_version                           : 3.18.8
conda_env_version                             : 4.7.11
platform                                      : osx-64
python_version                                : 3.7.3.final.0
root_writable                                 : True

__Current Conda Env__
_tflow_select             2.3.0                       mkl
absl-py                   0.7.1                    py37_0
appnope                   0.1.0                    py37_0
arrow-cpp                 0.11.1           py37hcacac7f_1
astor                     0.8.0                    py37_0
astroid                   2.2.5                    py37_0
atomicwrites              1.3.0                    py37_1
attrs                     19.1.0                   py37_1
backcall                  0.1.0                    py37_0
blas                      1.0                         mkl
bleach                    3.1.0                    py37_0
bodo                      0+untagged.2706.g0d319c5.dirty           dev_0    <develop>
boost                     1.67.0                   py37_4
bzip2                     1.0.8                h1de35cc_0
c-ares                    1.15.0            h1de35cc_1001
ca-certificates           2019.5.15                     1
cctools                   895                           1
certifi                   2019.6.16                py37_1
clang                     4.0.1                         1
clang_osx-64              4.0.1               h1ce6c1d_16
clangxx                   4.0.1                         1
clangxx_osx-64            4.0.1               h22b1bf0_16
cmake                     3.14.0               haff7e42_0
compiler-rt               4.0.1                hcfea43d_1
dbus                      1.13.6               h90a0687_0
decorator                 4.4.0                    py37_1
defusedxml                0.6.0                      py_0
entrypoints               0.3                      py37_0
expat                     2.2.6                h0a44026_0
gast                      0.2.2                    py37_0
gettext                   0.19.8.1             h15daf44_3
gflags                    2.2.2                h0a44026_0
gfortran_osx-64           4.8.5                h22b1bf0_8
glib                      2.56.2               hd9629dc_0
glog                      0.3.5                h0a44026_1
grpcio                    1.16.1           py37h044775b_1
h5py                      2.9.0            py37h3134771_0
hdf5                      1.10.4               hfa1e0ec_0
icu                       58.2                 h4b95b61_1
importlib_metadata        0.17                     py37_1
intel-openmp              2019.4                      233
ipykernel                 5.1.1            py37h39e3cac_0
ipyparallel               6.2.4                    py37_0
ipython                   7.6.1            py37h39e3cac_0
ipython_genutils          0.2.0                    py37_0
ipywidgets                7.5.0                      py_0
isort                     4.3.21                   py37_0
jedi                      0.13.3                   py37_0
jinja2                    2.10.1                   py37_0
joblib                    0.13.2                   py37_0
jpeg                      9b                   he5867d9_2
jsonschema                3.0.1                    py37_0
jupyter                   1.0.0                    py37_7
jupyter_client            5.3.1                      py_0
jupyter_console           6.0.0                    py37_0
jupyter_core              4.5.0                      py_0
keras-applications        1.0.8                      py_0
keras-preprocessing       1.1.0                      py_1
krb5                      1.16.1               hddcf347_7
lazy-object-proxy         1.4.1            py37h1de35cc_0
ld64                      274.2                         1
libboost                  1.67.0               hebc422b_4
libcurl                   7.65.2               h051b688_0
libcxx                    4.0.1                hcfea43d_1
libcxxabi                 4.0.1                hcfea43d_1
libedit                   3.1.20181209         hb402a30_0
libevent                  2.1.8                ha12b0ac_0
libffi                    3.2.1                h475c297_4
libgfortran               3.0.1                h93005f0_2
libiconv                  1.15                 hdd342a3_7
libpng                    1.6.37               ha441bb4_0
libprotobuf               3.8.0                hd9629dc_0
libsodium                 1.0.16               h3efe00b_0
libssh2                   1.8.2                ha12b0ac_0
llvm                      4.0.1                         1
llvm-lto-tapi             4.0.1                         1
llvm-openmp               4.0.1                hcfea43d_1
llvmlite                  0.29.0dev0              py37_36    numba/label/dev
lz4-c                     1.8.1.2              h1de35cc_0
markdown                  3.1.1                    py37_0
markupsafe                1.1.1            py37h1de35cc_0
maven                     3.6.0                         0
mccabe                    0.6.1                    py37_1
mistune                   0.8.4            py37h1de35cc_0
mkl                       2019.4                      233
mkl-service               2.0.2            py37h1de35cc_0
mkl_fft                   1.0.12           py37h5e564d8_0
mkl_random                1.0.2            py37h27c97d8_0
mock                      3.0.5                    py37_0
more-itertools            7.0.0                    py37_0
mpi                       1.0                       mpich
mpi4py                    3.0.1            py37h77202c6_0    conda-forge
mpich                     3.2.1                h12d9a10_8
nbconvert                 5.5.0                      py_0
nbformat                  4.4.0                    py37_0
ncurses                   6.1                  h0a44026_1
notebook                  6.0.0                    py37_0
numba                     0.46.0.dev0+12.g37ab1420f           dev_0    <develop>
numpy                     1.16.4           py37hacdab7b_0
numpy-base                1.16.4           py37h6575580_0
openjdk                   8.0.152              h393ad39_1
openssl                   1.1.1c               h1de35cc_1
packaging                 19.0                     py37_0
pandas                    0.25.0           py37h0a44026_0
pandoc                    2.2.3.2                       0
pandocfilters             1.4.2                    py37_1
parso                     0.5.0                      py_0
pcre                      8.43                 h0a44026_0
pexpect                   4.7.0                    py37_0
pickleshare               0.7.5                    py37_0
pip                       19.1.1                   py37_0
pluggy                    0.12.0                     py_0
prometheus_client         0.7.1                      py_0
prompt_toolkit            2.0.9                    py37_0
protobuf                  3.8.0            py37h0a44026_0
ptyprocess                0.6.0                    py37_0
py                        1.8.0                    py37_0
py-boost                  1.67.0           py37h6440ff4_4
py4j                      0.10.7                   py37_0
pyarrow                   0.11.1           py37h0a44026_0
pygments                  2.4.2                      py_0
pylint                    2.3.1                    py37_0
pyparsing                 2.4.0                      py_0
pyqt                      5.9.2            py37h655552a_2
pyrsistent                0.14.11          py37h1de35cc_0
pyspark                   2.4.3                      py_0
pytest                    5.0.1                    py37_0
python                    3.7.3                h359304d_0
python-dateutil           2.8.0                    py37_0
pytz                      2019.1                     py_0
pyzmq                     18.0.0           py37h0a44026_0
qt                        5.9.7                h468cd18_1
qtconsole                 4.5.2                      py_0
readline                  7.0                  h1de35cc_5
rhash                     1.3.8                ha12b0ac_0
scala                     2.11.1                        0    anaconda-cluster
scikit-learn              0.21.2           py37h27c97d8_0
scipy                     1.3.0            py37h1410ff5_0
send2trash                1.5.0                    py37_0
setuptools                41.0.1                   py37_0
sip                       4.19.8           py37h0a44026_0
six                       1.12.0                   py37_0
snappy                    1.1.7                he62c110_3
sqlite                    3.29.0               ha441bb4_0
tensorboard               1.13.1           py37haf313ee_0
tensorflow                1.13.1          mkl_py37h70c3834_0
tensorflow-base           1.13.1          mkl_py37h66b1bf0_0
tensorflow-estimator      1.13.0                     py_0
termcolor                 1.1.0                    py37_1
terminado                 0.8.2                    py37_0
testpath                  0.4.2                    py37_0
thrift-cpp                0.11.0               hd79cdb6_3
tk                        8.6.8                ha441bb4_0
tornado                   6.0.3            py37h1de35cc_0
traitlets                 4.3.2                    py37_0
wcwidth                   0.1.7                    py37_0
webencodings              0.5.1                    py37_1
werkzeug                  0.15.4                     py_0
wheel                     0.33.4                   py37_0
widgetsnbextension        3.5.0                    py37_0
wrapt                     1.11.2           py37h1de35cc_0
xz                        5.2.4                h1de35cc_4
zeromq                    4.3.1                h0a44026_3
zipp                      0.5.1                      py_0
zlib                      1.2.11               h1de35cc_3
zstd                      1.3.7                h5bba6e5_0
--------------------------------------------------------------------------------

</p>
</details>
user: ehsantn
issue_4434: state: open
title: Adding Jitclass as Identifier for other Jitclasses/function types
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

At the moment it is not possible to use Jitclasses as explicit types for function to accept/return, in addition it is not possible to use Jitclasses as variable types in other Jitclasses or to create a "copy" function or any other function inside a Jitclass that returns an object of said class.
At my point of view this should be possible, and therefore added that Jitclass objects count as numba Identifiers.
user: Hendiadyoin1
issue_4428: state: open
title: Add array tuple index from array unsafe function
body: 
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

A common, but hard to do in Numba, use case is users wanting to index one array with another via tuple (some discussion https://gitter.im/numba/numba?at=5d4bb0a4bb5364334cf22888), i.e. (from https://gitter.im/numba/numba?at=5d4b3954c87a0963e72e1581):

```python
def test(): 
    arr = np.zeros((3, 3))
    coord = np.array([1,2])
    arr[tuple(coord)] = 7 
    return arr
```
this won't work unless something like this is used:
https://gist.github.com/sklam/830fe01343ba95828c3b24c391855c86

This ticket proposes that this is formalised as part of `numba.unsafe.array` as it would be useful for users and is then also tested, maintained etc.
user: stuartarchibald
issue_4424: state: open
title: Compilation/Type Error with opaque pointers in cffi
body: I am trying to use a cffi wrapped c library that uses opaque pointers. I created a minimal C lib similar to it for debugging purposes. It contains two functions: `make_vector` that creates an opaque pointer object, and `sum` that consumes it.

<details>

```python
from cffi import FFI
import numba
import numba.cffi_support
import numpy as np

ffi = FFI()
ffi.set_source(
    '_ffi',
    '''
    struct Vector_t {
        double x1;
        double x2;
    };
    typedef struct Vector_t *Vector;
    typedef double(*Vecfunc)(Vector);

    Vector make_vector(void) {
        Vector vec = malloc(sizeof(struct Vector_t));
        if (vec == NULL) {
            abort();
        }
        return vec;
    }
    
    double apply_vecfunc(Vecfunc func, Vector vec) {
        return func(vec);
    }

    double sum(Vector vec) {
        return vec->x1 + vec->x2;
    }
    '''
)
ffi.cdef(
    '''
    typedef ... *Vector;
    typedef double(*Vecfunc)(Vector);
    
    double apply_vecfunc(Vecfunc func, Vector vec);
    Vector make_vector(void);
    double sum(Vector vec);
    ''')
ffi.compile()
```

</details>

If I call the functions in nopython mode, I get typing errors, because as far as I understand it, numba doesn't know how to map the return type of `make_vector` to a numba type.

```python
numba.cffi_support.register_module(_ffi)
#numba.cffi_support.register_type(
#    _ffi.ffi.typeof('Vector').item,
#    numba.types.Opaque('Vector'))

@numba.njit
def foo():
    vec = _ffi.lib.make_vector()
    return _ffi.lib.sum(vec)

foo()
```

<details>

```
TypingError                               Traceback (most recent call last)
<ipython-input-7-c19b6d9633cf> in <module>
----> 1 foo()

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375 
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344 
    345         argtypes = []

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at resolving type of attribute "make_vector" of "$0.2".
<ctype 'struct $$Vector'>
[1] During: typing of get attribute at <ipython-input-6-fb79965445b4> (8)
Enable logging at debug level for details.

File "<ipython-input-6-fb79965445b4>", line 8:
def foo():
    vec = _ffi.lib.make_vector()
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```

</details>

If I uncomment the line that registers `Vector` as an opaque type, type checking seems to work.
```python
>>> vec = _ffi.lib.make_vector()
>>> numba.cffi_support.map_type(_ffi.ffi.typeof(vec))
Vector*
```
But it fails with an exception during compilation:

<details>

```
AttributeError                            Traceback (most recent call last)
~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    661     try:
--> 662         yield
    663     except NumbaError as e:

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    257                                    loc=self.loc, errcls_=defaulterrcls):
--> 258                 self.lower_inst(inst)
    259 

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower_inst(self, inst)
    300             ty = self.typeof(inst.target.name)
--> 301             val = self.lower_assign(ty, inst)
    302             self.storevar(val, inst.target.name)

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    458         elif isinstance(value, ir.Expr):
--> 459             return self.lower_expr(ty, value)
    460 

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower_expr(self, resty, expr)
   1008             else:
-> 1009                 impl = self.context.get_getattr(ty, expr.attr)
   1010                 attrty = self.context.typing_context.resolve_getattr(ty,

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/targets/base.py in get_getattr(self, typ, attr)
    587                 pyval = getattr(typ.pymod, attr)
--> 588                 llval = self.get_constant(attrty, pyval)
    589                 def imp(context, builder, typ, val, attr):

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/targets/base.py in get_constant(self, ty, val)
    509         # HACK: pass builder=None to preserve get_constant() API
--> 510         return self.get_constant_generic(None, ty, val)
    511 

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/targets/base.py in get_constant_generic(self, builder, ty, val)
    499             impl = self._get_constants.find((ty,))
--> 500             return impl(self, builder, ty, val)
    501         except NotImplementedError:

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/targets/builtins.py in constant_function_pointer(context, builder, ty, pyval)
    292     ptrval = context.add_dynamic_addr(builder, ty.get_pointer(pyval),
--> 293                                       info=str(pyval))
    294     return builder.bitcast(ptrval, ptrty)

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/targets/base.py in add_dynamic_addr(self, builder, intaddr, info)
   1052         assert isinstance(intaddr, utils.INT_TYPES), 'dyn addr not of int type'
-> 1053         mod = builder.module
   1054         llvoidptr = self.get_value_type(types.voidptr)

AttributeError: 'NoneType' object has no attribute 'module'

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-9-c19b6d9633cf> in <module>
----> 1 foo()

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    393                     e.patch_message(''.join(e.args) + help_msg)
    394             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 395             raise e
    396 
    397     def inspect_llvm(self, signature=None):

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    350                 argtypes.append(self.typeof_pyval(a))
    351         try:
--> 352             return self.compile(tuple(argtypes))
    353         except errors.TypingError as e:
    354             # Intercept typing error that may be due to an argument

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, sig)
    691 
    692             self._cache_misses[sig] += 1
--> 693             cres = self._compiler.compile(args, return_type)
    694             self.add_overload(cres)
    695             self._cache.save_overload(sig, cres)

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     74 
     75     def compile(self, args, return_type):
---> 76         status, retval = self._compile_cached(args, return_type)
     77         if status:
     78             return retval

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in _compile_cached(self, args, return_type)
     88 
     89         try:
---> 90             retval = self._compile_core(args, return_type)
     91         except errors.TypingError as e:
     92             self._failed_cache[key] = e

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/dispatcher.py in _compile_core(self, args, return_type)
    106                                       args=args, return_type=return_type,
    107                                       flags=flags, locals=self.locals,
--> 108                                       pipeline_class=self.pipeline_class)
    109         # Check typing error if object mode is used
    110         if cres.typing_error is not None and not flags.enable_pyobject:

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    970     pipeline = pipeline_class(typingctx, targetctx, library,
    971                               args, return_type, flags, locals)
--> 972     return pipeline.compile_extra(func)
    973 
    974 

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    388         self.lifted = ()
    389         self.lifted_from = None
--> 390         return self._compile_bytecode()
    391 
    392     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    901         """
    902         assert self.func_ir is None
--> 903         return self._compile_core()
    904 
    905     def _compile_ir(self):

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    888         self.define_pipelines(pm)
    889         pm.finalize()
--> 890         res = pm.run(self.status)
    891         if res is not None:
    892             # Early pipeline completion

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    264                     # No more fallback pipelines?
    265                     if is_final_pipeline:
--> 266                         raise patched_exception
    267                     # Go to next fallback pipeline
    268                     else:

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    255                 try:
    256                     event("-- %s" % stage_name)
--> 257                     stage()
    258                 except _EarlyPipelineCompletion as e:
    259                     return e.result

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in stage_nopython_backend(self)
    762         """
    763         lowerfn = self.backend_nopython_mode
--> 764         self._backend(lowerfn, objectmode=False)
    765 
    766     def stage_compile_interp_mode(self):

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    701             self.library.enable_object_caching()
    702 
--> 703         lowered = lowerfn()
    704         signature = typing.signature(self.return_type, *self.args)
    705         self.cr = compile_result(

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in backend_nopython_mode(self)
    688                 self.calltypes,
    689                 self.flags,
--> 690                 self.metadata)
    691 
    692     def _backend(self, lowerfn, objectmode):

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags, metadata)
   1141         lower = lowering.Lower(targetctx, library, fndesc, interp,
   1142                                metadata=metadata)
-> 1143         lower.lower()
   1144         if not flags.no_cpython_wrapper:
   1145             lower.create_cpython_wrapper(flags.release_gil)

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower(self)
    175         if self.generator_info is None:
    176             self.genlower = None
--> 177             self.lower_normal_function(self.fndesc)
    178         else:
    179             self.genlower = self.GeneratorLower(self)

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    216         # Init argument values
    217         self.extract_function_arguments()
--> 218         entry_block_tail = self.lower_function_body()
    219 
    220         # Close tail of entry block

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower_function_body(self)
    241             bb = self.blkmap[offset]
    242             self.builder.position_at_end(bb)
--> 243             self.lower_block(block)
    244 
    245         self.post_lower()

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    256             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    257                                    loc=self.loc, errcls_=defaulterrcls):
--> 258                 self.lower_inst(inst)
    259 
    260     def create_cpython_wrapper(self, release_gil=False):

~/anaconda3/envs/pymc/lib/python3.7/contextlib.py in __exit__(self, type, value, traceback)
    128                 value = type()
    129             try:
--> 130                 self.gen.throw(type, value, traceback)
    131             except StopIteration as exc:
    132                 # Suppress StopIteration *unless* it's the same exception that

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    668         from numba import config
    669         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 670         six.reraise(type(newerr), newerr, tb)
    671 
    672 

~/anaconda3/envs/pymc/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660 
    661 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
'NoneType' object has no attribute 'module'

File "<ipython-input-8-3672370f2198>", line 8:
def foo():
    vec = _ffi.lib.make_vector()
    ^

[1] During: lowering "$0.3 = getattr(value=$0.2, attr=make_vector)" at <ipython-input-8-3672370f2198> (8)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.45.1.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```

</details>

The error seems not to be related to the `Vector` type directly. I also hacked the numba source code a bit to make sure that all cffi `Vector*` types map to `numba.types.voidptr` in `numba.cffi_support.map_type`, but this led to the same error message during compilation.

Is it that opaque types through cffi are in general not supported?

The error message is the same as #4417.
This seems related: #4115
user: aseyboldt
issue_4423: state: open
title: omitted types forcing additional compilation?
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
This
```python
from numba import njit

@njit
def foo(a, kwarg=False):
    if kwarg:
        return 10
    else:
        return 100

foo(1)
print(foo.signatures)
foo(1, True)
print(foo.signatures)
```
does this:
```
[(int64, omitted(default=False))]
[(int64, omitted(default=False)), (int64, bool)]
```
when it seems like the second call ought to be able to use the `CompileResult` of the first were the signatures `de-omitted`, for want of a better expression. The pointless branch was to check that branch pruning wasn't killing branches based on the omitted type and it doesn't appear to be the case.

CC @lesshaste 

Context: https://gitter.im/numba/numba?at=5d4a955c1db76d0ffe8c2f55


user: stuartarchibald
issue_4419: state: open
title: @njit numpy mean incorrect result
body: Calculating the mean of an array using numpy.mean() returns a different value if the method is jitted. Sample code block (below) returns 92.22270202636719 for jitted mean and 90.123474 for np.mean().
```
import h5py
import numpy as np
from numba import jit, njit

@njit
def mean(arr): return np.mean(arr)
h5f = h5py.File('wmap-nside=64-m=720-test.h5','r')
arr = h5f['ctheta'][:]
print(mean(arr))
print(np.mean(arr))

```
[wmap-nside=64-m=720-test.zip](https://github.com/numba/numba/files/3474933/wmap-nside.64-m.720-test.zip)
user: rayhagimoto
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_4414: state: open
title: TypingError: `np.max(..., axis=1)`
body: ```
@jit(nopython=True)
def ts_mean(x,n,d):	

	x_ = np.lib.stride_tricks.as_strided(x,shape=(n-d+1,d),strides=(x.strides[0],x.strides[0])) 
	ret = x_.sum(1)/d
	return ret

@jit(nopython=True)
def ts_mean_mat(m,d):

	if d == 1:
		return m 

	rowNum = m.shape[0]
	colNum = m.shape[1]
	retMat = np.zeros((rowNum-d+1,colNum))
	
	for i in np.arange(colNum):
		retMat[:,i] = ts_mean(m[:,i],rowNum,d)

	return retMat
```

```
def ts_max(x,n,d):

	n = len(x)
	
	x_ = np.lib.stride_tricks.as_strided(x,shape=(n-d+1,d),strides=(x.strides[0],x.strides[0]))

	ret = np.max(x_,axis=1)
	return ret 

@jit(nopython=True)
def ts_max_mat(m,d):

	if d == 1:
		return m

	rowNum = m.shape[0]
	colNum = m.shape[1]
	
	retMat = np.zeros((rowNum-d+1,colNum))
	
	for i in np.arange(colNum):
		retMat[:,i] = ts_max(m[:,i],rowNum,d)

	return retMat
```

it seems no difference between the above codes, but ts_mean_mat can work, and ts_max_mat cannot work. How can I fix the problem .

```
TypingError: Failed at nopython (nopython frontend)
Untyped global name 'ts_max': cannot determine Numba type of <class 'function'>

File "<ipython-input-200-c53c88612e92>", line 22:
def ts_max_mat(m,d):
    <source elided>
	for i in np.arange(colNum):
		retMat[:,i] = ts_max(m[:,i],rowNum,d)
  ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.
```

This is the error report for ts_max_mat

numba.__version__: 0.38.0
python: 3.6.8



user: isaac-you
issue_4413: state: open
title: Accessing array fields works via getattr while it should not.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Here's an example case:
```
from numba import njit, jit
import numpy as np

arr = np.array([1,2], dtype=np.dtype([('value', 'i8')]))
@njit
def foo():
    return arr.value
print(foo())
def bar():
    return arr.value
print(bar())
```
Calling `foo()` returns the value of `arr['value']` while calling pure Python function `bar` raises `AttributeError` (which is expected).

Using numba version 0.46.0dev0+42.g81b91f93c
user: pearu
issue_4404: state: open
title: Support keyword arguments with guvectorize
body: Today it seems like it's not possible to pass through non-array parameters to functions decorated with `guvectorize`

```python
from numba import guvectorize, i8

@guvectorize([(i8, i8[:])], '()->()')
def g(x, out, factor=2):
    out[0] = x * factor
```

I don't have a sense of how feasible this is, but it would be nice.

<details>

```python-traceback
TypeError                                 Traceback (most recent call last)
<ipython-input-2-7e803a6af717> in <module>
      1 @guvectorize([(i8, i8[:])], '()->()')
----> 2 def g(x, out, factor=2):
      3     out[0] = x * factor
      4

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/npyufunc/decorators.py in wrap(func)
    177         guvec = GUVectorize(func, signature, **kws)
    178         for fty in ftylist:
--> 179             guvec.add(fty)
    180         return guvec.build_ufunc()
    181

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/npyufunc/ufuncbuilder.py in add(self, sig)
    192             targetoptions = self.nb_func.targetoptions
    193         cres, args, return_type = _compile_element_wise_function(
--> 194             self.nb_func, targetoptions, sig)
    195         sig = self._finalize_signature(cres, args, return_type)
    196         self._sigs.append(sig)

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/npyufunc/ufuncbuilder.py in _compile_element_wise_function(nb_func, targetoptions, sig)
    126     # Do compilation
    127     # Return CompileResult to test
--> 128     cres = nb_func.compile(sig, **targetoptions)
    129     args, return_type = sigutils.normalize_signature(sig)
    130     return cres, args, return_type

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/npyufunc/ufuncbuilder.py in compile(self, sig, locals, **targetoptions)
     75         flags.unset("enable_looplift")
     76
---> 77         return self._compile_core(sig, flags, locals)
     78
     79     def _compile_core(self, sig, flags, locals):

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/npyufunc/ufuncbuilder.py in _compile_core(self, sig, flags, locals)
    110                                               self.py_func, args=args,
    111                                               return_type=return_type,
--> 112                                               flags=flags, locals=locals)
    113
    114                 # cache lookup failed before so safe to save

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    924     pipeline = pipeline_class(typingctx, targetctx, library,
    925                               args, return_type, flags, locals)
--> 926     return pipeline.compile_extra(func)
    927
    928

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    372         self.lifted = ()
    373         self.lifted_from = None
--> 374         return self._compile_bytecode()
    375
    376     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    855         """
    856         assert self.func_ir is None
--> 857         return self._compile_core()
    858
    859     def _compile_ir(self):

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    842         self.define_pipelines(pm)
    843         pm.finalize()
--> 844         res = pm.run(self.status)
    845         if res is not None:
    846             # Early pipeline completion

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    253                     # No more fallback pipelines?
    254                     if is_final_pipeline:
--> 255                         raise patched_exception
    256                     # Go to next fallback pipeline
    257                     else:

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    244                 try:
    245                     event(stage_name)
--> 246                     stage()
    247                 except _EarlyPipelineCompletion as e:
    248                     return e.result

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in stage_analyze_bytecode(self)
    387         """
    388         func_ir = translate_stage(self.func_id, self.bc)
--> 389         self._set_and_check_ir(func_ir)
    390
    391     def _set_and_check_ir(self, func_ir):

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/compiler.py in _set_and_check_ir(self, func_ir)
    399             raise TypeError("Signature mismatch: %d argument types given, "
    400                             "but function takes %d arguments"
--> 401                             % (len(self.args), self.nargs))
    402
    403     def stage_process_ir(self):

TypeError: Failed in object mode pipeline (step: analyzing bytecode)
Signature mismatch: 2 argument types given, but function takes 3 arguments
```

</details>
user: mrocklin
issue_4402: state: open
title: meta issue: fp16 support
body: This meta issue lists the concrete tasks needed to implement half-precision floating type. (#4395).

llvmlite: 
- [x] add `half` type

numba:
- [ ] add `float16` type and conversion to/from `numpy.float16`.
- [ ] setup implicit casting rules.  (note: survey what numpy does with float16 casting).
- [ ] implement basic arithmetic ops.
    - [ ] add, sub, mul
    - [ ] div, rem (separate item because CUDA PTX do not provide these it seems)
- [ ] decide what to do with other math functions? implicit cast to float32 variant?






user: sklam
issue_4399: state: open
title: Numpy corrcoef performance is better without Numba
body: Hi,

I noticed that `numpy.corrcoef` performs better without the `@njit` decorator.

I was expecting that using the `@njit` decorator should result in on-par or better performance because `numpy.corrcoef` is one of the supported functions according to this [document](https://numba.pydata.org/numba-doc/latest/reference/numpysupported.html).

Following is a minimum working code to demonstrate the issue.
```python
from numba import njit
import numpy as np

def corr_cpu(x):
    return np.corrcoef(x, rowvar=False)

@njit
def corr_cpu_optimized(x):
    return np.corrcoef(x, rowvar=False)

x = np.random.rand(2000000, 100)

print("unoptimized:")
%timeit corr_cpu(x)

print("optimized:")
%timeit corr_cpu_optimized(x)
```

output:
```python
unoptimized:
739 ms ± 487 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
optimized:
5.69 s ± 6.73 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
```

Hardware information:
```
__Hardware Information__
Machine                                       : x86_64
CPU Name                                      : skylake
Number of accessible CPU cores                : 4
Listed accessible CPUs cores                  : 0-3
CFS restrictions                              : None
CPU Features                                  :
64bit adx aes avx avx2 bmi bmi2 clflushopt cmov cx16 f16c fma fsgsbase invpcid
lzcnt mmx movbe pclmul popcnt prfchw rdrnd rdseed sahf sgx sse sse2 sse3 sse4.1
sse4.2 ssse3 xsave xsavec xsaveopt xsaves

__OS Information__
Platform                                      : Linux-4.4.0-143-generic-x86_64-with-debian-stretch-sid
Release                                       : 4.4.0-143-generic
System Name                                   : Linux
Version                                       : #169-Ubuntu SMP Thu Feb 7 07:56:38 UTC 2019
OS specific info                              : debianstretch/sid
glibc info                                    : glibc 2.10

__Python Information__
Python Compiler                               : GCC 7.3.0
Python Implementation                         : CPython
Python Version                                : 3.7.3
Python Locale                                 : en_US UTF-8

__LLVM information__
LLVM version                                  : 8.0.0

__CUDA Information__
Found 1 CUDA devices
id 0       b'GeForce GT 730'                              [SUPPORTED]
                      compute capability: 3.5
                           pci device id: 0
                              pci bus id: 1
Summary:
        1/1 devices are supported
CUDA driver version                           : 10010
CUDA libraries:
Finding cublas from Conda environment
        named  libcublas.so.10.0.130
        trying to open library...       ok
Finding cusparse from Conda environment
        named  libcusparse.so.10.0.130
        trying to open library...       ok
Finding cufft from Conda environment
        named  libcufft.so.10.0.145
        trying to open library...       ok
Finding curand from Conda environment
        named  libcurand.so.10.0.130
        trying to open library...       ok
Finding nvvm from Conda environment
        named  libnvvm.so.3.3.0
        trying to open library...       ok
Finding libdevice from Conda environment
        searching for compute_20...     ok
        searching for compute_30...     ok
        searching for compute_35...     ok
        searching for compute_50...     ok

...
```
user: varunbpatil
labels: performance: performance related issue
issue_4395: state: open
title: fp16 GPU support
body: (Filing issue as requested at https://twitter.com/jeremyphoward/status/1156949482694574080 )

On any GPU with tensor cores (which is all non-embedded cards sold by Nvidia today AFAIK) fp16 is necessary to use them. For most deep learning models this results in a 3x-5x performance improvement. As a result, fp16 is becoming a requirement for deep learning.

Thanks to `__cuda_array_interface__` it is now convenient to write (for example) PyTorch kernels in Numba. Therefore there is an increasing interest in the deep learning community in using Numba. For instance, we're interested in converting our QRNN implementation in fastai from C++/CUDA to Numba. This would allow our users to use it without installing nvcc, since Numba only requires the conda cudatoolkit package, and it would also simplify our code and build process significantly.

Also, using Numba would allow us in our courses at https://course.fast.ai to start teaching students how to write their own kernels in Python.

Here's an example of the kind of kernel we'd like to be able to write in Numba and have support fp16: https://github.com/fastai/fastai/blob/master/fastai/text/models/forget_mult_cuda_kernel.cu

Note that we don't really need to support tensor core accelerated stuff within Numba itself - just basic operations would be fine. Generally the kind of thing we'd expect to see written in Numba is small pieces of a larger network (like the forget_mult examples above) - so we want to avoid having to cast to/from fp16 to use those pieces, but they don't really need to use tensor cores themselves.
user: jph00
labels: CUDA: CUDA related issue/PR
issue_4389: state: open
title: Ahead-of-time compilation for cuda.jit
body: As discussed earlier on Gitter (starting [here](https://gitter.im/numba/numba?at=5cf68107ff3f016baaa36413)), it's desirable to have a `pycc` counterpart for `cuda.jit`. The motivation is 
1. avoid Numba dependency 
2. avoid compilation overhead
3. avoid accidental unwanted compilation (in some cases if recompiling happens, it should error out as it's not expected)

This also aligns with #4342.

As @sklam pointed out, the PTX code is contained in the object generated by `cuda.jit`, and it could be picked and passed around. While this has no problem in supporting different GPU generations and models, this would still require depending on Numba for unpickling.

My current understanding is that name mangling is the first issue to be overcome.
user: leofang
labels: CUDA: CUDA related issue/PR
issue_4382: state: open
title: Default argument with typed list?
body: (From gitter discussion: https://gitter.im/numba/numba?at=5d3f641b6009f73e06eb0f99)

using empty list as the default value to an argument is an interesting situation. First, numba doesn’t support the use of reflected-list or the new typed list as default argument value currently. Second, in python, default argument of list (or any mutable objects) can be easily misused; i.e.

```python
In [1]: def foo(x=[]):
   ...:     x.append(1)
   ...:     return x
   ...:

In [2]: foo()
Out[2]: [1]

In [3]: foo()
Out[3]: [1, 1]
```
user: sklam
labels: discussion: An issue requiring discussion
issue_4380: state: open
title: numba fails to be imported in Termux, aarch64, android 9
body: I installed numba in Termux using the usual `pip install numba` and it succeeded, however trying to import it fails like this:

```
$ python -c "import numba"
Traceback (most recent call last):
  File "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/typeconv/typeconv.py", line 6, in <module>
    from . import _typeconv
ImportError: dlopen failed: cannot locate symbol "PyExc_ValueError" referenced by "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/typeconv/_typeconv.cpython-37m.so"...

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/__init__.py", line 18, in <module>
    from .special import typeof, prange, pndindex, gdb, gdb_breakpoint, gdb_init
  File "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/special.py", line 3, in <module>
    from .typing.typeof import typeof
  File "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/typing/__init__.py", line 2, in <module>
    from .context import BaseContext, Context
  File "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/typing/context.py", line 12, in <module>
    from numba.typeconv import Conversion, rules
  File "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/typeconv/rules.py", line 3, in <module>
    from .typeconv import TypeManager, TypeCastingRules
  File "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/typeconv/typeconv.py", line 16, in <module>
    raise ImportError(msg)
ImportError: Numba could not be imported.
If you are seeing this message and are undertaking Numba development work, you may need to re-run:

python setup.py build_ext --inplace

(Also, please check the development set up guide http://numba.pydata.org/numba-doc/latest/developer/contributing.html.)

If you are not working on Numba development:

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!

The original error was: 'dlopen failed: cannot locate symbol "PyExc_ValueError" referenced by "/data/data/com.termux/files/usr/lib/python3.7/site-packages/numba/typeconv/_typeconv.cpython-37m.so"...' 
```

Note that llvmlite is installed and imports just fine:

```
$ pip list | grep llvm
llvmlite           0.29.0 
$ python -c "import llvmlite"
$ 
```
user: tigran123
labels: ISA: ARM: Issue related to ARM ISA
issue_4378: state: open
title: CUDA flag to emulate `-fdefault-real-*`/force e.g. `float32` throughout
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

A commonly requested/observed use case in CUDA is users wanting to force all floating point types to be `float32` because of the performance gain present in doing so. Having to manually cast everything obfuscates the source code and the use of the `locals` kwarg is not often advised as it may set a precedent that creates considerably harder to fix/debug problems.

Something like:

```python
@cuda.jit(force_float=types.float32)
```

might work by resolving types as normal, and then just replacing `float64` by `float32`, but this presents a risk that there is a `float64` variant of some operation for which there is not a `float32`. The other option is such a flag alters type inference itself to disable 8 byte wide floating point types such that `float64` and `complex128` are not accessible.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
labels: CUDA: CUDA related issue/PR
issue_4370: state: open
title: Appending a Python int to a Numba typed list (of type np.intp) raises an error.
body: I can't append a  Python `int` to `nb.typed.List.empty_list(np.intp)`

```
Python 3.7.3 (default, Mar 27 2019, 16:54:48)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.6.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import numpy as np

In [2]: import numba as nb

In [3]: nb.typed.List.empty_list(np.intp).append(42)
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-3-20f63de11a16> in <module>
----> 1 nb.typed.List.empty_list(np.intp).append(42)

~/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/typed/typedlist.py in append(self, item)
    221         if not self._typed:
    222             self._initialise_list(item)
--> 223         _append(self, item)
    224
    225     def __setitem__(self, i, item):

~/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    374                 e.patch_message(msg)
    375
--> 376             error_rewrite(e, 'typing')
    377         except errors.UnsupportedError as e:
    378             # Something unsupported is present in the user code, add help info

~/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    341                 raise e
    342             else:
--> 343                 reraise(type(e), e, None)
    344
    345         argtypes = []

~/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.typeinfer.CallConstraint object at 0x624a51160>.
Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast int64 to <class 'numpy.int64'>: %".42" = load i64, i64* %"casteditem"

File "miniconda3/envs/uarray/lib/python3.7/site-packages/numba/listobject.py", line 433:
    def impl(l, item):
        <source elided>
        casteditem = _cast(item, itemty)
        status = _list_append(l, casteditem)
        ^

[1] During: lowering "$0.8 = call $0.5(l, casteditem, func=$0.5, args=[Var(l, /Users/hameerabbasi/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/listobject.py (432)), Var(casteditem, /Users/hameerabbasi/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/listobject.py (432))], kws=(), vararg=None)" at /Users/hameerabbasi/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/listobject.py (433)
[2] During: resolving callee type: BoundFunction((<class 'numba.types.containers.ListType'>, 'append') for ListType[<class 'numpy.int64'>])
[3] During: typing of call at /Users/hameerabbasi/miniconda3/envs/uarray/lib/python3.7/site-packages/numba/typed/typedlist.py (39)

Enable logging at debug level for details.

File "miniconda3/envs/uarray/lib/python3.7/site-packages/numba/typed/typedlist.py", line 39:
def _append(l, item):
    l.append(item)
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```

user: hameerabbasi
issue_4364: state: open
title: typed Dict slower than array with custom dtype
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

I was hoping numba typed Dict would get the same or nearly the same performance replacing an array with a custom dtype with a typed Dict (the advantage of the latter is that the shapes don't have to align). However, it seems that Dict is much slower than an array. In my actual code, the slowdown isn't this dramatic (about 2x slower).

```py
In [1]: from numba import njit, types

In [2]: from numba.typed import Dict

In [3]: import numpy as np

In [4]: dtype = np.dtype([('a', 'f8'), ('b', 'f8')], align=True)

In [5]: a = np.empty(10000, dtype=dtype)

In [6]: @njit
   ...: def test_array(a):
   ...:     val = 0
   ...:     for i in range(10000):
   ...:         val += a[i]['a'] + a[i]['b']
   ...:     return val
   ...:

In [7]: d = Dict.empty(key_type=types.unicode_type, value_type=types.float64[:])

In [8]: d['a'] = a['a']

In [9]: d['b'] = a['b']

In [10]: @njit
    ...: def test_dict(d):
    ...:     val = 0
    ...:     for i in range(10000):
    ...:         val += d['a'][i] + d['b'][i]
    ...:     return val
    ...:

In [11]: test_array(a)
Out[11]: nan

In [12]: test_dict(d)
Out[12]: nan

In [13]: %timeit test_array(a)
8.3 µs ± 6.58 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [14]: %timeit test_dict(d)
1.23 ms ± 18.8 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

This is on master (0.46.0dev0+12.g37ab1420f).

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

user: asmeurer
labels: performance: performance related issue
issue_4355: state: open
title: typed-list: expose a view for numpy arrays
body: As suggested in:

https://github.com/numba/numba/issues/4347

> Would it be possible for lists where the element type maps to a NumPy dtype to be able to create a NumPy array view on the internal list data? This view would become invalid if the list length is changed, but it would be useful in these sorts of cases to speed import of lists into things that expect numpy arrays.
user: esc
issue_4347: state: open
title: Implement using typed list in pandas constructor
body: I do not know if I should name it a bug or a feature request: Currently using the new numba typed list available since numba 0.45 for constructing a pandas data frame leads to the following error:

```
File "/fio/srvx7/leo/python/typed_dict_list.py", line 30, in <module>
  pl=pd.DataFrame(y)
File "/opt/anaconda3/lib/python3.7/site-packages/pandas/core/frame.py", line 451, in __init__
  copy=copy)
File "/opt/anaconda3/lib/python3.7/site-packages/pandas/core/internals/construction.py", line 146, in init_ndarray
  values = prep_ndarray(values, copy=copy)
File "/opt/anaconda3/lib/python3.7/site-packages/pandas/core/internals/construction.py", line 246, in prep_ndarray
  if values.ndim == 1:

builtins.AttributeError: 'List' object has no attribute 'ndim'
```

If I convert the List object to a regular list before putting it into the pandas constructor, it works. 
Using typed dicts as input for pandas constructors also works. 

Thus I am asking it if is feasible to add the ndim attribute to List objects. 


The whole reproducer:

```python
import os,sys,glob
from numba import *
from numba import types
from numba.typed import Dict,List
import numpy
import pandas as pd
import time

@njit
def lappend(n):
    
    l=List()
    for i in range(n):
        l.append(numpy.float32(i))
        
    return l

t=time.time()
x = Dict.empty(
    key_type=types.unicode_type,
    value_type=types.float32[:],
)

n=100000
x['a']=numpy.arange(n,dtype=numpy.float32)
y=lappend(n)

p=pd.DataFrame(x)

# pl=pd.DataFrame(list(y))  # this works
pl=pd.DataFrame(y)  # this fails

print(time.time()-t)
print()
```
user: leohaim
issue_4344: state: open
title: Meta issue: Error message improvements
body: A while back Numba had a very large rewrite of its error handling capabilities, the objectives were:

* To split the error types into roughly two categories 1) those which are likely resolvable by the user/problems with user code etc 2) those which are likely bugs/problems in numba itself.
* Add highlighting to the error messages to make the important bits stand out.
* Include the source line that is problematic in the error message.
* Reduce the size of the traceback in cases where the cause is clear to one frame + a couple of frames to the error rewrite location.
* Add "help" messages with links to on-line documentation.

Some of the above was modelled on what is found in error output modern C/C++ compilers.

The above massively improved the situation but further work is needed, feedback includes:
* Error messages are too technical
* Error messages are too large
* Too much detail
* If there's a typing error it is not clear to what it is referring.
* Tracebacks are still too long.

Following some discussion with @sklam and @esc, some ideas to address the above include:
* Switching around the error message output so that help/docs/guidance comes first, followed by the error message and the source line. This is to try and better match conventional error output where the last few lines of a traceback contain the error.
* Try and put the type information as annotations on the source line in the error message.
* Make type hinting work: Fix PR https://github.com/numba/numba/pull/3942
* Experiment with lazy frame injection to point to the actual source line of error a the manner of a standard traceback.
* Add better diagnostics tooling (perhaps better type propagation annotations).
* In part using the above, add in a command/link to the new shorter error messages which will add more context to the current error. i.e. `Rerun and set environment variable X for expanded diagnostics` or `Rerun with numba -d <> to see appropriate documentation links` etc.
* Make the compiler error messages show at runtime (poison types etc).

Conclusion:

There's a lot of ideas (and more are welcomed) but to start with these probably have the highest ROI:

* Start off with making error messages more terse and doing the reordering, still ask users to report critical errors.
* Add in the type information annotations.
* Make type hinting work: Fix PR https://github.com/numba/numba/pull/3942

user: stuartarchibald
issue_4342: state: open
title: SciPy 2019 feedback meta-issue
body: For lack of a better place to put this, I thought I would create a meta issue with things that were requested / brought up by Numba users at SciPy.  These can be spun out into separate issues as they are defined (and maybe close this issue once we feel like these have been spun out into concrete subissues).

* *Understanding of whether Numba has been able to "accelerate" some code:*  Due to the all-or-nothing approach of nopython mode, this feels like something we have to address with:
  - line profiling (which is being worked on)
  - indication of lifted loops (in mixed mode, see #4278)
  - indication of whether SIMD instructions have been generated in loops
  - indication of suboptimal code patterns (this is very hard and open ended, but there are some cases, like 64-bit data types on the GPU, that could be automated) 
* *Ahead of time compilation:* I believe the desire here is to avoid end users having any warm-up time by shipping pre-compiled functions targetting a "generic" version of the CPU architecture so they are likely to work for all users.  The obvious model here is Cython, which does .pyx -> C -> .so.  There are some options to work through:
   * Disk caching (which exists and is being improved currently) covers some of these issues, but not entirely.  A pre-populated cache could be shipped in binary packages, but currently cached functions depend on the version of Numba that compiled them (it is part of the cache key) because Numba does not define an internally stable ABI.  This would force recompilation of a prepopulated cache if the user didn't have the exact version of Numba that matched the creator of the binary package.  That negates a lot of the benefit.
  * Existing AoT compilation support: This currently creates an .so that statically links to the Numba runtime and no longer has Numba as a dependency (but still requires NumPy and Python).  This doesn't really handle Numba's advanced features, like type-based dispatch and parallel execution.
  * Use a `numba` subcommand to walk the environment, find packages that use Numba, and prepopulate the function cache for a desired architecture.  This is interesting (and opens up creative extension, like automatically doing profile-guided optimization), but requires manual user intervention.
  * Making Numba compiled code portable between Numba versions by separating out a stable, backward compatible "Numba Runtime" package from Numba, and make ahead of time compilation require the Numba runtime without all of Numba itself.  Then we would only need to key the cache on the NRT ABI version (which hopefully changes very infrequently) and not the Numba version itself.  Users would still be free to regenerate the cache for their specific architecture or with newer versions of Numba.
* *Error messages* - the constant struggle to reconstruct meaningful error messages for users when problems are detected in the pipeline.  There are numerous ideas proposed and in progress for this item.  More declarative typing of overloads, and more catching of errors before they reach lowering will help a lot.

user: seibert
issue_4340: state: open
title: Dynamic container to fixed tuple helpers
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Two or three times recently users have had cases where they want to convert a container to a tuple, in all cases custom code has had to be written to help. I think it'd be useful to generalise the code here:
https://github.com/numba/numba/blob/f76c3a5c1600a50588579239e238ac2140c81d95/numba/unsafe/ndarray.py#L42-L80

so as to wrap the intrinsic and do something factory function like dispatching on type for creating a fixed tuple from any container type. i.e. use case:
```
@njit
def foo(container):
    tup = to_fixed_tuple(container, len)
```


<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
issue_4333: state: open
title: Support numpy.isnan and numpy.isnat in cuda.jit kernels
body: Currently math.isnan is supported for checking for `NaN`s, but there's no way to check for `NaT`s easily short of viewing as an int64 and comparing to the minimum value (-9223372036854775808). Simple reproducer:
```python
import numpy as np
from numba import cuda

test_in = cuda.to_device(np.array([1,None,3], dtype='datetime64[ms]'))
test_out = cuda.to_device(np.array([1,2,3]))

@cuda.jit
def test_datetime_nat(in_array, out_array):
    i = cuda.grid(1)
    if i < in_array.size:
        if np.isnat(in_array[i]):
            out_array[i] = 100

test_datetime_nat.forall(test_in.size)(test_in, test_out)
```
user: kkraus14
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_4327: state: open
title: Specialize `operator` methods for boolean types (stop casting as int!).
body: Numba 0.44.1

This prints `bool` `int64`:

```
def f(xs):
    return np.empty(1, dtype=np.array([xs.dtype.type(0) * xs.dtype.type(0)]).dtype)

print(f(np.array([True], dtype=np.bool)).dtype)
print(nb.njit(f)(np.array([True], dtype=np.bool)).dtype)
```

This prints `int32` `int64`:

```
def f(xs):
    return np.empty(1, dtype=np.array([xs.dtype.type(0) + xs.dtype.type(0)]).dtype)

print(f(np.array([1], dtype=np.int32)).dtype)
print(nb.njit(f)(np.array([1], dtype=np.int32)).dtype)
```

I think in each case Numba should be getting the same dtype as Numpy does. There is no ambiguity about what the correct answer is.
user: batterseapower
issue_4324: state: open
title: Vector `@overload` not overwriting scalar one
body: - [X] I am using the ~latest released version of Numba~ master branch of Numba (most recent is visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

If I define a scalar overload for a function and then later define a vector overload, the vector overload appears to not be respected. A simple example is:

```python
In [1]: import numba

In [2]: import scipy.special as sc

In [3]: @numba.extending.overload(sc.gamma)
   ...: def gamma_scalar(a):
   ...:     if a is numba.types.float64:
   ...:         return lambda a: a**2
   ...:

In [4]: @numba.extending.overload(sc.gamma)
   ...: def gamma_vector(a):
   ...:     if isinstance(a, numba.types.Array):
   ...:         @numba.vectorize
   ...:         def vector(a):
   ...:             return a
   ...:         return lambda a: vector(a)
   ...:

In [5]: @numba.njit
   ...: def gamma(x):
   ...:     return sc.gamma(x)
   ...:

In [6]: import numpy as np

In [7]: gamma(2.0)
Out[7]: 4.0

In [8]: gamma(np.array([2.0]))
Out[8]: array([4.])
```

I would have expected to get `2.0` in `Out[8]`.


user: person142
issue_4315: state: open
title: Check dtype arguments for Function types
body: ## Feature request

As mentioned [here](https://github.com/numba/numba/issues/3993#issuecomment-484851921), numba chokes on creating arrays with statements like `np.zeros((2, 2), dtype=int)` or `np.zeros((2, 2), dtype=np.int)` [and similarly for `float` and `complex`], even though these are among the most common ways to construct arrays.  It turns out the correct way to do this would be with `np.zeros((2, 2), dtype=np.int_)`, which is something that — even having extensive experience with numpy and its C API — I had not thought to try until finding the solution in that other thread.  And in any case, it certainly seems to work against the goal of numba as being as simple as decorating normal python code.

@stuartarchibald suggested that the solution would be
> something that especially checks the dtype and if the type is identified as a `Function` class type it hints that you probably meant an equivalent concrete NumPy type

and noted that this is "not quite the same sort of code path as #3942".

user: moble
issue_4314: state: open
title: Dynamically-defined @guvectorized functions over dask distributed
body: Dynamically defined functions - namely, anything from a Jupyter notebook - can be executed over a dask distributed grid thanks to cloudpickle.
Functions decorated with @guvectorize can be pickled, but only as long as they are defined in a static module.

Type in a jupyter notebook:

```python
import distributed
from numba import guvectorize, i8

def f(x):
    return x * 2


@guvectorize([(i8, i8[:])], '()->()')
def g(x, out):
    out[0] = x * 2

    
client = distributed.Client()

print(f(2))
print(g(2))
print(client.submit(f, 2).result())
print(client.submit(g, 2).result())
```
Output:
```
4
4
4

AttributeError: module '__main__' has no attribute 'g'
```

Note that the above is not the same as just writing ``cloudpickle.loads(cloudpickle.dumps(g))``, which works (but isn't terribly useful) because loads and dumps are running in the same interpreter.


Workaround:
```python
def cp_guvectorize(*args, **kwargs):
    """Same as :func:`numba.guvectorize`, but can be used to decorate dynamically
    defined function and then pickle them with
    `cloudpickle <https://pypi.org/project/cloudpickle/>`_.
    On the other hand, it can't be called from another jit-compiled function.
    """

    def decorator(func):
        return _PickleableGUVectorized(func, args, kwargs)

    return decorator


class _PickleableGUVectorized:
    def __init__(self, func, guvectorize_args, guvectorize_kwargs):
        self.args = func, guvectorize_args, guvectorize_kwargs
        decorator = numba.guvectorize(*guvectorize_args, **guvectorize_kwargs)
        self.ufunc = decorator(func)

    def __reduce__(self):
        return _PickleableGUVectorized, self.args

    def __call__(self, *args, **kwargs):
        return self.ufunc(*args, **kwargs)

    
@cp_guvectorize([(i8, i8[:])], '()->()')
def h(x, out):
    out[0] = x * 2

print(client.submit(h, 2).result())
```
Output:
```
4
```
user: crusaderky
issue_4310: state: open
title: Python classes in numba cuda?
body: I am working on a project with numba cuda. It is convenience to write a cuda function in python. I am wondering if numba supports python class in the cuda kernel. I appreciate if anyone has ideas about it. 
user: MikeChenfu
labels: CUDA: CUDA related issue/PR
issue_4309: state: open
title: CUDA parallel range?
body: This may be a naive suggestion, so please feel free to close if not useful/out of scope. I've been playing with numba cuda jit functions and wondering how to make cuda programming more accessible. One obvious challenge is that there is a big conceptual jump from using numba cuda to generate ufuncs or gufuncs, where the block/thread structure of the computation is all hidden and handled for you automatically, versus writing your own cuda function where you have to explicitly manage threads and blocks yourself. When writing your own cuda function, I find I am often wanting to implement a parallel range, something I would implement using prange if implementing for parallel CPU execution, so I wondered if a prange equivalent feature for cuda jit functions might be possible. 

E.g., consider the following example from the docs:

```python
@cuda.jit
def increment_by_one(an_array):
    i = cuda.grid(1)
    if i < an_array.size:
        an_array[i] += 1
```

To run this, you need to decide the number of threads per block, then compute the number of blocks based on the input array size.

If I was writing the same function for parallel CPU execution, I might do:

```python
@numba.jit(parallel=True)
def increment_by_one(an_array):
    for i in numba.prange(an_array.shape[0]):
        an_array[i] += 1
```

So I'm wondering, would it be possible to have the equivalent of prange for cuda? E.g.:

```python
@cuda.jit
def increment_by_one(an_array):
    for i in cuda.range(an_array.shape[0]):
        an_array[i] += 1
```

The idea would be that launching this function with `cuda.range` would not require specifying number of threads or blocks, that would be handled for me.

Consider the 2D example from the numba cuda docs:

```python
@cuda.jit
def increment_a_2D_array(an_array):
    x, y = cuda.grid(2)
    if x < an_array.shape[0] and y < an_array.shape[1]:
       an_array[x, y] += 1
```

Similarly, would it possible to do something like:

```python
@cuda.jit
def increment_a_2D_array(an_array):
    for x, y in cuda.product(an_array.shape[0], an_array.shape[1]):
       an_array[x, y] += 1
```

I also have a use case where I want to compute pairwise distance, and so I need to iterate over all combinations of indices. E.g., currently I do:

```python
@cuda.jit(numba.void(numba.float32[:, :], numba.float32[:, :]))
def pdist_cityblock_cuda(x, out):
    m = x.shape[0]
    n = x.shape[1]
    j, k = cuda.grid(2)
    if j < n and k < n and j < k:
        dd = np.float32(0)
        for i in range(m):
            vj = x[i, j]
            vk = x[i, k]
            d = math.fabs(vj - vk)
            dd += d
        out[j, k] = dd
```

...which requires manually specifying threads and blocks. But I wonder if I could instead have:

```python
@cuda.jit(numba.void(numba.float32[:, :], numba.float32[:, :]))
def pdist_cityblock_cuda(x, out):
    m = x.shape[0]
    n = x.shape[1]
    for j, k in cuda.combinations(n, 2):
        dd = np.float32(0)
        for i in range(m):
            vj = x[i, j]
            vk = x[i, k]
            d = math.fabs(vj - vk)
            dd += d
        out[j, k] = dd
```

...where again threads and blocks would be handled for me.

Just a thought :-) cc @mrocklin.

user: alimanfoo
labels: CUDA: CUDA related issue/PR
issue_4290: state: open
title: Investigate PGO in the LLVM backend
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

As title.
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
issue_4289: state: open
title: JIT dask task fused blocks
body: Dask has the ability to fuse a number of tasks together into a single block. It'd be great if Numba could jit this if the block is amenable to doing so, and then share the jitted function with other threads.

Example (there's probably a more dask-like way to get this):
```python
from dask import array as da
import dask

n = 10
z = da.ones((n,))
x = da.cos(z) ** 2 + da.sin(z) ** 2
print(x)
print(x.compute())
x.visualize()


for k, v in x.dask.dicts.items():
    if isinstance(v, dask.blockwise.Blockwise):
        print(k, v.dsk)
```
gives:
```
add-2fa37458d05a7e6eefb11f21662c473a {'add-2fa37458d05a7e6eefb11f21662c473a': (<built-in function add>, '_0', '_1')}
pow-089cabc6919bf3b832fae3eb6a961be5 {'pow-089cabc6919bf3b832fae3eb6a961be5': (<built-in function pow>, '_0', '_1')}
cos-ebaf3409f3869cdc867b4c62ab5a8a65 {'cos-ebaf3409f3869cdc867b4c62ab5a8a65': (<ufunc 'cos'>, '_0')}
pow-d1f463afa18af866b974449ca6e56d81 {'pow-d1f463afa18af866b974449ca6e56d81': (<built-in function pow>, '_0', '_1')}
sin-506d289f597ceb5cb8ebe582a3bf0ec0 {'sin-506d289f597ceb5cb8ebe582a3bf0ec0': (<ufunc 'sin'>, '_0')}
```
The `_0` and `_1` refer to argument index, the rest are just references to functions, NumPy ufuncs, builtins etc. Obvious approaches to assembling a function are string building or AST based generation. It may be challenging to share such a generated function trivially from the dispatcher cache.
user: stuartarchibald
labels: discussion: An issue requiring discussion
issue_4288: state: open
title: Write N~=20? examples of doing commonly done things with Numba (CPU and GPU)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

As title. To act as a place for new users to start from that is near to a thing they want to do, or make it easer for new users to get to what they want by combining a few of these.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
issue_4286: state: open
title: Type highlighting in `inspect_types`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

It'd be useful to highlight all the inferred types in the `inspect_types` output so that, especially on GPUs, accidental upcast of types is trivial to spot. e.g. float64 is red, float32 is orange etc etc.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_4284: state: open
title: Add FAQ entry about scipy.special
body: Thanks to this project:

https://numba-special.readthedocs.io/en/latest/index.html

There are now wrappers for the `scipy.special` functions.  We should mention this project in our FAQ.

As a side question: This implementation requires individually extracting all the function pointers using a .pyx file:

https://github.com/person142/numba_special/blob/master/numba_special/function_pointers.pyx

I wonder if there is a way to do that more automatically...
user: seibert
labels: scipy: Requests for scipy features
scumba: Issue relating to SciPy support that could exist in Numba "Scumba!"
issue_4278: state: open
title: New @jit option to get mixed nopython/forceobj (old default behavior)
body: ## Feature request

In a recent Numba release, the old fallback to object mode has been deprecated; the future behavior of `@numba.jit` will be the same as `@numba.njit`. One thing that was lost, however, was the mode that would partially lower a function (e.g. for loops that consist of purely lowerable variables and functions) and partially use object mode (e.g. statements outside the for loops that use unlowerable functions or functions unknown to Numba).

This is neither `nopython=True`, which attempts to lower everything and raises an error if unsuccessful, nor `forceobj=True`, which uses object mode for everything, lowering nothing.

Here is an example function in which the old default behavior was perfect:

```python
@numba.jit                                 # no qualification in old Numba
def run_numba(height, width, maxiterations=20):
    y, x = numpy.ogrid[-1:0:height*1j, -1.5:0:width*1j]
    c = x + y*1j
    fractal = numpy.full(c.shape, maxiterations, dtype=numpy.int32)
    for h in range(height):
        for w in range(width):             # for each pixel (h, w)...
            z = c[h, w]
            for i in range(maxiterations): # iterate at most 20 times
                z = z**2 + c[h, w]         # applying z → z² + c
                if abs(z) > 2:             # if it diverges (|z| > 2)
                    fractal[h, w] = i      # color the plane with iteration number
                    break                  # we're done, no need to keep iterating
    return fractal
```

The first few lines use functions unknown to Numba (`numpy.ogrid`, I believe) and, in the old behavior, were left in object mode, while the for loops were lowered. This demonstrably had the same running time as

```python
def run_numba(height, width, maxiterations=20):
    y, x = numpy.ogrid[-1:0:height*1j, -1.5:0:width*1j]
    c = x + y*1j
    fractal = numpy.full(c.shape, maxiterations, dtype=numpy.int32)
    tight_loop(c, fractal, maxiterations)
    return fractal

@numba.jit(nopython=True)
def tight_loop(c, fractal, maxiterations):
    for h in range(height):
        for w in range(width):             # for each pixel (h, w)...
            z = c[h, w]
            for i in range(maxiterations): # iterate at most 20 times
                z = z**2 + c[h, w]         # applying z → z² + c
                if abs(z) > 2:             # if it diverges (|z| > 2)
                    fractal[h, w] = i      # color the plane with iteration number
                    break                  # we're done, no need to keep iterating
```

except that I didn't have to find the cut point manually.

I don't mind that the new default will be `nopython=True` (I think it's a good change), but I'd like an option to get mixed compilation when I want it.
user: jpivarski
labels: discussion: An issue requiring discussion
issue_4274: state: open
title: temp_directory cleanup and revisit its impl
body: From https://github.com/numba/numba/pull/4254#discussion_r300071354

The testsuite is not cleaning up `temp_directory()` immediately.  We should revisit its design. 
user: sklam
labels: discussion: An issue requiring discussion
issue_4268: state: open
title: coverage.py support for Numba
body: It would be extremely helpful to be able to capture line coverage in Numba-compiled functions the same as in Python functions with coverage.py.

Doing this would most likely require something like the following:

* Numba compiler pipeline detects when coverage.py is active and injects a bit of code after each line to register execution of "line X in file Y" in a data structure.  We might need to switch on compiler debug mode to avoid code relocation that would confuse the measurement.
* We could make the data structure hang off the [Environment](https://github.com/numba/numba/blob/master/numba/_dynfunc.c#L17-L24) object that is passed to every function call.  It is append-only, but needs to be thread-safe.
* When transitioning back to the interpreter, we should run down the log of executed lines, populate the relevant data structure in coverage.py, and clear the log.

@cdeil noted on the mailing list that Cython has done this already.  Relevant links:
* http://blog.behnel.de/posts/coverage-analysis-for-cython-modules.html
* https://cython.readthedocs.io/en/latest/src/tutorial/profiling_tutorial.html#enabling-coverage-analysis
* https://github.com/cython/cython/blob/master/Cython/Coverage.py
user: seibert
issue_4267: state: open
title: prange hook for those of us who like status bar
body: I like status bars. Even if numba accelerates my code and parallelizes it for me, I want to know how much longer I have to wait.

In python this can be done with the multi threading library with something like:

```python
_i = Value('i', -1, lock=True)

def iterative_foo(total, throttle=50):
    # total is len(iterable)
    # do some things
    with _i.get_lock():
        _i.value += 1
    if total is not None:
        if _i.value % throttle == 0:
            print('\r                                                               ', flush=True, end='')
            print('\r{}%'.format(_i.value / total * 100), flush=True, end='')

def p_iterate(iterable):
    with Pool(processes=os.cpu_count()) as pool:
        total = len(iterable)
        sargs = [(total, 50) for i in range(total)]
        return pool.starmap(iterative_foo, sargs)
```

Assuming that the `iterative_foo` is non-negligible in computation, then the cost of the acquiring the lock is a fair pay off for this feature. 

It would be nice if when using prange, there was some way to access such a variable like `_i` to have such functionality. 

Alternatively `prange` could be extended to handle the printing on behalf of the user

```python
for _i in prange(len(iterable), status_bar=True, throttle=50):
    # parallel stuff here and now will auto print percentage or progress bar
```

user: SumNeuron
issue_4264: state: open
title: np.sum(X, Y) causes LoweringError
body: Take an array, say `x` and attempt to jit the function `np.sum(x, x)`.  i.e.

```
    @numba.jit(nopython=True, cache=True)
    def test(x):
        return np.sum(x, x)

    test(np.linspace(0, 1))
````

This will produce the error:

```
LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
No definition for lowering <function sum at 0x7f8b68092f28>(array(float64, 1d, C), array(float64, 1d, C)) -> array(float64, 0d, C)

File "<ipython-input-2-8fccba4d5c94>", line 3:
def test(x):
    return np.sum(x, x)
    ^

[1] During: lowering "$0.5 = call $0.2(x, x, func=$0.2, args=[Var(x, <ipython-input-2-8fccba4d5c94> (3)), Var(x, <ipython-input-2-8fccba4d5c94> (3))], kws=(), vararg=None)" at <ipython-input-2-8fccba4d5c94> (3)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```
user: RJTK
issue_4259: state: open
title: A sum module for collections of summation algorithms
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
(Related #4220, #3046)

As noted in numba core-devs discussion, we wanted to have a module of summation algorithms.  
user: sklam
issue_4258: state: open
title: refactor common code in reduce-like numpy methods
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

(Related to #4220)

As noted in discussion with numba core-devs, we wanted to refactor the common code of all reduce-like numpy methods to support `dtype` and `axis`.
user: sklam
issue_4257: state: open
title: Make it more clear what numba features can and can't be used in compiled code
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

I think the docs should be more clear about which numba functions and features can be used inside compiled code. As a motivating example, it took me a bit to figure out why I couldn't do this:

```python
from numba import njit, typed, typeof, types

@njit
def foo(x, y):
    d = typed.Dict(
        key_type=types.Tuple((types.int64, types.int64)),
        value_type=types.int64
    )
    for i in range(len(y)):
        d[(x[i], y[i])] = 1
    return d

foo([1,2,3], [4,5,6])
```

<details>
<summary> Error message </summary>

```python
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'Tuple' of type Module(<module 'numba.types' from '/usr/local/lib/python3.7/site-packages/numba/types/__init__.py'>)

File "<ipython-input-1-88121243b104>", line 9:
def foo(x, y):
    <source elided>
    d = typed.Dict(
        key_type=types.Tuple((types.int64, types.int64)),
        ^

[1] During: typing of get attribute at <ipython-input-1-88121243b104> (9)

File "<ipython-input-1-88121243b104>", line 9:
def foo(x, y):
    <source elided>
    d = typed.Dict(
        key_type=types.Tuple((types.int64, types.int64)),
        ^
```

</details>

Or:

```python
@njit
def bar(x, y):
    return typeof((x[0], y[0]))

bar(x, y)
```

<details>
<summary> Error message </summary>

```python
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'typeof': cannot determine Numba type of <class 'function'>

File "<ipython-input-2-d72e04322460>", line 3:
def bar(x, y):
    return typeof((x[0], y[0]))
    ^
```

</details>

The [docs on typing and signatures](http://numba.pydata.org/numba-doc/latest/reference/types.html) do not mention that these types and functions cannot be used in compiled code. This seems like a good place to mention it. Another useful place would be the error message, since `Unknown attribute 'Tuple'` and `Untyped global name 'typeof'` made me think there was something more wrong going on.

The docs kind of [say this will happen](http://numba.pydata.org/numba-doc/latest/reference/pysupported.html#id4) for `Dict`s, but it's right below an example where this goes unmentioned. Since I'm not familiar with the term "type-expression" in the context of numba, this one comment was not clear to me. I had initial presumed this had something to do with the overloaded subscript notation for dependent types.
user: ivirshup
issue_4250: state: open
title: Using .pop(0) on a list and then appending new elements crashes when called repeatedly
body: Hey,

I am encountering a strange issue that I have narrowed down to this code:

```python
import numba


@numba.jitclass(spec=[])
class TestClass:
    def __init__(self):
        pass

@numba.njit
def test_func():
    l = [TestClass()]
    l.pop(0)
    l.append(TestClass())
    l.append(TestClass())

def python_func():
    test_func() # Calling this once works (comment out next line)
    test_func() # Calling it again will crash.

if __name__ == "__main__":
    print("Numba version:", numba.__version__)
    python_func()
    print("Done")
```

Output:
```
Numba version: 0.44.1
free(): invalid pointer
Aborted (core dumped)
```

- Only calling `test_func()` once does not crash, calling it twice does
- Using a list of integers instead of `TestClass` does not crash
- Duplicating the code within `test_func` twice within it does not crash
- It only crashes when the list was empty after the pops (eg. starting with a list of 2 elements and calling `pop` twice crashes, but calling `pop()` only once doesn't)

OS: Kubuntu (kernel version 4.18.0-25-generic)
Python: 3.6.8 (from Conda 4.6.2)

user: RobinKa
issue_4246: state: open
title: storage variables inside functions do not work in nopython mode
body: A common coding convention is to use a "storage" variable to collect results inside of a function, e.g. 

```python
def foo(some_var):
    results = []
    for some_el in some_var:
        results.append(some_el)
    return results
```

Numba supports numpy arrays, but it seems this is not the case for multidimensional arrays.

```python
# this does not work
@njit(int64[:,:](int64))
def bar(number):
    results = np.array([], dtype=np.int64).reshape(-1, 2)
    for i in range(number):
        results = np.concatenate(results, np.array([[number, number + 1]]))
    return results

# this works
@njit(int64[:,:](int64, int64[:,:]))
def baz(number, results):
    # results = np.array([], dtype=np.int64).reshape(-1, 2)
    for i in range(number):
        results = np.concatenate(results, np.array([[number, number + 1]]))
    return results
```

this forces a weird wrapper requirement like:

```python
@jit(forceobj=True)
def fuzz(number):
    # make this here because numba no like
    results = np.array([], dtype=np.int64).reshape(-1, 2)
    return baz(number, results)
```

because although numpy arrays are allowed as default arguments, `numba` does not like not recieving the optinal argument


```python
@njit(int64[:,:](int64, int64[:,:]))
def buzz(number, results=np.array([], dtype=np.int64).reshape(-1, 2)):
    for i in range(number):
        results = np.concatenate(results, np.array([[number, number + 1]]))
    return results

buzz(10) #<--- throws error
```

please fix
user: SumNeuron
labels: discussion: An issue requiring discussion
issue_4245: state: open
title: optional argument support for supported numpy functions, at the very least `axis`
body: 
## Feature request
As stated in the [docs](https://numba.pydata.org/numba-doc/dev/reference/numpysupported.html#calculation) all optional arguments are not supported for many fundamental arguments.

Further several issues:

- https://github.com/numba/numba/issues/2745
- https://github.com/numba/numba/issues/1269

already call for at the very least `axis` across a number of `numpy` functions. 

I wouldn't mind it in `np.all`, `np.any`, etc

In addition to this, I **highly** encourage a new docs page or search bar specific for searching the either implemented or not implemented features in a `numpy`-esque doc style

e.g. 

searching `all` would show me the function signature for `np.all()` and note that although optional arguments exists they are currently not supported. `numba` specific work-arounds should be provide to direct users how to best recreate this lost functionality in a performant manner.

I should also be able to search directly for things like `np.append` and see that it is not yet implemented / supported by `numba` and to use the related `concatenate`


user: SumNeuron
issue_4244: state: open
title: Type inference error for dict when using default value
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Numba fails to infer return type of `Dict.get` or `Dict.setdefault` if that value (or value generated downstream) is set to the `Dict`.

```python
import numba

@numba.njit
def foo(x):
    d = dict()
    for i in x:
        val = d.get(i, default=0)
        d[i] = val + 1
    return d

foo([1, 2, 3]) # Throws TypingError
```

<details>
<summary> traceback </summary>

```python
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-114-3a9000771a91> in <module>
----> 1 foo([1, 2, 3])

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    349                 e.patch_message(msg)
    350 
--> 351             error_rewrite(e, 'typing')
    352         except errors.UnsupportedError as e:
    353             # Something unsupported is present in the user code, add help info

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    316                 raise e
    317             else:
--> 318                 reraise(type(e), e, None)
    319 
    320         argtypes = []

/usr/local/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
cannot safely cast int64 to undefined
[1] During: resolving callee type: BoundFunction((<class 'numba.types.containers.DictType'>, 'get') for DictType[undefined,undefined])
[2] During: typing of call at <ipython-input-113-dda3043518e0> (5)


File "<ipython-input-113-dda3043518e0>", line 5:
def foo(x):
    <source elided>
    for i in x:
        val = d.get(i, 0)
```

</details>


However, numba seems to be able to infer the type just fine as long as the value isn't assigned back into the dict:

```python
@numba.njit
def bar(x):
    d = dict()
    for i in x:
        val = d.get(i, default=0)
        print(type(val))
        d[i] = 1
    return d

_ = bar([1,2,3])
# int64
# int64
# int64
```

Assigning the value to another dict also fails inference, but other operations I've tried (like appending to a list) seem to work fine. Additionally, if I assign a value before trying `.get` or `.setdefault`, inference works.
user: ivirshup
labels: bug - typing: Bugs: occuring at typing time
issue_4243: state: open
title: `np.float*()` call with array like argument incorrectly types
body: ```
import numba
from numba import jit
import numpy as np

@jit(nopython=True)
def rgb2hsv(arr):
    #assert src != None and src.ndim == 3 and src.shape[-1] == 3
    arr = np.float32(src) / 255.0

    out = np.empty_like(arr)

    # -- V Channel
    out_v = arr.max(-1)

    # -- S Channel
    delta = arr.ptp(-1) + 1.0e-9

    # Ignore div by zero
    # old_settings = np.seterr(invalid='ignore')

    out_s = delta / out_v
    out_s[delta == 0.] = 0.

    # -- H Channel

    # R is max
    idx = (arr[:,:,0] == out_v)
    out[idx,0] = (arr[idx,1] - arr[idx,2]) / delta[idx]

    # G is max
    idx = (arr[:,:,1] == out_v)
    out[idx,0] = 2. + (arr[idx,2] - arr[idx,0]) / delta[idx]

    # B is max
    idx = (arr[:,:,2] == out_v)
    out[idx,0] = 4. + (arr[idx,0] - arr[idx,1]) / delta[idx]

    out_h = (out[:,:,0] / 6.0) % 1.
    out_h[delta == 0.] = 0.

    #np.seterr(**old_settings)

    out[:,:,0] = out_h
    out[:,:,1] = out_s
    out[:,:,2] = out_v

    out = np.clip(out,0,255).astype(np.uint8)
    return out

import imageio
src = imageio.imread('resources/images/f1.jpg')
hsv = color.rgb2hsv(src)
```

while i try to use numba to acceralte the function,got  errors bellow:

```
PS D:\Develop\machine-vision-workbench> python -u "d:\Develop\machine-vision-workbench\projects\image-processing\numba-imtools\1-color_rgb2hsv.py"
Traceback (most recent call last):
  File "d:\Develop\machine-vision-workbench\projects\image-processing\numba-imtools\1-color_rgb2hsv.py", line 8, in <module>
    dst = color.rgb2hsv(src)
  File "C:\Users\jenson\Anaconda3\lib\site-packages\numba\dispatcher.py", line 351, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\jenson\Anaconda3\lib\site-packages\numba\dispatcher.py", line 318, in error_rewrite
    reraise(type(e), e, None)
  File "C:\Users\jenson\Anaconda3\lib\site-packages\numba\six.py", line 658, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
?[1m?[1mUnknown attribute 'max' of type float64
?[1m
File "projects\image-processing\numba-imtools\utils\color.py", line 13:?[0m
?[1mdef rgb2hsv(src):
    <source elided>
    # -- V Channel
?[1m    out_v = arr.max(-1)
?[0m    ?[1m^?[0m?[0m
?[0m
?[0m?[1m[1] During: typing of get attribute at d:\Develop\machine-vision-workbench\projects\image-processing\numba-imtools\utils\color.py (13)?[0m
?[1m
File "projects\image-processing\numba-imtools\utils\color.py", line 13:?[0m
?[1mdef rgb2hsv(src):
    <source elided>
    # -- V Channel
?[1m    out_v = arr.max(-1)
?[0m    ?[1m^?[0m?[0m

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/dev/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/dev/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```
user: juxiangwu
issue_4242: state: open
title: Allow parsing dates of the form "1899-12-30" in a jit context
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Hello,

First, thanks for your hard work and this great library.
Recently I came across small issue that is stopping me from using `numba` in my project. We need to parse dates that are adjusted as floats from Dec 30, 1899 (this format is used in Excel).
Below is details of my environment and content of Jupyter cells:

Thanks again and best regards

Numba 0.44.1
Running through Jupyter


```python
import numba
import numpy as np
```

```python
print(np.datetime64("1899-12-30"))
```

```
1899-12-30
```

```python
@numba.jit
def test():
    t = np.datetime64("1899-12-30")
    return 0
```

```python
test()
```

```
<ipython-input-50-f403da816d8c>:1: NumbaWarning: 
Compilation is falling back to object mode WITH looplifting enabled because Function test failed at nopython mode lowering due to: Cannot cast Literal[str](1899-12-30) to datetime64[]: %".16" = load i8*, i8** %"$const0.3"

File "<ipython-input-50-f403da816d8c>", line 3:
def test():
    t = np.datetime64("1899-12-30")
    ^

[1] During: lowering "$0.4 = call $0.2($const0.3, func=$0.2, args=[Var($const0.3, <ipython-input-50-f403da816d8c> (3))], kws=(), vararg=None)" at <ipython-input-50-f403da816d8c> (3)
  @numba.jit
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/compiler.py:725: NumbaWarning: Function "test" was compiled in object mode without forceobj=True.

File "<ipython-input-50-f403da816d8c>", line 2:
@numba.jit
def test():
^

  self.func_ir.loc))
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/compiler.py:734: NumbaDeprecationWarning: 
Fall-back from the nopython compilation path to the object mode compilation path has been detected, this is deprecated behaviour.

For more information visit http://numba.pydata.org/numba-doc/latest/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit

File "<ipython-input-50-f403da816d8c>", line 2:
@numba.jit
def test():
^

  warnings.warn(errors.NumbaDeprecationWarning(msg, self.func_ir.loc))
```
user: bmironov
issue_4231: state: open
title: prange equivalent for iterable, zipped, etc
body: # Feature request
a `prange` equivalent for zip-ped / iterables would be nice rather than:

```python
zipped = zip(my, things, together, forever)
_n = len(list(zipped)) # <--- yuck, have to list-ify my zip to get _n if zip is using uneven length lists
for i in prange(_n):
# for i in prnage(len(shortest_iterable_from_zip)): would work if expected that all lists are same length
    cur = zipped[i]
```
user: SumNeuron
issue_4225: state: open
title: Conditional numpy array slicing
body: ## Feature request

Hey! I come from issue #1246. The kind of code that I do (math/signal processing stuff) would be very easy to port to numba if numpy's conditional array slicing was supported. This is a minimal example of it and the error message I currently (numba 0.44.1) get: 

```
from numba import njit
import numpy as np

@njit
def test_jit_numpy_slicing():
    diag = np.array([[1,0],[0,1]])
    zeros = np.zeros((2,2))
    return zeros[diag>0]
```

The output is: 

```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-34-d37f51e18613> in <module>()
----> 1 test_jit_numpy_slicing()

~/.local/lib/python3.5/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    349                 e.patch_message(msg)
    350 
--> 351             error_rewrite(e, 'typing')
    352         except errors.UnsupportedError as e:
    353             # Something unsupported is present in the user code, add help info

~/.local/lib/python3.5/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    316                 raise e
    317             else:
--> 318                 reraise(type(e), e, None)
    319 
    320         argtypes = []

~/.local/lib/python3.5/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<built-in function getitem>) with argument(s) of type(s): (array(float64, 2d, C), array(bool, 2d, C))
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
In definition 2:
    All templates rejected with literals.
In definition 3:
    All templates rejected without literals.
In definition 4:
    All templates rejected with literals.
In definition 5:
    All templates rejected without literals.
In definition 6:
    All templates rejected with literals.
In definition 7:
    All templates rejected without literals.
In definition 8:
    TypeError: unsupported array index type array(bool, 2d, C) in [array(bool, 2d, C)]
    raised from /home/amarafioti/.local/lib/python3.5/site-packages/numba/typing/arraydecl.py:71
In definition 9:
    TypeError: unsupported array index type array(bool, 2d, C) in [array(bool, 2d, C)]
    raised from /home/amarafioti/.local/lib/python3.5/site-packages/numba/typing/arraydecl.py:71
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: typing of intrinsic-call at <ipython-input-33-7dc37423919a> (5)

File "<ipython-input-33-7dc37423919a>", line 5:
def test_jit_numpy_slicing():
    <source elided>
    zeros = np.zeros((3,3))
    return zeros[diag>0]
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/dev/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/dev/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new
```

Thank you for numba, I got it to work with my project today after a few workarounds (https://github.com/tifgan/stftGAN/blob/master/data/pghi%20test.ipynb) 
user: andimarafioti
issue_4221: state: open
title: Make lowering reveal which overload is picked
body: ## Feature request

During lowering, numba should log what overload definitions are picked to help debugging.
user: sklam
issue_4218: state: open
title: Feature Request: parallel mode for map
body: ## Feature request
parallel mode seems to only really kick in with the use of `prange`.
It would be nice if something like this would work:


```python
@jit 
def e_fn(...):
    pass

@jit(parallel=True)
def arr_fn(arr):
    return list(map(e_fn, arr))
```

user: SumNeuron
issue_4214: state: open
title: Array analysis support for user defined arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Array analysis features (such as providing sizes for arrays) are useful for user defined arrays (e.g. string array) as well. Looks like it might work by inhering `types.ArrayCompatible` and adding handling methods to array analysis class dynamically, but needs more investigation.
user: ehsantn
issue_4212: state: open
title: Parfors corrupted typemap for type_annotation
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

See https://github.com/numba/numba/pull/4155#discussion_r294469705

user: sklam
issue_4202: state: open
title: `nopython` mode doesn't support numpy ops with scalar input
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Numba does't support scalar input for numpy methods. Foe example, the following snippet would produce error

```
import numpy as np
from numba import jit

@jit(nopython=True)
def atleast_1d(x):
    return np.atleast_1d(x)

# Error
atleast_1d(12)

# numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
# Invalid use of Function(<function atleast_1d at 0x7fb1dcbf4378>) with argument(s) of type(s): (int64)
#  * parameterized
# In definition 0:
#     All templates rejected with literals.
# In definition 1:
#     All templates rejected without literals.


# Works fine
np.atleast_1d(12)

# array([12])
```

Similar problems exists in other numpy methods like `np.digitize` or `np.searchsorted`.
user: chenzhekl
issue_4198: state: open
title: Auto-registration of custom IR nodes in all extension APIs.
body: If a new IR node is created, the programmer is responsible for registering that new node where it is necessary with the various extension APIs.  There are the following:
1) ir_extension_usedefs
2) visit_vars_extension
3) add_offset_to_labels_extension
4) find_max_label_extension
5) remove_dead_extensions
6) is_pure_extensions
7) alias_analysis_extensions
8) alias_func_extensions
9) copy_propagate_extensions
10) apply_copy_propagate_extensions
11) call_table_extensions
12) tuple_table_extensions
13) array_accesses_extensions
14) build_defs_extensions
15) ir_extension_insert_dels

So, it is pretty easy to miss some and have bugs later.  One potential solution is to have a custom IR node base class that you have to derive from and whose constructor registers functions with a known name in the derived class for each of these extensions.  If they are a no-op that is fine but at least the function would have to be present and you'd have to think about it.  We could probably then get rid of all these separate extension arrays and just have one that registers custom IR nodes and all the other code just iterates through custom IR node registrations, calling the appropriate function for the given current operation.
user: DrTodd13
issue_4191: state: open
title: Make fallback customizable
body: Regarding #4159 and also note comment at #3907

What we want:
- default behavior of not falling back; nopython=True is default.

Proposals:
- customizable “fallback” callable.
- allow option to fallback to interpreter mode if pyobject types are used or typing fails.


user: sklam
issue_4190: state: open
title: not helping the np.sign/np.abs/np.power
body: ```python
from numba import njit
import numpy as np

def signedpower(x,a):

	'''
	x:the vector 
	a: the power 
	'''
	signedV = np.sign(x)	#signe vector: 1 -1 1 -1 ...
	absV = np.abs(x)
	powerV = np.power(absV,a)
	return signedV * powerV

signedpower_ = njit(signedpower)

v1 = np.arange(-500,500)
```
```pycon
%timeit signedpower(v1,10)   
8.53 µs ± 28.7 ns per loop
%timeit signedpower_(v1,10)
75.6 µs ± 1.14 µs per loop
```

njit actually slowing down the function 

user: isaac-you
labels: performance: performance related issue
issue_4186: state: open
title: Linear algebra in a @cuda.jit decorated function
body: Hello:
I was wondering if there is a linear algebra package that could work inside a @cuda.jit decorated function.  If there is no package, is there a way to use the numpy linear algebra functions inside @cuda.jit decorated functions   
Thanks 
 
user: mahmoudasmar
labels: CUDA: CUDA related issue/PR
issue_4182: state: open
title: cuda graph api proposal
body: Hello! This PR implements simple cuda graph API for numba (in response to #3327), as is shown in the following snippet:

```python
import numpy as np
from numba import cuda
from numba.cuda.graph import KernelNode

arr = cuda.to_device(np.array([1.]))

@cuda.jit
def k1(a):
    a[0] += 2
    print('k1', a[0])

@cuda.jit
def k2(a):
    a[0] *= 3
    print('k2', a[0])

# define new kernel nodes
n1 = KernelNode(k1, [arr])
n2 = KernelNode(k2, [arr], [n1])

# before the node is builded, the arguments and dependencies can be altered
n3 = KernelNode(k2)
n3.args.append(arr)
n3.deps.append(n2)

# build the graph
g = n3.build()

# short for g.instantiate().launch()
g.launch()

cuda.synchronize()

```

And another example for `KernelNode`, `MemcpyHtoDNode`, `MemcpyDtoHNode`, `HostNode`:
```python
import numpy as np
from numba import cuda
from numba.cuda.graph import KernelNode, MemcpyHtoDNode, MemcpyDtoHNode, HostNode

host_arr = np.array([1.])
dev_arr = cuda.device_array_like(host_arr)


def k1(a):
    cuda.atomic.add(a, 0, 2)
    print('this runs on device and a[0] =', a[0], ', grid =', cuda.grid(1))


def h1(a):
    print('this runs on host and a[0] =', a[0])


n0 = MemcpyHtoDNode(dev_arr, host_arr, host_arr.nbytes)
n1 = KernelNode[4, 1](k1, [dev_arr], [n0])
n2 = MemcpyDtoHNode(host_arr, dev_arr, host_arr.nbytes, [n1])
n3 = HostNode(h1, [host_arr], [n2])

n3.build().launch()
cuda.synchronize()
```

I tried to make the API simple and flexible by making the following decisions:
* Nodes are not binded to specific graph so you can alter it and build it later
* Host arrays are not supported as it's hard to decide when to copy data back

And the following features are in plan:
* [x] `graph.destroy()` and ~~`graph.clone()`~~
  * [x] `graph.destroy()`
  * ~~[ ] `graph.clone()` (Do we really need this?)~~
* [x] `MemcpyNode`, `MemsetNode`, `HostNode` and `EmptyNode`
  * [x] `MemcpyNode`
  * [x] `MemsetNode`
  * [x] `EmptyNode`
  * [x] `HostNode` (CFUNCTYPE is used)

As you see the API is far from complete so please feel free to add comments :)

PS: For tests run the following command in terminal:
```bash
python -m numba.runtests numba.cuda.tests.graph.test_graph
```
<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
mailing list https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: oxyflour
labels: Pending BuildFarm: For PRs that have been reviewed but pending a push through our buildfarm
CUDA: CUDA related issue/PR
R&D: Research and Development
issue_4179: state: open
title: Provide additional information through numba.cuda.grid API
body: In [this notebook](https://gist.github.com/mrocklin/9272bf84a8faffdbbe2cd44b4bc4ce3c) I play with `numba.cuda.jit` on stencil computations.  Here is my example toy code:

```python
from numba import cuda

@cuda.jit
def smooth_gpu(x, out):
    i, j = cuda.grid(2)
    n, m = x.shape
    if 1 <= i < n - 1 and 1 <= j < m - 1:
        out[i, j] = (x[i - 1, j - 1] + x[i - 1, j] + x[i - 1, j + 1] +
                     x[i    , j - 1] + x[i    , j] + x[i    , j + 1] +
                     x[i + 1, j - 1] + x[i + 1, j] + x[i + 1, j + 1]) // 9
```
```python
import cupy, math

x_gpu = cupy.ones((10000, 10000), dtype='int8')
out_gpu = cupy.zeros((10000, 10000), dtype='int8')

# I copied the four lines below from the Numba docs
threadsperblock = (16, 16)
blockspergrid_x = math.ceil(x_gpu.shape[0] / threadsperblock[0])
blockspergrid_y = math.ceil(x_gpu.shape[1] / threadsperblock[1])
blockspergrid = (blockspergrid_x, blockspergrid_y)

smooth_gpu[blockspergrid, threadsperblock](x_gpu, out_gpu)
```

This is great, but some of this feels a little bit difficult for novice users to understand (at least this novice user).

In particular, I found it difficult to correctly keep the computation in bounds of the array with this conditional

```python
if 1 <= i < n - 1 and 1 <= j < m - 1:
```

And then I also found selecting the blocks per grid and threads per block to require a greater understanding of GPUs than I had.

```python
threadsperblock = (16, 16)
blockspergrid_x = math.ceil(x_gpu.shape[0] / threadsperblock[0])
blockspergrid_y = math.ceil(x_gpu.shape[1] / threadsperblock[1])
blockspergrid = (blockspergrid_x, blockspergrid_y)
```

I really liked the `numba.cuda.grid` operator though.  That was very helpful.  Taking this further, I would aspirationally like to write something like the following:

```python
@cuda.jit
def smooth_gpu(x, out):
    n, m = x.shape
    i, j = cuda.grid[1:n - 1, 1:m - 1]  # <-- define grid here?

    out[i, j] = (x[i - 1, j - 1] + x[i - 1, j] + x[i - 1, j + 1] +
                 x[i    , j - 1] + x[i    , j] + x[i    , j + 1] +
                 x[i + 1, j - 1] + x[i + 1, j] + x[i + 1, j + 1]) // 9


smooth_gpu(x_gpu, out_gpu)
```

Perhaps by slicing into the grid we can specify our bounds (numba would just return immediately if the value is outside of those bounds) and also provide some information that, along with hardware information, might inform default values for threads-per-block and blocks-per-grid.

cc'ing @pentschev and @gmarkall with whom I had a nice conversation about this just now.
user: mrocklin
labels: CUDA: CUDA related issue/PR
issue_4160: state: open
title: Feature request: Support axis kwarg in `np.repeat`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of Function(<function repeat at 0x7fe136d37b70>) with argument(s) of type(s): (array(int64, 2d, C), Literal[int](11), Literal[int](0))
 * parameterized
In definition 0:
    TypeError: np_repeat() takes 2 positional arguments but 3 were given
    raised from /mnt/lustre/wangshiqing/venv_3.5_raisr/lib/python3.5/site-packages/numba/typing/templates.py:475
In definition 1:
    TypeError: np_repeat() takes 2 positional arguments but 3 were given
    raised from /mnt/lustre/wangshiqing/venv_3.5_raisr/lib/python3.5/site-packages/numba/typing/templates.py:475
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<function repeat at 0x7fe136d37b70>)
[2] During: typing of call at Test.py (257)

-->

user: wsqat
issue_4159: state: open
title: Object mode or no-jit at all for unknown objects
body: Hi, 

I'm following up on #3907, regarding the deprecation of object mode. I almost never use object mode, but I could imagine a case like this:

```python
import pandas as pd
import numba as nb

@nb.jit
def double(x):
    return x*2

double(0.5)

double(np.ones(3))

double(pd.DataFrame(np.ones(3)))
```

That example behaves as expected, all three lines produce a result. However, I think that it works by falling back on object mode. If object-mode fallback is removed, what would happen to a case like that?
I understand that there's an opportunity to simplify the pipeline by removing the fallback, but would it be possible to leave some kind of multiple-dispatch on unknown types that runs object-mode or simply interpreted code?
Unlike the current case, I don't think it needs to look line-by-line inside the function to know whether to fall back. For example, whereas today the following works via object-mode fallback

```
def something_non_jitable(x):
    return x

@nb.jit
def foo(x):
    return something_non_jitable(x)

foo(0.5)
```
in the future it would not, because it's not a problem of input parameters but of code failing. So in the future `foo(0.5)` would fail as it fails today with `njit` but `double(pd.DataFrame(np.ones(3)))` would not fail (as it does with njit) but would fallback to object code or interpreted code.

Something to consider. Thanks for your work on Numba.
user: luk-f-a
issue_4119: state: open
title: not helping for np.convolve
body: I want to find the most efficient way to calculate the moving average. Three approach presented: 

``` 
def sma1(x,d):
	
	n = np.ones(d)
	weights = n/d  
	ret = np.convolve(weights,x)[d-1:-d+1]
	return ret 
 ```

13.2 µs ± 501 ns per loop 
6.61 µs ± 358 ns per loop for '%timeit np.mean(x)'
the np.convolve is really fast  close to no moving  np.mean

```
@jit(nopython=True)
 def sma1_jit(x,d):
	
      n = np.ones(d)
      weights = n/d  
      ret = np.convolve(weights,x)[d-1:-d+1]
      return ret
```

23.8 µs ± 811 ns per loop  jit is not helping in the case


```
def sma2(x,d):
	
	res = map(lambda t: np.mean(x[t:t+d]),range(len(x)-d+1))
	return list(res)
```
6.21 ms ± 505 µs per loop
and jit cannot work for map or lambda 

So why jit cannot speed up the np.convolve  and actually slow down ?
Thank you 
user: isaac-you
labels: performance - run time: Performance issue occurring at run time.
issue_4115: state: open
title: CFFI void* in nopython mode, determine Numba type of `_cffi_backend.CData` 
body: ## Feature request

tl;dr: support for `void*` as a nopython mode argument.

Numba can make use of CFFI in nopython mode to call simple C functions with little overhead. More complex functions might rely on state, in particular, passing structured data as a `void*`. Currently I could not find a straightforward way of doing that with Numba.

A practical example might be dealing with a C wrapper of a C++ code such as Cairo, where `void*` are used to pass around the underlying class. I have created a minimal standalone example below, consisting of a C++ library from `mylib.cc` and a python code `test.py`.

## Minimal example

mylib.cc:
~~~C++
//compile with  g++ -fPIC -shared -o mylib.dylib mylib.cc
class MyClass {
public:
  
  MyClass(const char* filename) {
    //init class, e.g. load files
  }
  
  double func(int a) {
    //an expensive C++ function
    return 0.0;
  }
  
};

extern "C" {
  void* new_class(const char* filename) {
    return new MyClass(filename);
  }

  double class_func(void* cls, int a) {
    return ((MyClass*)cls)->func(a);
  }
}

~~~

test.py:
~~~python
import numba
from cffi import FFI

ffi = FFI()
ffi.cdef("""
void* new_class(const char* filename);
double class_func(void* cls, int a);
""")
mylib = ffi.dlopen("mylib.dylib")

class_func = mylib.class_func

c = mylib.new_class("asd")

@numba.njit
def call_myfunc(a):
    x = class_func(c, a)

#throws exception as the type of c ('_cffi_backend.CData') is not known to Numba
call_myfunc(1)
~~~

This currently fails with
~~~
cannot determine Numba type of <class '_cffi_backend.CData'>
~~~
as the type of `c` cannot be propagated in the nopython mode. With `nopython=False`, this works, but it would be great not to have to pay the additional overhead :)

## Who would benefit from it? 
  - In my case, I'm trying to wrap some existing scientific C++ code that relies on classes that can be easily encapsulated in a few C functions and passing around a blind pointer to the class.
  - In gitter, @tillsten mentioned that he had the same issue when wrapping Cairo.
  - I have found a work-around for this [here](https://github.com/willsheffler/worms/blob/1d31a23890b059baccf062ace98c7ec63cd61554/worms/khash/khash_cffi.py#L43), where it seems `register_type` did not give the expected result, but `register_module` worked. I was not successful in using this approach for my purpose.

cc @stuartarchibald, who proposed a solution based on adding additional intrinsics: [May 23, 2019 1:08 PM](https://gitter.im/numba/numba?at=5ce6fdcf83ae782aeebbf941)
user: jpata
issue_4108: state: open
title: incorrect handling of array.shape with nopython=True
body: Each of the following variations on the same code results in numba raising a 'Tuple index out of range' error regarding (it seems) `array.shape[1]`.

The checks on `len(array.shape)` and `array.ndim` are completely ignored.

Code to reproduce:

```python
from numba import jit
import numpy as np
import traceback


@jit(nopython=True)
def test_1(array: np.ndarray):
    if array.ndim == 2:
        if array.shape[1] == 2:
            return 1
    return 0


@jit(nopython=True)
def test_2(array: np.ndarray):
    if array.ndim == 2 and array.shape[1] == 2:
        return 1
    return 0


@jit(nopython=True)
def test_3(array: np.ndarray):
    if len(array.shape) == 2:
        if array.shape[1] == 2:
            return 1
    return 0


@jit(nopython=True)
def test_4(array: np.ndarray):
    if len(array.shape) == 2 and array.shape[1] == 2:
        return 1
    return 0


array = np.empty((1,))

for test in (test_1, test_2, test_3, test_4):
    try:
        test(array)

    except:
        traceback.print_exc()
```

Tracebacks:
```
Traceback (most recent call last):
  File "C:/Users/admin/Documents/Projects/scraps/numba_bug_test.py", line 40, in <module>
    test(array)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\dispatcher.py", line 350, in _compile_for_args
    error_rewrite(e, 'typing')
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\dispatcher.py", line 317, in error_rewrite
    reraise(type(e), e, None)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\six.py", line 658, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.typeinfer.StaticGetItemConstraint object at 0x000001BF103C9EB8>:
--%<----------------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\errors.py", line 627, in new_error_context
    yield
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typeinfer.py", line 343, in __call__
    value=ty, index=self.index,
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typing\context.py", line 300, in resolve_static_getitem
    return self.resolve_function_type("static_getitem", args, kws)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typing\context.py", line 204, in resolve_function_type
    res = self._resolve_builtin_function_type(func, args, kws)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typing\context.py", line 221, in _resolve_builtin_function_type
    res = defn.apply(args, kws)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typing\templates.py", line 207, in apply
    sig = generic(args, kws)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typing\builtins.py", line 611, in generic
    ret = tup.types[idx]
IndexError: tuple index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typeinfer.py", line 144, in propagate
    constraint(typeinfer)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\typeinfer.py", line 351, in __call__
    self.fallback(typeinfer)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\errors.py", line 635, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python37\lib\site-packages\numba\six.py", line 659, in reraise
    raise value
numba.errors.InternalError: tuple index out of range
[1] During: typing of static-get-item at C:/Users/admin/Documents/Projects/scraps/numba_bug_test.py (9)
--%<----------------------------------------------------------------------------

File "numba_bug_test.py", line 9:
def test_1(array: np.ndarray):
    <source elided>
    if array.ndim == 2:
        if array.shape[1] == 2:
        ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.
```
```
File "numba_bug_test.py", line 16:
def test_2(array: np.ndarray):
    if array.ndim == 2 and array.shape[1] == 2:
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.
```
```
File "numba_bug_test.py", line 24:
def test_3(array: np.ndarray):
    <source elided>
    if len(array.shape) == 2:
        if array.shape[1] == 2:
        ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.
```
```
File "numba_bug_test.py", line 31:
def test_4(array: np.ndarray):
    if len(array.shape) == 2 and array.shape[1] == 2:
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.
```

user: 0xf0f
labels: bug - typing: Bugs: occuring at typing time
issue_4098: state: open
title: numpy.empty() TypingError with structured dtype
body: ```python
@njit
def foo():
    numpy.empty((0, 2), dtype=[('point', numpy.float32), ('count', numpy.int32)])
foo()
```
```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Type of variable '$0.12' cannot be determined, operation: build_list(items=[Var($0.7, <ipython-input-672-28d53090bc27> (3)), Var($0.11, <ipython-input-672-28d53090bc27> (3))]), location: <ipython-input-672-28d53090bc27> (3)

File "<ipython-input-672-28d53090bc27>", line 3:
def foo():
    numpy.empty((0, 2), dtype=[('point', numpy.float32), ('count', numpy.int32)])
    ^
```
user: belm0
labels: bug - typing: Bugs: occuring at typing time
issue_4093: state: open
title: Memory leak when allocating 1D and 2D numpy arrays inside jitted functions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I have been running into memory leaks which I have been able to trace to jitted functions which allocate both 1D and 2D numpy arrays. The memory leak seems to occur only if the function allocates both a 1D and a 2D array; only doing one type removes the leak, regardless of whether or not the allocated array is used in any way, or the order of the allocation.

A minimal code reproducing the leak and two non-leaking versions of the same function:

```
#!/usr/bin/env python3
import numpy as np
from numba import njit, float64

@njit(float64[:](float64[:]))
def test_leak(z):
    a = np.array([[-1, 1], [0, 0], [1, -1]], dtype=np.int64)
    b = np.array([1.0, -1.0, 1.0], dtype=np.float64)
    return z+a[:,0]

@njit(float64[:](float64[:]))
def test_noleak_v1(z):
    a = np.array([[-1, 1], [0, 0], [1, -1]], dtype=np.int64)
    return z+a[:,0]

@njit(float64[:](float64[:]))
def test_noleak_v2(z):
    a = np.array([-1, 1, 0, 0, 1, -1], dtype=np.int64).reshape(-1,2)
    b = np.array([1.0, -1.0, 1.0], dtype=np.float64)
    return z+a[:,0]

def run_test(func):
    v = np.zeros(3, dtype=np.float64)
    for i in range(100000000):
        func(v)

if __name__ == "__main__":
    run_test(test_leak) # <- gives a very fast memory leak
    #run_test(test_noleak_v1) # <- no memory leak
    #run_test(test_noleak_v2) # <- no memory leak
```

My current workaround is to use the second fix, allocating all arrays as 1D and reshaping them afterwards.

I am using the pip version of Numba 0.43.1 on Ubuntu 18.04, Python 3.6.7

Thank you for your help and developing Numba!
user: dkitch
labels: bug - memory leak: Memory leak
issue_4074: state: open
title: meta-issue: All NumPy functions with no implementation
body: Below are lists of feasible but not yet implemented NumPy functions... ideal for first time contributors. If you would like to contribute a function, please first check the open "Pull Requests" to make sure someone else isn't already working on the one you chose! If the check-box next to the function is checked it means the function is already done...

As a new contributor, some instructions for getting set up for development are [here](https://numba.readthedocs.io/en/stable/developer/contributing.html#getting-set-up) and are a great place to start.

It should be possible to write these functions using the [`numba.extending.overload`](https://numba.readthedocs.io/en/stable/extending/high-level.html) functionality, they are of varying difficulty. A guide to using `@overload` is [here](https://numba.readthedocs.io/en/stable/extending/overloading-guide.html):

* ~[ ] `np.alen`~ deprecated, see https://github.com/numpy/numpy/issues/14155
* [x] `np.allclose`
* [x] `np.alltrue`
* [x] `np.append`
* [x] `np.argpartition`
* [x] `np.argwhere`
* [x] `np.around`
* [x] `np.array_equal`
* [x] `np.array_split`
* [ ] `np.asanyarray`
* [x] `np.asarray_chkfinite`
* [x] `np.asfarray`
* ~[ ] `np.asscalar`~ deprecated, see https://github.com/numpy/numpy/pull/20414
* [x] `np.atleast_1d`
* [x] `np.atleast_2d`
* [x] `np.atleast_3d`
* [x] `np.bartlett`
* [ ] `np.binary_repr`
* [x] `np.bincount`
* [x] `np.blackman`
* [ ] `np.compress`
* [x] `np.count_nonzero`
* [x] `np.cross`
* [x] `np.cumproduct` (just needs wiring)
* [ ] `np.diag_indices`
* [ ] `np.diag_indices_from`
* [x] `np.diagflat`
* [x] `np.euler_gamma` (constant)
* [ ] ~`np.fastCopyAndTranspose`~ deprecated, see https://github.com/numpy/numpy/pull/22313
* [x] `np.floatnonzero`
* [x] `np.fliplr`
* [x] `np.flipud`
* ~[ ] `np.fv`~ deprecated see NumPy's NEP-0032.
* [x] `np.geomspace`
* [x] `np.hamming`
* [x] `np.hanning`
* [x] `np.hsplit`
* [ ] `np.i0`
* [ ] `np.in1d`
* [ ] `np.indices`
* [x] `np.infty` (constant)
* [ ] `np.inner`
* [x] `np.intersect1d`
* ~[ ] `np.ipmt`~ deprecated see NumPy's NEP-0032.
* ~[ ] `np.irr`~ deprecated see NumPy's NEP-0032.
* [x] `np.isclose`
* [x] `np.iscomplex`
* [x] `np.iscomplexobj`
* [ ] `np.isfortran`
* [ ] `np.isin`
* [x] `np.isnat`
* [x] `np.isneginf`
* [x] `np.isposinf`
* [x] `np.isreal`
* [x] `np.isrealobj`
* [x] `np.isscalar`
* [x] `np.kaiser`
* [ ] `np.little_endian`
* [x] `np.logspace`
* [ ] `np.meshgrid`
* ~[ ] `np.mirr`~ deprecated see NumPy's NEP-0032.
* ~[ ] `np.msort` (largely wiring!)~ deprecated, see https://github.com/numpy/numpy/pull/22456
* [x] `np.nan_to_num`
* [ ] `np.nanargmax`
* [ ] `np.nanargmin`
* [ ] `np.ndim` (just needs wiring)
* [ ] `np.newaxis` (just needs wiring)
* ~[ ] `np.nper`~ deprecated see NumPy's NEP-0032.
* ~[ ] `np.npv`~ deprecated see NumPy's NEP-0032.
* [ ] `np.place`
* ~[ ] `np.pmt`~ deprecated see NumPy's NEP-0032.
* [ ] `np.poly`
* [ ] `np.polyadd`
* [ ] `np.polyder`
* [ ] `np.polydiv`
* [ ] `np.polyint`
* [ ] `np.polymul`
* [ ] `np.polysub`
* [ ] `np.polyval`
* ~[ ] `np.ppmt`~ deprecated see NumPy's NEP-0032.
* [x] `np.product` (just needs wiring)
* [ ] `np.put`
* [ ] `np.putmask`
* ~[ ] `np.pv`~ deprecated see NumPy's NEP-0032.
* ~[ ] `np.rate`~ deprecated see NumPy's NEP-0032.
* [x] `np.resize`
* [x] `np.rot90`
* [x] `np.row_stack`
* [x] `np.select`
* [ ] `np.setdiff1d`
* [ ] `np.setxor1d`
* [ ] `np.size` (mostly wiring)
* [ ] <strike>`np.sometrue` (just needs wiring) </strike> ([deprecated with 1.25 ](https://numpy.org/devdocs/release/1.25.0-notes.html)
* [ ] `np.sortcomplex`
* [x] `np.split`
* [x] `np.tril_indices`
* [x] `np.tril_indices_from`
* [x] `np.triu_indices`
* [x] `np.triu_indices_from`
* [x] `np.trim_zeros`
* [x] `np.union1d`
* [ ] `np.unravel_index`
* [ ] `np.unwrap`
* [x] `np.vsplit`

It is also seemingly possible to write these functions with `numba.extending.overload` but they are harder/it is less easy to determined difficultly in implementing these:
* [ ] `np.choose`
* [ ] `np.common_type`
* [ ] `np.copyto`
* [x] `np.dsplit`
* [x] `np.dstack`
* [ ] `np.fix`
* [ ] `np.gradient`
* [ ] `np.histogram2d`
* [ ] `np.histogramdd`
* [ ] `np.insert`
* [ ] `np.ix_`
* [ ] `np.lexsort`
* [ ] `np.mask_indices`
* [ ] `np.maximum_sctype`
* [ ] `np.nested_iters`
* [ ] `np.pad`
* [ ] `np.piecewise`
* [ ] `np.polyfit`
* [ ] `np.put_along_axis`
* [ ] `np.squeeze`
* [x] `np.swapaxis`
* [ ] `np.tensordor`

These are likely to need lower level work:
* [x] `np.broadcast_to`
* [x] `np.broadcast_arrays`
* [ ] `np.byte_bounds`
* [ ] `np.packbits`
* [ ] `np.unpackbits`


user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
good second issue: A good issue for second time contributors
issue_4072: state: open
title: Add note in CUDA docs about signature in @cuda.jit causing immediate compilation
body: 

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

As title. Follow up to https://github.com/numba/numba/issues/4052

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
labels: CUDA: CUDA related issue/PR
issue_4069: state: open
title: out parameter broken for cuda ufuncs
body: The out parameter on cuda ufuncs raises an erroneous assertion error. Here's an example:

```
import numpy as np
from numba import vectorize, float64

@vectorize([float64(float64)], target="cuda")
def gpu_kernel(a):
    return 2 * a

a = np.random.rand(10, 10)
b = np.empty_like(a)
gpu_kernel(a, out=b)
```
user: insertinterestingnamehere
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_4064: state: open
title: Annotate HTML alignment broken in JupyterLab
body: While trying out Numba `Annotate` (and after fixing #4063) I noticed that the alignment is broken in JupyterLab. It is right-aligned, but should be left-aligned. (I didn't try in Jupyter notebook)

See screenshot below.

@Carreau - Do you know what's wrong?

---

Another usability issue is that executing the cell with the example multiple times makes the HTML output grow and grow, showing the same annotated output multiple times. This looks like a bug, no? When re-executing a `def` statement with `numba.jit` decorator, a new `numba.targets.registry.CPUDispatcher` object should be created, and nothing should accumulate, no?

---

<img width="851" alt="Screenshot 2019-05-07 at 10 22 12" src="https://user-images.githubusercontent.com/852409/57285126-d0bc4600-70b2-11e9-8e42-1ac8fbdde4fb.png">


user: cdeil
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_4062: state: open
title: Result caching in Numba
body: This issue serves as a backup of some ideas discussed in the Gitter room.

# Result caching in combination with Numba

## Premise

One clear application of numba is the speedup of costly computations. Besides acceleration of such computations, it could be useful to cache results of such functions, if they are pure functions and expected to be called with the same parameters frequently. The Python standard library offers e.g. the [lru_cache in the functools module](https://docs.python.org/3/library/functools.html#functools.lru_cache), which memoises the most recent calls of the functions it is wrapping.

## Challenge

At the current time, no best practice or recipe exists for how to efficiently combine numba's jit capabilities and a caching approach.

If only a single function is to be compiled by numba and have its results cached, this can be achieved efficiently by wrapping the jit or njit compiled function with the lru_cache like
```python
@lru_cache()
@njit
def add_one(x):
    return x+1
```

The problem arises when we want to call a (jitted and) cached, function from a another jitted function as in

```python
@jit
def foo(x)
    return bar(x)

@lru_cache()
@jit
def bar(x)
    return x + 1
```

There are two approaches one could possibly think of:
1. jit-compile the lru_cache decorated function: This will not work in a straight forward way. The lru_cache ability cannot be compiled by numba in nopython or python mode.
2. Add caching to the compiled function:
    1. Both jitted and n-jitted functions can savely be wrapped by pythons lru_cache
    2. Functions compiled in python mode can call lru_cached functions
    3. Functions compiled in nopython mode can only call cached functions by using the [objmode context manager](https://numba.pydata.org/numba-doc/dev/user/withobjmode.html)

Usually we would like to try and compile our functions in nopython mode for performance reasons (and the objmode comes with performance penalties similar to those of pythonmode jitting, because of the context change).
So the bottom line of this is: **What is a good way to implement results caching for a function that is intended to be called from anoter njit function**

## An example with lru_caching
The following code snippet serves as an example for combining caching and jitting and to demonstrate that the context change through objmode makes njit similarly slow to pythonmode jit

```python
from functools import lru_cache
from numba import jit, njit, objmode
import timeit

@lru_cache(1000)
@jit
def fib_jit_cache(n):
    if n == 1 or n == 2:
        return 1
    return fib_jit_cache(n-2) + fib_jit_cache(n-1)

@njit
def fib_njit(n):
    if n == 1 or n == 2:
        return 1
    return fib_njit(n-2) + fib_njit(n-1)

@lru_cache(1000)
@njit
def fib_njit_cache(n):
    if n == 1 or n == 2:
        return 1
    with objmode(f="intp"):
        f = fib_njit_cache(n-2) + fib_njit_cache(n-1)
    return f

# Trigger compilation through first time call
fib_jit_cache(1)
fib_njit(1)
fib_njit_cache(1)

# time it
print("jit_cache", timeit.timeit("fib_jit_cache(30)", setup="from __main__ import fib_jit_cache", number=1000))
print("njit", timeit.timeit("fib_njit(30)", setup="from __main__ import fib_njit", number=1000))
print("njit_cache", timeit.timeit("fib_njit_cache(30)", setup="from __main__ import fib_njit_cache", number=1000))
```

Output
```
jit_cache 0.008777704000000108
njit 0.11476176100000002
njit_cache 0.008950522999999988
```

## Strategies
@luk-f-a proposed to implement a numba cache by using the fairly new [typed.Dict](http://numba.pydata.org/numba-doc/latest/reference/pysupported.html#dict) which sounds like an interesting approach.

Potentially inspiration could be drawn from the original [lru_cache implementation](https://github.com/python/cpython/blob/master/Lib/functools.py#L444).

A reasonably robust implementation could make for an interesting numba recipe. This could become even more convenient once the typed.Dict receives type inference features, which is planned for the upcoming releases of numba.
user: HPLegion
labels: discussion: An issue requiring discussion
caching: Issue involving caching
issue_4051: state: open
title: Improve the efficiency of generating exponential random variables.
body: The implementation of numpy.random.exponential in numba seems to be a bit slow. Consider the following code

```python
@numba.njit
def f_exp(n):
    t = 0
    for i in range(n):
        if np.random.exponential() < 1:
            t += 1
    return t
```

For n = 10**7, this takes about 570 ms on my machine, where as the corresponding uniform random variable version (see below) takes only about 60 ms. That's 10x difference, which is very strange.
```python
@numba.njit
def f_unif(n):
    t = 0
    for i in range(n):
        if np.random.random() < 0.5:
            t += 1
    return t
```

A walk around is to use log of uniform random variable, which should have same distribution as exponential. But I don't know if this introduces any bias in practice.
```python
@numba.njit(fastmath=True)
def f_log_unif(n):
    t = 0
    for i in range(n):
        if -np.log(np.random.random()) < 1:
            t += 1
    return t
```
This version takes about 380 ms.

BTW, it seems that Julia's implementation of exponential random variable is much faster.
```julia
function f_exp(n)
    t = 0
    for i in 1:n
        if Random.randexp() < 1
            t += 1
        end
    end
    t
end
```
This takes only about 60 ms for n=10^7 on my machine.
user: newptcai
labels: performance: performance related issue
issue_4045: state: open
title: Calling vectorize with parallel target inside njit
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Calling a `vectorize` function with the parallel target inside an `njit` function fails:
```python
import numpy as np
import numba as nb

# @nb.vectorize([nb.float64(nb.float64, nb.float64)]) # works
@nb.vectorize([nb.float64(nb.float64, nb.float64)], target="parallel")
def g(a, b):
    return (a * b + 1)

@nb.njit
def f(A, B):
    return g(A, B)

print(f(np.ones(4), np.zeros(4)))
```
user: ehsantn
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_4037: state: open
title: Add Dataclasses support
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

[Dataclasses](https://docs.python.org/3/library/dataclasses.html) I find are particularly useful containers for primatives such as model parameters. I have been writing up code in a photometric model and it is convienent to drop various configurable coefficients into a dataclass. This is so that I do not explode the number of parameters each function can take, and so that I don't have a bunch of constants defined outside the function body for speed. It would be nice if numba could handle dataclasses transparently, or at least handle typical python types and a subset of numpy arrays and such. Most relevant issue looks to be #2334.

user: AndrewAnnex
issue_4035: state: open
title: Fancy Indexing for `DeviceNDArray`
body: On the [gitter chat today](https://gitter.im/numba/numba?at=5cc7359b3b6cb0686a74463d) we briefly discussed whether or not to add fancy indexing to Numba-backed CUDA arrays (DeviceNDArray).  I am interested in this topic as it relates to recent work around cuml and sklearn's gridsearch.  This relevant for context as running `DeviceNDArray` through sklearn machinery means handling code like: `X[indices]`

This issue should serve as a continuation of the discussion on gitter to specifically address the following use case:

```python
import numpy as np
import numba.cuda

data = np.arange(10)
carr = numba.cuda.to_device(data)

carr[data[:5]]
# carr[carr[:5]] # this too ?

# and multidimensional cases

data = np.ones((2,2))
carr = numba.cuda.to_device(data)
carr[np.array([0,1])]
```

cc @cjnolet @seibert @kkraus14
user: quasiben
labels: CUDA: CUDA related issue/PR
issue_4029: state: open
title: Issue with using `overload` on a vectorized function
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

If I try to overload a function decorated with `numba.vectorize`:

```python
In [40]: @numba.vectorize
    ...: def f(x):
    ...:     pass
    ...:

In [41]: @numba.extending.overload(f)
    ...: def f_overload(x):
    ...:     if x == numba.types.float64:
    ...:         return lambda x: x
    ...:

In [42]: @numba.njit
    ...: def g(x):
    ...:     return f(x)
    ...:

In [43]: g(1.0)
```

then I get this traceback:

<details>
 <summary>Traceback</summary>

```python
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
~/Projects/spycial-dev/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    626     try:
--> 627         yield
    628     except NumbaError as e:

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    257                                    loc=self.loc, errcls_=defaulterrcls):
--> 258                 self.lower_inst(inst)
    259

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_inst(self, inst)
    300             ty = self.typeof(inst.target.name)
--> 301             val = self.lower_assign(ty, inst)
    302             self.storevar(val, inst.target.name)

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    453         elif isinstance(value, ir.Expr):
--> 454             return self.lower_expr(ty, value)
    455

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_expr(self, resty, expr)
    912         elif expr.op == 'call':
--> 913             res = self.lower_call(resty, expr)
    914             return res

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_call(self, resty, expr)
    705         else:
--> 706             res = self._lower_call_normal(fnty, expr, signature)
    707

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in _lower_call_normal(self, fnty, expr, signature)
    884
--> 885         res = impl(self.builder, argvals, self.loc)
    886         return res

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/targets/base.py in __call__(self, builder, args, loc)
   1131     def __call__(self, builder, args, loc=None):
-> 1132         res = self._imp(self._context, builder, self._sig, args, loc=loc)
   1133         self._context.add_linking_libs(getattr(self, 'libs', ()))

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/targets/base.py in wrapper(*args, **kwargs)
   1156             kwargs.pop('loc')     # drop unused loc
-> 1157             return fn(*args, **kwargs)
   1158

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/npyufunc/dufunc.py in __call__(self, context, builder, sig, args)
     64                                           self.kernel,
---> 65                                           explicit_output=explicit_output)
     66

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/targets/npyimpl.py in numpy_ufunc_kernel(context, builder, sig, args, kernel_class, explicit_output)
    320                 context, builder,
--> 321                 lc.Constant.null(context.get_value_type(ret_ty)), ret_ty)
    322         arguments.append(output)

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/targets/npyimpl.py in _prepare_argument(ctxt, bld, inp, tyinp, where)
    172     else:
--> 173         raise NotImplementedError('unsupported type for {0}: {1}'.format(where, str(tyinp)))
    174

NotImplementedError: unsupported type for input operand: none

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-43-b4ad4e189a16> in <module>
----> 1 g(1.0)

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    367                     e.patch_message(''.join(e.args) + help_msg)
    368             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 369             raise e
    370
    371     def inspect_llvm(self, signature=None):

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    324                 argtypes.append(self.typeof_pyval(a))
    325         try:
--> 326             return self.compile(tuple(argtypes))
    327         except errors.TypingError as e:
    328             # Intercept typing error that may be due to an argument

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, sig)
    656
    657             self._cache_misses[sig] += 1
--> 658             cres = self._compiler.compile(args, return_type)
    659             self.add_overload(cres)
    660             self._cache.save_overload(sig, cres)

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     80                                       args=args, return_type=return_type,
     81                                       flags=flags, locals=self.locals,
---> 82                                       pipeline_class=self.pipeline_class)
     83         # Check typing error if object mode is used
     84         if cres.typing_error is not None and not flags.enable_pyobject:

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    939     pipeline = pipeline_class(typingctx, targetctx, library,
    940                               args, return_type, flags, locals)
--> 941     return pipeline.compile_extra(func)
    942
    943

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    370         self.lifted = ()
    371         self.lifted_from = None
--> 372         return self._compile_bytecode()
    373
    374     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    870         """
    871         assert self.func_ir is None
--> 872         return self._compile_core()
    873
    874     def _compile_ir(self):

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    857         self.define_pipelines(pm)
    858         pm.finalize()
--> 859         res = pm.run(self.status)
    860         if res is not None:
    861             # Early pipeline completion

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    251                     # No more fallback pipelines?
    252                     if is_final_pipeline:
--> 253                         raise patched_exception
    254                     # Go to next fallback pipeline
    255                     else:

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    242                 try:
    243                     event(stage_name)
--> 244                     stage()
    245                 except _EarlyPipelineCompletion as e:
    246                     return e.result

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in stage_nopython_backend(self)
    729         """
    730         lowerfn = self.backend_nopython_mode
--> 731         self._backend(lowerfn, objectmode=False)
    732
    733     def stage_compile_interp_mode(self):

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    679             self.library.enable_object_caching()
    680
--> 681         lowered = lowerfn()
    682         signature = typing.signature(self.return_type, *self.args)
    683         self.cr = compile_result(

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in backend_nopython_mode(self)
    666                 self.calltypes,
    667                 self.flags,
--> 668                 self.metadata)
    669
    670     def _backend(self, lowerfn, objectmode):

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags, metadata)
   1061         lower = lowering.Lower(targetctx, library, fndesc, interp,
   1062                                metadata=metadata)
-> 1063         lower.lower()
   1064         if not flags.no_cpython_wrapper:
   1065             lower.create_cpython_wrapper(flags.release_gil)

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower(self)
    175         if self.generator_info is None:
    176             self.genlower = None
--> 177             self.lower_normal_function(self.fndesc)
    178         else:
    179             self.genlower = self.GeneratorLower(self)

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    216         # Init argument values
    217         self.extract_function_arguments()
--> 218         entry_block_tail = self.lower_function_body()
    219
    220         # Close tail of entry block

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_function_body(self)
    241             bb = self.blkmap[offset]
    242             self.builder.position_at_end(bb)
--> 243             self.lower_block(block)
    244
    245         self.post_lower()

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    256             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    257                                    loc=self.loc, errcls_=defaulterrcls):
--> 258                 self.lower_inst(inst)
    259
    260     def create_cpython_wrapper(self, release_gil=False):

/usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/contextlib.py in __exit__(self, type, value, traceback)
    128                 value = type()
    129             try:
--> 130                 self.gen.throw(type, value, traceback)
    131             except StopIteration as exc:
    132                 # Suppress StopIteration *unless* it's the same exception that

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    633         from numba import config
    634         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 635         six.reraise(type(newerr), newerr, tb)
    636
    637

~/Projects/spycial-dev/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660
    661 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
unsupported type for input operand: none

File "<ipython-input-42-b6814e4dfb5d>", line 3:
def g(x):
    return f(x)
    ^

[1] During: lowering "$0.3 = call $0.1(x, func=$0.1, args=[Var(x, <ipython-input-42-b6814e4dfb5d> (3))], kws=(), vararg=None)" at <ipython-input-42-b6814e4dfb5d> (3)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```

</details>

which ends with a request to report the issue:

```
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```

If I do the same thing but without the `vectorize` decorator then the overload works as expected:

```python
In [36]: def f(x):
    ...:     pass
    ...:

In [37]: @numba.extending.overload(f)
    ...: def f_overload(x):
    ...:     if x == numba.types.float64:
    ...:         return lambda x: x
    ...:

In [38]: @numba.njit
    ...: def g(x):
    ...:     return f(x)
    ...:

In [39]: g(1.0)
Out[39]: 1.0
```
user: person142
issue_4003: state: open
title: Support time functions like `time.time()`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Supporting a wall clock time function like `time.time()` enables more accurate benchmarking since the time call can be inside the njit function, which avoids measure boxing/unboxing. This is very useful for benchmarking strings since boxing/unboxing large string containers is expensive.
user: ehsantn
issue_4002: state: open
title: Hashing of jitclass doesn't work
body: # Reporting a bug

This is my code

```python
import numba
from numba import njit, jitclass


@jitclass([("a", numba.int64), ("b", numba.int64)])
class A:
    def __init__(self, a, b):
        self.a = a
        self.b = b

    def __hash__(self):
        return self.a + self.b


print(A.class_type())

x = A(1, 2)
y = A(1, 2)

print(hash(x))
print(hash(y))
```

It appears that:
- the override of `__hash__` doesn't work
- the hash is not the same even for objects that are the same (like in Python)

Is there a way to get a value-dependent hashing?

Or is there a way to subclass namedtuples and still compile?
user: louisabraham
issue_3998: state: open
title: Runtime control of environment variables (especially for Jupyter notebooks)
body: Numba uses enviromental variables for some features.  

It would be desirable, when the structure of numba allows, to be able to control environment variable settings directly using numba methods (at run time).

Thus the feature suggestion is that for any modal feature that does not require an environmental variable to activate it, don't use an environmental variable.  Use a run-time or import-time setting.

**Rationale:** 
 Debugging in interactive modes such at Jupyter Notebooks can be useful when hard to reproduce errors are encountered since the state of the system contains the variable values that trigger the error.

Unfortunately, one would also like to switch on some environment variables to debug when the elusive or irreproducible error is in view and it's unclear how to do this. The upcoming Hinting system will make this even more desirable.

**Related issues:**
  #1804 (global turning off of JIT), and #1234 (reloading environment variables in interactive environments)

**Challenges:** 
For example when does python check the environment variables:  At launch, at numba import, at run time?     Could one turn some of them on just by a Reload modules? Are some dependent on the whole interpreter have to be restarted to respect changes.  



Thus, restrict the use of environment variables to just situations where the modal activity has to be done with an environment variables and set the rest directly from numba methods.



user: cems2
issue_3997: state: open
title: Error using nb.prange()
body: Here is a reproducible example of a problem I encountered today. The traceback suggested that I post an issue, so I came here. 

```
import numba as nb
import numpy as np
from time import time
import matplotlib.pyplot as plt


def f(d):
    a = np.int(10*d)
    N = np.int(10000/d)
    for _ in range(N):
        X = np.dot(np.random.randn(a,10), np.random.randn(10,10))
    return X


@nb.jit(parallel=True, nopython=True)
def f_numba(d):
    a = np.int(10*d)
    N = np.int(10000/d)
    for _ in nb.prange(N):
        X = np.dot(np.random.randn(a,10), np.random.randn(10,10))
    return X


# Dimensions
ds = [1,2,3,4,5,6,8,10,20,35,40,45,50,60,62,64,66,68,70,80,90,100]

# Serial processing
serial = []
for d in ds:
    t1 = time()
    for i in range(20):
        f(d)
    serial.append(time()-t1)

# Parallel processing
parallel = []
for d in ds:
    t1 = time()
    for i in range(20):
        f_numba(d)
    parallel.append(time() - t1)

# Plot
plt.title('Matrix multiplication time with 10000/d repetitions')
plt.plot(ds, serial, label='serial')
plt.plot(ds, parallel, label='parallel')
plt.xlabel('d (dimension)')
plt.ylabel('Total time (sec)')
plt.legend()
plt.show()
```

Traceback is: 
```
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Buffer dtype cannot be buffer, have dtype: array(float64, 2d, C)

File "scratch.py", line 19:
def f_numba(d):
    <source elided>
    N = np.int(10000/d)
    for _ in nb.prange(N):
    ^

[1] During: lowering "id=2[LoopNest(index_variable = parfor_index.22, range = (0, $N.24, 1))]{42: <ir.Block at C:/Users/wadear/.PyCharm2019.1/config/scratches/scratch.py (19)>}Var(parfor_index.22, C:/Users/wadear/.PyCharm2019.1/config/scratches/scratch.py (19))" at C:/Users/wadear/.PyCharm2019.1/config/scratches/scratch.py (19)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```
My current dependencies and versions are:
```
Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit (AMD64)] on win32
cftime==1.0.3.4
cycler==0.10.0
et-xmlfile==1.0.1
hydrostats==0.67
jdcal==1.4
kiwisolver==1.0.1
llvmlite==0.28.0
matplotlib==2.2.2
mpmath==1.0.0
netCDF4==1.4.2
numba==0.43.1
numpy==1.16.2
openpyxl==2.5.4
pandas==0.23.3
pyparsing==2.2.0
python-dateutil==2.7.3
pytz==2018.5
scipy==1.1.0
six==1.11.0
sympy==1.2
xarray==0.11.3
xlrd==1.1.0
```

user: pythonweb2
issue_3993: state: open
title: Use of lists for shape args in empty(), zero(), Ones()
body: Noting an inconsistency between numba and numpy  in the type of arguments allowed for empty(), zero() and ones() and probably others.

This is not a bug per se, just a case were generally expected behaviors don't match between numba and numpy.

In numpy the documentation states that the shape argument of numpy.empty is a tuple of dimensions.

**However _although not documented_, numpy will also take a list in place of a tuple.**

**Numba Will only take a tuple.  It will not take a list.**

_This is both good yet unfortunate._ 

 It's bad because it breaks a lot of existing code that, albeit sloppy, depends on a list being accepted in numpy.

I think is it probably good because Cuda types will work better if Tuples are used I believe.  

The real problem is the error output is a bit cryptic and the result unexpected by experienced numpy users.

**CODE TO REPRODUCE**
```
def testempty_List(i):
    moo = np.empty([i,i])
    return moo

def testempty_Tuple(i):
    moo = np.empty((i,i))
    return moo

# pure numpy
testempty_Tuple(3)   
testempty_List(3)                # this will not give an error
        
nb.njit(testempty_Tuple)(3)
nb.njit(testempty_List)(3)     # this will give an error
```






user: cems2
issue_3980: state: open
title: Performance hit with local temporary variables
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

---

It looks like Numba cannot optimise simple functions will if they contain local temporary variables on multiple lines, instead of a long expression on a single line.

With the latest Numba 0.43.1 on macOS from Anaconda and the `sin(x) ** 2  + cos(x) ** 2` example from http://numba.pydata.org/numba-doc/latest/user/performance-tips.html I see this:
```
In [1]: import numpy as np                                                                                                                                                                                 

In [2]: import numba                                                                                                                                                                                       

In [3]: import numexpr                                                                                                                                                                                     

In [4]: def f1(x): 
   ...:     return np.sin(x) ** 2 + np.cos(x) ** 2 
   ...:                                                                                                                                                                                                    

In [5]: def f2(x): 
   ...:     s = np.sin(x) 
   ...:     c = np.cos(x) 
   ...:     return s ** 2 + c ** 2 
   ...:                                                                                                                                                                                                    

In [6]: a = np.arange(1.e7)                                                                                                                                                                                

In [7]: f1_numba = numba.jit(f1)                                                                                                                                                                           

In [8]: f2_numba = numba.jit(f2)                                                                                                                                                                           

In [9]: %timeit f1(a)                                                                                                                                                                                      
227 ms ± 2.52 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [10]: %timeit f2(a)                                                                                                                                                                                        
260 ms ± 3.09 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [11]: %timeit f1_numba(a)                                                                                                                                                                                  
230 ms ± 1.69 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [12]: %timeit f2_numba(a)                                                                                                                                                                                  
457 ms ± 5.23 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [13]: %timeit numexpr.evaluate("sin(a) ** 2 + cos(a) ** 2")                                                                                                                                                
52.3 ms ± 216 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
```

- Why is `f2` a bit slower than `f1`? I thought Numpy creates temp variables and it doesn't matter how I write my code?
- Why is `f2_numba` so much slower than `f1_numba`? Shouldn't both compile to the same function and give identical performance?

---

I couldn't find any information on http://numba.pydata.org/numba-doc/latest/user/performance-tips.html or anywhere in the Numba docs concerning this question of whether using temp local variables is OK or not when one wants good performance.

Could you please add some documentation giving advice / information on this point?
Or - if possible - improve Numba to make this question void by generating the same good performance one gets from a single expression?
user: cdeil
labels: performance: performance related issue
discussion: An issue requiring discussion
issue_3971: state: open
title: numpy isin
body: Hello here im using numba for my own lib for speedup data preprocessing and would love to see isin as numpy supported function :)
(I see in1d topic but following numpy docs -> We recommend using isin instead of in1d for new code)
user: machineko
labels: good first issue: A good issue for a first time contributor
issue_3966: state: open
title: String interning optimization
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request
CPython implements string interning optimization, which uses a global dictionary of strings to represent common values (some details [here](http://guilload.com/python-string-interning/)). I think we could think about this optimization in Numba as well.
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: ehsantn
issue_3965: state: open
title: Short String Optimization (SSO)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request
I just profiled a string-heavy workload, and it shows reference counting, allocation, and deallocation as the bottlenecks. Since a lot of strings are small in practice (e.g. parsing), small string optimization (SSO) can be highly effective.

We can look at `std::string` implementations to see examples of SSO. For example, Clang's libc++ stores up to 22 characters without allocation (see [here](https://stackoverflow.com/questions/21694302/what-are-the-mechanics-of-short-string-optimization-in-libc)).
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: ehsantn
issue_3958: state: open
title: Meta issue for variable naming and user-annotation dict getting out-of-sync
body: User annotation dictionary (i.e. `locals`) attaches metadata to variable names.  The bytecode interpreter may rename variables due to variable redefinition (and SSA) and possibly due to other transformation passes.  As a result, the annotation may be loss because the variable naming changed.  

Related PRs: https://github.com/numba/numba/pull/3946

(ping: @ehsantn, @DrTodd13)
user: sklam
labels: discussion: An issue requiring discussion
SSA: Problem due to SSA (or lack of)
issue_3957: state: open
title: Fix gdb launch race condition
body: This uses pipes to orchestrate a blocking condition when gdb
launches so to avoid a race condition between parent/child.

Fixes #3642

<!--

Thanks for wanting to contribute to Numba :)

First, if you need some help or want to chat to the core developers, please
visit https://gitter.im/numba/numba for real time chat or post to the Numba
mailing list https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

Here's some guidelines to help the review process go smoothly.

0. Please write a description in this text box of the changes that are being
   made.

1. Please ensure that you have written units tests for the changes made/features
   added.

2. If you are closing an issue please use one of the automatic closing words as
   noted here: https://help.github.com/articles/closing-issues-using-keywords/

3. If your pull request is not ready for review but you want to make use of the
   continuous integration testing facilities please label it with `[WIP]` and
   then remove the label when you'd like it to be reviewed.

4. Once review has taken place please do not add features or make changes out of
   the scope of those requested by the reviewer (doing this just add delays as
   already reviewed code ends up having to be re-reviewed/it is hard to tell
   what is new etc!). Further, please do not rebase your branch on master/force
   push/rewrite history, doing any of these causes the context of any comments
   made by reviewers to be lost. If conflicts occur against master they should
   be resolved by merging master into the branch used for making the pull
   request.

Many thanks in advance for your cooperation!

-->

user: stuartarchibald
labels: Pending BuildFarm: For PRs that have been reviewed but pending a push through our buildfarm
issue_3948: state: open
title: cfunc sig/signature attribute. 
body: really simple request have some way of getting the signature used to compile the cfunc.

In my use case I would like to pass a cfunc into a class/function however I need to make sure that the signature of the function actually matches a specific signature for error handling so it would be nice if there was a way of accessing the signature of the cfunc. 

After looking at the `CFunc` class it seems like there is a private attribute `_sig` which contains the information that I would in principle need, is there any reason why this is could not be exposed to the public API?






user: weinbe58
issue_3934: state: open
title: numba.errors.NotDefinedError: Variable '$8.2' is not defined
body: Can anyone help me to resolve this issue ? Thanks very much~

It will work if I remove the decorator @jit
```
$ python gendata.py
runTime: 5.401679992675781
```
```
$ head datafile
1 886215525234406 20190403-08:51:39.088782 zdvmulzcvgamfkpfnxej smkn@ugsb.com
2 338428593811377 20190403-08:51:39.088979 ttawsfucjftsffpmbzur lnhoe@qggzneiqhl.edu
3 3931073299927094 20190403-08:51:39.089052 xcouvooxuzuyuqadgbvv azkm@coqpbi.gov
4 398660292972212 20190403-08:51:39.089112 duzvmhxohezlfcjubgvy vzxz@audxjkbzsxex.gov
5 1513212543887088 20190403-08:51:39.089175 ifuegalbhpimmuswpcdr tuijxzc@slgfsspbwx.com
6 4430088472792036 20190403-08:51:39.089244 byuxvlybdjyhzpfchsrt rlofuzf@zohfknief.edu
7 391859031394301 20190403-08:51:39.089309 jduetxwivrkwtaedtgpe vkjmg@siitvegzxva.net
8 1903014840747994 20190403-08:51:39.089369 odxgfenrdzuspawwkwhd akah@jogtrnysg.net
9 2681734757974063 20190403-08:51:39.089428 pxxvoxfouleulkodfmsp aeunhz@glexfxyki.org
10 664508848647411 20190403-08:51:39.089490 ecuihedygyjamfzzionvc kiyvvw@ptcbrsk.com
```

This is my first time using numba, the following is source code.
gendata.py

```python
import time
import datetime
from numba import jit
from random import randrange, choice
from string import ascii_lowercase as lc

@jit
def gen_data(filename):
    with open(filename,"w+") as f:
        for i in range(1,100001):
            dtint = randrange(2**52)
            now = datetime.datetime.now()
            dtime = now.strftime("%Y%m%d-%H:%M:%S.%f")

            llen = randrange(4,8)
            l1 = []
            for j in range(llen):
                l1.append(choice(lc))
            login = "".join(l1)
            # login = ''.join(choice(lc) for j in range(llen))

            dlen = randrange(llen, 13)
            l2 = []
            for j in range(dlen):
                l2.append(choice(lc))
            dom = "".join(l2)
            # dom = ''.join(choice(lc) for j in xrange(dlen))

            suff = choice(tlds)
            dmail = login + "@" + dom + "." + suff

            l3 = []
            for j in range(randrange(20,22)):
                l3.append(choice(lc))
            dtstr="".join(l3)
            # dtstr=''.join(choice(lc) for j in range(randrange(20,22)))
            print(i,dtint,dtime,dtstr,dmail, end="\n", file=f)


if __name__ == "__main__":
    tlds = ("com", "edu", "net", "org", "gov")
    startTime = time.time()
    gen_data("/tmp/datafile")
    endTime = time.time()
    runTime = endTime - startTime
    print(f"runTime: {runTime}")
```

python and numba version
```
python 3.7.3
numba  0.43.1
```

system info
```
Model Name:	MacBook Pro
Model Identifier:	MacBookPro11,4
Processor Name:	Intel Core i7
Processor Speed:	2.2 GHz
Number of Processors:	1
Total Number of Cores:	4
L2 Cache (per Core):	256 KB
L3 Cache:	6 MB
Memory:	16 GB
Boot ROM Version:	189.0.0.0.0
SMC Version (system):	2.29f24
```

Traceback
```
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/start/.pyenv/versions/3.7.3/lib/python3.7/site-packages/numba/ir.py", line 806, in get_exact
    return self.localvars.get(name)
  File "/Users/start/.pyenv/versions/3.7.3/lib/python3.7/site-packages/numba/ir.py", line 168, in get
    raise NotDefinedError(name)
numba.errors.NotDefinedError: Variable '$8.2' is not defined.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/start/.pyenv/versions/3.7.3/lib/python3.7/site-packages/numba/ir.py", line 166, in g#!/usr/bin/env python
et
    return self._con[name]
KeyError: '$8.2'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "gendata.py", line 43, in <module>
    gen_data("/tmp/datafile")
  File "/Users/start/.pyenv/versions/3.7.3/lib/python3.7/site-packages/numba/dispatcher.py", line 358, in _compile_for_args
    error_rewrite(e, 'interpreter')
  File "/Users/start/.pyenv/versions/3.7.3/lib/python3.7/site-packages/numba/dispatcher.py", line 317, in error_rewrite
    reraise(type(e), e, None)
  File "/Users/start/.pyenv/versions/3.7.3/lib/python3.7/site-packages/numba/six.py", line 658, in reraise
    raise value.with_traceback(tb)
numba.errors.NotDefinedError: Failed in object mode pipeline (step: analyzing bytecode)
Variable '$8.2' is not defined.
Unsupported Python functionality was found in the code Numba was trying to
compile. This error could be due to invalid code, does the code work
without Numba? (To temporarily disable Numba JIT, set the `NUMBA_DISABLE_JIT`
environment variable to non-zero, and then rerun the code).

If the code is valid and the unsupported functionality is important to you
please file a feature request at: https://github.com/numba/numba/issues/new

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/dev/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/dev/reference/numpysupported.html
```
user: binbjz
issue_3930: state: open
title: Vectorize docs improvement
body: I feel that @vectorize (especially on cuda) is the most restrictive decorator and the fastest one at the same time.
On the other hand @njit (on cpu) supports the most features. 
The docs for these two should better reflect the corresponding support, so that for a newcomer it can have an overview of the limitations attached to @vectorize but also the freedom of @njit.

user: cristipurdel
issue_3922: state: open
title: Loading cubin
body: 
## Feature request

(From mailing list
https://groups.google.com/a/continuum.io/forum/?utm_medium=email&utm_source=footer#!msg/numba-users/VvAYx81M68Q/wdZDHDGGAwAJ)

Feature request for API to load from cubin.

**Update**

usecase:
>  use numba to load and launch cuda kernels from cubin file which is compiled by nvcc.
user: sklam
labels: CUDA: CUDA related issue/PR
issue_3916: state: open
title: Use optional return values for guvectorize
body: In https://numba.pydata.org/numba-doc/dev/user/vectorize.html#the-guvectorize-decorator the docs say:

> Contrary to vectorize() functions, guvectorize() functions don’t return their result value: they take it as an array argument, which must be filled in by the function. This is because the array is actually allocated by NumPy’s dispatch mechanism, which calls into the Numba-generated code.

To get around this I find myself writing functions that look like the following:

```python
@guvectorize(...)
def f(x, out):
    y = g(x)
    out[:] = y
```

Which seems like the kind of thing that syntactic sugar might be able to get around.  Perhaps, if the user's function returns a value then numba might take this as a sign and do this for them automatically?
user: mrocklin
issue_3915: state: open
title: Support GPUs for numba.stencil
body: The Stencil functions seem like a convenient entry point for CUDA acceleration.  

My hope is that the constained nature of the user API would make the automatic generation of CUDA kernels somewhat more straightforward than in the fully general case.
user: mrocklin
labels: CUDA: CUDA related issue/PR
issue_3914: state: open
title: Allow numba.jit to compose with numba.stencil
body: Today, I think that the way to use stencil functions with numba is to include them in another function that is jitted.

```python
@numba.stencil
def f(x):
    ...

@numba.jit
def g(x):
    return f(x)
```

I wonder if it might make sense instead to allow `numba.jit` to be directly composed with `numba.stencil`

```python
@numba.jit
@numba.stencil
def f(x):
    ...
```

Or, going further, stencil may just have a `jit=True` keyword.  When I originally tried to use stencil I assumed that it would jit automatically.  I suspect that most users coming to this function for the first time have a similar expectation, used to as we are with the simple API of numba.jit.

### Example

<details>

```python
In [1]: import numba

In [2]: import numpy as np

In [3]: x = np.arange(25).reshape((5, 5))

In [4]: x
Out[4]:
array([[ 0,  1,  2,  3,  4],
       [ 5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14],
       [15, 16, 17, 18, 19],
       [20, 21, 22, 23, 24]])

In [5]: @numba.stencil
   ...: def f(x):
   ...:     return (x[-1, -1] + x[-1, 0] + x[-1, 1] +
   ...:             x[ 0, -1] + x[ 0, 0] + x[ 0, 1] +
   ...:             x[ 1, -1] + x[ 1, 0] + x[ 1, 1])
   ...:

In [6]: %timeit f(x)
189 ms ± 1.24 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [7]: @numba.njit
   ...: @numba.stencil
   ...: def f(x):
   ...:     return (x[-1, -1] + x[-1, 0] + x[-1, 1] +
   ...:             x[ 0, -1] + x[ 0, 0] + x[ 0, 1] +
   ...:             x[ 1, -1] + x[ 1, 0] + x[ 1, 1])
   ...:
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-7-f2d04f4f5a9e> in <module>
      1 @numba.njit
----> 2 @numba.stencil
      3 def f(x):
      4     return (x[-1, -1] + x[-1, 0] + x[-1, 1] +
      5             x[ 0, -1] + x[ 0, 0] + x[ 0, 1] +

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/decorators.py in njit(*args, **kws)
    234         warnings.warn('forceobj is set for njit and is ignored', RuntimeWarning)
    235     kws.update({'nopython': True})
--> 236     return jit(*args, **kws)
    237
    238

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/decorators.py in jit(signature_or_function, locals, target, cache, pipeline_class, **options)
    171                    targetoptions=options, **dispatcher_args)
    172     if pyfunc is not None:
--> 173         return wrapper(pyfunc)
    174     else:
    175         return wrapper

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/decorators.py in wrapper(func)
    187         disp = dispatcher(py_func=func, locals=locals,
    188                           targetoptions=targetoptions,
--> 189                           **dispatcher_args)
    190         if cache:
    191             disp.enable_caching()

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/dispatcher.py in __init__(self, py_func, locals, targetoptions, impl_kind, pipeline_class)
    542         arg_count = len(pysig.parameters)
    543         can_fallback = not targetoptions.get('nopython', False)
--> 544         _DispatcherBase.__init__(self, arg_count, py_func, pysig, can_fallback)
    545
    546         functools.update_wrapper(self, py_func)

~/miniconda/envs/dev/lib/python3.7/site-packages/numba/dispatcher.py in __init__(self, arg_count, py_func, pysig, can_fallback)
    180
    181         argnames = tuple(pysig.parameters)
--> 182         default_values = self.py_func.__defaults__ or ()
    183         defargs = tuple(OmittedArg(val) for val in default_values)
    184         try:

AttributeError: 'StencilFunc' object has no attribute '__defaults__'

In [8]: @numba.njit
   ...: def g(x):
   ...:     return f(x)
   ...:

In [9]: g(x)
Out[9]:
array([[  0,   0,   0,   0,   0],
       [  0,  54,  63,  72,   0],
       [  0,  99, 108, 117,   0],
       [  0, 144, 153, 162,   0],
       [  0,   0,   0,   0,   0]])

In [10]: %timeit g(x)
569 ns ± 27.5 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
```

</detals>
user: mrocklin
issue_3902: state: open
title: Add casting capability to cffi_support.ffi.from_buffer in nopython mode
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Currently casting a numpy array with dtype=np.complex128 and passing it to cffi function is not possible in nopython mode.

```
from numba import cffi_support, njit
import numpy as np

def f(a):
    cdata = cffi_support.ffi.from_buffer('double []', a)
    
a = np.ascontiguousarray([], dtype=np.complex128)
f(a)
njit(f)(a)
```

It would be great if different cdata could be passed. Since now it supports only the default cdata="char[]"

```
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of BoundFunction(ffi.from_buffer for ffi) with parameters (Literal[str](double []), array(complex128, 1d, C))
 * parameterized
[1] During: resolving callee type: BoundFunction(ffi.from_buffer for ffi)
[2] During: typing of call at <ipython-input-27-3dc53d0b7bf1> (4)
```
user: dimitar-petrov
issue_3898: state: open
title: np.ediff1d stricter type checking than numpy
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

The "bug" may be a good thing.  `np.ediff1d` uses the `ary` dtype as the output dtype.  Numpy allows the `to_begin` and `to_end` arguments to have bigger dtype than can be stored in the output dtype.  Thus, numpy may silently allow overflow.  The current numba behavior will fail the typing if the cast is not safe.

Numpy allows this to happen:

```python
>>> np.ediff1d(np.arange(5, dtype=np.int32), to_begin=np.int64(0xffffffff1))
array([-15,   1,   1,   1,   1], dtype=int32)
>>> np.ediff1d(np.arange(5, dtype=np.int64), to_begin=np.int64(0xffffffff1))
array([68719476721,           1,           1,           1,           1])
```

But, numba will raise TypingError regarding `np.int64` cannot be downcasted to `np.int32`.

Reproducer: running the test `test_ediff1d_edge_cases (numba.tests.test_np_functions.TestNPFunctions)` on win64 + np1.16.

Particularly, this: https://github.com/numba/numba/blob/5aaf81c4605331b657778dc1d0db29ef95564b47/numba/tests/test_np_functions.py#L1579-L1580

On win64, `ary` is typed to `np.int32` and `to_begin` is typed to `int64`.
user: sklam
issue_3878: state: open
title: Add support for NumPy `insert`
body: 
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

As title. From https://gitter.im/numba/numba?at=5c8f2a2da21ce51a207b2899.
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_3877: state: open
title: support bytes as key_type in typed Dict
body: currently only unicode_type is supported as key_type in the new Dict.
bytes are also immutable and should be supported.
currently trying to do 
`d = Dict.empty(key_type=numba.typeof(b''),value_type=types.int32)`
will result an error 

Traceback (most recent call last):

  File "<ipython-input-41-897fa6428797>", line 1, in <module>
    d = Dict.empty(key_type=numba.typeof(b''),value_type=types.int32)

  File "C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\typed\typeddict.py", line 86, in empty
    return cls(dcttype=DictType(key_type, value_type))

  File "C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\typed\typeddict.py", line 97, in __init__
    self._dict_type, self._opaque = self._parse_arg(**kwargs)

  File "C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\typed\typeddict.py", line 106, in _parse_arg
    opaque = _make_dict(dcttype.key_type, dcttype.value_type)

  File "C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dispatcher.py", line 350, in _compile_for_args
    error_rewrite(e, 'typing')

  File "C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dispatcher.py", line 317, in error_rewrite
    reraise(type(e), e, None)

  File "C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\six.py", line 658, in reraise
    raise value.with_traceback(tb)

TypingError: Invalid use of Function(<function new_dict at 0x00000168CF31FD90>) with argument(s) of type(s): (typeref[readonly bytes(uint8, 1d, C)], class(int32))
 * parameterized
In definition 0:
    LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
No definition for lowering <built-in function eq>(readonly bytes(uint8, 1d, C), readonly bytes(uint8, 1d, C)) -> bool

File "..\..\..\..\..\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py", line 792:
    def imp(key, value):
        <source elided>
        dp = _dict_new_minsize(keyty, valty)
        _dict_set_method_table(dp, keyty, valty)
        ^

[1] During: lowering "$0.9 = call $0.5(dp, $0.7, $0.8, func=$0.5, args=[Var(dp, C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (791)), Var($0.7, C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (792)), Var($0.8, C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (792))], kws=(), vararg=None)" at C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (792)
    raised from C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\six.py:659
In definition 1:
    LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
No definition for lowering <built-in function eq>(readonly bytes(uint8, 1d, C), readonly bytes(uint8, 1d, C)) -> bool

File "..\..\..\..\..\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py", line 792:
    def imp(key, value):
        <source elided>
        dp = _dict_new_minsize(keyty, valty)
        _dict_set_method_table(dp, keyty, valty)
        ^

[1] During: lowering "$0.9 = call $0.5(dp, $0.7, $0.8, func=$0.5, args=[Var(dp, C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (791)), Var($0.7, C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (792)), Var($0.8, C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (792))], kws=(), vararg=None)" at C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\dictobject.py (792)
    raised from C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\six.py:659
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<function new_dict at 0x00000168CF31FD90>)
[2] During: typing of call at C:\Users\tal\Anaconda3\envs\py37\lib\site-packages\numba\typed\typeddict.py (18)

version: win10, python 3.7, numba 0.43

user: talkaminker
issue_3875: state: open
title: Function calls slow if default keyword arg is False
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Functions with a default keyword argument set to `False` seem to take orders of magnitude longer to call than if the default is set to `True`.  The following test code (using the IPython `%timeit` magic) shows a 70x performance hit from using a `False` default arg:

```python
import numba

@numba.njit
def fslow(a=False):
    pass
%timeit fslow()

@numba.njit
def ffast(a=True):
    pass
%timeit ffast()
```
```
7.81 µs ± 638 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
151 ns ± 3.91 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
```

I've confirmed this behavior across multiple machines.  The problem can be exacerbated by adding more arguments; I was seeing a floor of 100 µs in a latency-sensitive function with 7 args, which is how I discovered this behavior.  Providing all arguments seems to fix the problem.
user: lgarrison
labels: performance - run time: Performance issue occurring at run time.
issue_3873: state: open
title: (i)python randomly crashes when calling compiled function on non-homogeneous list argument
body: ## Reporting a bug

I'm on Windows using numba 0.43 (rather excited by the dict support by the way!), Python 3.7.2. 
For what it's worth, I get the same results with Python 3.6.5 and numba 0.39.

One of my function arguments is a list of tuples of lists. Surprisingly, my function seems to get called succesfully, but subsequent calls appear to crash ipython. 

Generally, if I run the MWE below in ipython (with ipython magic `%run mwe.py`), it'll crash shortly. Calling `dummy_func(inhom_arg)` an additional time in the ipython prompt nearly always results in a crash. It appears to be somewhat random, sometimes I've been able to do five calls in the prompt.

## Minimum working example

`mwe.py`
```python
import numba

@numba.njit
def dummy_func(inhom_arg):
    pass

inhom_arg = [
     ([0, 1], [[0, 1], [2, 3]])
]

dummy_func(inhom_arg)
dummy_func(inhom_arg)
```

Then in ipython:
```python
%run mwe.py
dummy_func(inhom_arg)
```

## Expected output
I think I would expect an exception in this case. I was rather surprised that I could pass such an argument, at which point I naively assumed this worked.





user: Huite
issue_3860: state: open
title: automatic wrapper or function to wrap complex values returned from C-ABI functions
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Following on from https://github.com/numba/numba/issues/3086#issuecomment-471723980, either autogenerate or provide a function to help with the case where a C-ABI function returns a complex value (`double complex` or `float complex` from C). Need to look at what clang and GCC generate on multiple architectures, work out the pattern and essentially do the same.
user: stuartarchibald
issue_3855: state: open
title: Extending and strengthening `numba.extending.overload`
body: ## Feature request

The decorator `numba.extending.overload` (`@overload`) has been used a lot for Numba internal implementations since its inception and it has fulfilled the requirement of presenting an easy method for adding new functionality to Numba. It is now quite clear that should be possible to rewrite large amounts of Numba internals with this decorator, this shrinking the code base considerably and also making internal implementations have a look and feel like NumPy. This presents an opportunity to make amendments to `@overload` that help with this rewrite so as to:
 * progressively make mismatches between typing and lowering implementations far less likely
 * improve error messages for users and e.g. add hints on how to fix
 * add additional convenience in terms of code generation.

Here's some initial ideas for new kwargs to `@overload` (but would also be applicable to the other functions in `numba.extending`):

**kwarg: signatures**
  - supported signature(s) are spelled out, will be described via a mini-language, this permits more meta-types, like `ArrayLike`.
  - this mini-language is used to strictly enforce type resolution at the implementation boundary, essentially this allows the checking of types from inference to make sure they match what is declared.
  - the above feeds into error messages, for example:
    `CompilationError: Could not compile X, unsupported types presented to function <the function>, types given <the inferred types>, but function supports <the supported types>`
  - it should be possible to detect mismatch between declared support and what typing thinks?
      - If there's a mismatch, it means there's a bug somewhere.
      - this should be categorised as reportable as something is internally inconsistent
  - it should be possible to write a fuzzer based on mini-language declaration to help find issues.

**kwarg: auto_asarray**
  -  this may or may not get rolled into the above mini-language, but the intention is to signal that some args could/should automatically be converted to arrays if they are array-like:
      - this means most of the time only one implementation of an alg will be needed
      - there are some efficiency concerns ? should we warn when this happens?
      - complexity in typing and error messages potentially increases

Extending `@overload` further for a NumPy specific overload e.g. (`@overload_np`) might be useful too. The intention here is to provide consistency against the NumPy API.

 - The `@overload_np` would, in addition to the above, parse the NumPy function being overloaded to obtain a signature and then check that the args match by name and default value in the overload implementation. The question arises as to whether this could/should this be generalized so that whatever the function being overloaded, it is read and checked? However, problems may occur if there's no usable inspection capacity?!

Thoughts?
user: stuartarchibald
issue_3838: state: open
title: Add or document signature syntax for zero dimensional arrays
body: ## Problem Being addressed.
Numba has a text syntax for function signatures such as 
``` 'f8' or 'float32[:,:]' ```

However there is no simple text syntax for other arrays such as zero dimensional arrays

You can do this using a poorly documented alternative syntax of using explicit types in the signature rather than the simplified text string convention.  For example
```@nb.njit(nb.types.Array(nb.int64, 0, "C")())```

## Feature request

Add syntax for at least the Zero dimensional case since this is actually pretty common when using cuda.  (because you can store scalars on the GPU if you make them zero dimensional arrays).

Here's a possible syntax that might be worth considering.

```'float32[]'   # empty brackets without any colons would imply zero dimensions```

A final matter to consider would be if one wants to also worry about fortran versus C order arrays.  My vote would be not to worry about that since it would complicate the syntax.  But if you chose to do so then a possible ansatz would be to replace the ":" colon sigils with the letter F like this:

```'float32[F,F]'```  # where F is the signal for a fortran order 2 D array

Note that zero and 1D arrays are identical in C and F 

 


user: cems2
issue_3823: state: open
title: "cannot determine Numba type" when calling AOT-compiled function from AOT-compiled function
body: If you take the AOT example file from the documentation and add another function to it,
```
@cc.export('runall', '()')
def runall():
    square(4)
```

you get this traceback when attempting to compile it.  From this I conclude that numba does not support nesting AOT-compiled functions.  True?   If not I would like to see a working example in your docs.
```
Traceback (most recent call last):
  File "setup.py", line 26, in <module>
    ext_modules=[cc.distutils_extension()])
  File "tenv/local/lib/python2.7/site-packages/setuptools/__init__.py", line 145, in setup
    return distutils.core.setup(**attrs)
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "tenv/local/lib/python2.7/site-packages/wheel/bdist_wheel.py", line 192, in run
    self.run_command('build')
  File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/distutils/command/build.py", line 128, in run
    self.run_command(cmd_name)
  File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "tenv/local/lib/python2.7/site-packages/setuptools/command/build_ext.py", line 78, in run
    _build_ext.run(self)
  File "/usr/lib/python2.7/distutils/command/build_ext.py", line 339, in run
    self.build_extensions()
  File "/usr/lib/python2.7/distutils/command/build_ext.py", line 448, in build_extensions
    self.build_extension(ext)
  File "tenv/local/lib/python2.7/site-packages/setuptools/command/build_ext.py", line 199, in build_extension
    _build_ext.build_extension(self, ext)
  File "tenv/local/lib/python2.7/site-packages/numba/pycc/cc.py", line 293, in build_extension
    ext._prepare_object_files(self)
  File "tenv/local/lib/python2.7/site-packages/numba/pycc/cc.py", line 274, in _prepare_object_files
    objects, _ = cc._compile_object_files(build_ext.build_temp)
  File "tenv/local/lib/python2.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "tenv/local/lib/python2.7/site-packages/numba/pycc/cc.py", line 200, in _compile_object_files
    compiler.write_native_object(temp_obj, wrap=True)
  File "tenv/local/lib/python2.7/site-packages/numba/pycc/compiler.py", line 198, in write_native_object
    library = self._cull_exports()
  File "tenv/local/lib/python2.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "tenv/local/lib/python2.7/site-packages/numba/pycc/compiler.py", line 157, in _cull_exports
    locals={}, library=library)
  File "tenv/local/lib/python2.7/site-packages/numba/compiler.py", line 926, in compile_extra
    return pipeline.compile_extra(func)
  File "tenv/local/lib/python2.7/site-packages/numba/compiler.py", line 374, in compile_extra
    return self._compile_bytecode()
  File "tenv/local/lib/python2.7/site-packages/numba/compiler.py", line 857, in _compile_bytecode
    return self._compile_core()
  File "tenv/local/lib/python2.7/site-packages/numba/compiler.py", line 844, in _compile_core
    res = pm.run(self.status)
  File "tenv/local/lib/python2.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "tenv/local/lib/python2.7/site-packages/numba/compiler.py", line 255, in run
    raise patched_exception
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'square': cannot determine Numba type of <type 'function'>

File "numbatest/multsquare.py", line 26:
def runall():
    square(4)
    ^

```
user: nmgeek
labels: good first issue: A good issue for a first time contributor
AOT: ahead of time compilation issue
issue_3804: state: open
title: Add support for `np.matmul`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request


As title. Noted missing functionality from https://github.com/numba/numba/issues/3803.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_3802: state: open
title: (Auto?!)Generate wrappers for call convention change
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest ~~released~~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Any call to `compile_internal()` inside `@box` causes this error:
`cannot store {i8*, i32}* to i8*: mismatching types`

Here is a standalone reproducer using the interval example:

```python
from numba import jit

class Interval(object):
    """
    A half-open interval on the real number line.
    """
    def __init__(self, lo, hi):
        self.lo = lo
        self.hi = hi

    def __repr__(self):
        return 'Interval(%f, %f)' % (self.lo, self.hi)

    @property
    def width(self):
        return self.hi - self.lo

from numba import types

class IntervalType(types.Type):
    def __init__(self):
        super(IntervalType, self).__init__(name='Interval')

interval_type = IntervalType()

from numba.extending import type_callable

@type_callable(Interval)
def type_interval(context):
    def typer(lo, hi):
        if isinstance(lo, types.Float) and isinstance(hi, types.Float):
            return interval_type
    return typer


from numba.extending import box
from numba.extending import models, register_model

@register_model(IntervalType)
class IntervalModel(models.StructModel):
    def __init__(self, dmm, fe_type):
        members = [
            ('lo', types.float64),
            ('hi', types.float64),
            ]
        models.StructModel.__init__(self, dmm, fe_type, members)

from numba.extending import lower_builtin
from numba import cgutils

@lower_builtin(Interval, types.Float, types.Float)
def impl_interval(context, builder, sig, args):
    typ = sig.return_type
    lo, hi = args
    interval = cgutils.create_struct_proxy(typ)(context, builder)
    interval.lo = lo
    interval.hi = hi
    return interval._getvalue()

@box(IntervalType)
def box_interval(typ, val, c):
    """
    Convert a native interval structure to an Interval object.
    """
    c.context.compile_internal(c.builder, lambda: 1, types.intp(), ())
    interval = cgutils.create_struct_proxy(typ)(c.context, c.builder, value=val)
    lo_obj = c.pyapi.float_from_double(interval.lo)
    hi_obj = c.pyapi.float_from_double(interval.hi)
    class_obj = c.pyapi.unserialize(c.pyapi.serialize_object(Interval))
    res = c.pyapi.call_function_objargs(class_obj, (lo_obj, hi_obj))
    c.pyapi.decref(lo_obj)
    c.pyapi.decref(hi_obj)
    c.pyapi.decref(class_obj)
    return res

@jit(nopython=True)
def sum_intervals(i, j):
    return Interval(i, j)

sum_intervals(0.0, 4.0)

```
user: ehsantn
issue_3797: state: open
title: Move _nonoptional a common intrinsic 
body: This issue is a TODO item for: https://github.com/numba/numba/pull/3777#discussion_r258593341
user: sklam
issue_3793: state: open
title: send method of generators
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

Currently, the `send` method of generators is not implemented. In Python, calling send on a generator allows data to be passed into it, which becomes the return value of the `yield` statement. This allows generators to act as filters that process streams of data, rather than only being data sources.

Implementing this in numba would be enormously helpful for processing audio streams and other time series data, and would likely have other applications as well.


user: nathanielvirgo
issue_3790: state: open
title: Expose all the numba env var controls through command line arguments
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request
There is an "entry point" as conda-build defines it, which enables command line interface with numba package, e.g. `numba --help`. It is a convenient way to list all the available options and recall how to dump an assembly or order annotated html report. But there are not all the global controls, which are available through environment variables only. Duplicating all the rest of env var options as `numba` command line arguments would be a perfectionist's usability dream ;-)
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: anton-malakhov
issue_3784: state: open
title: Feature request: implement range as a type
body: I've managed to get this one pretty short:

```python
import numba

@numba.njit
def foo(x):
    return list(range(x))

@numba.njit
def bar(x):
    return list(x)

foo(3)  # Returns [1, 2, 3]

bar(range(3))  # Throws the TypingError:
```

<details>

```python
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-2-6a02ce2a7a63> in <module>
----> 1 bar(range(3))

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    346                 e.patch_message(msg)
    347 
--> 348             error_rewrite(e, 'typing')
    349         except errors.UnsupportedError as e:
    350             # Something unsupported is present in the user code, add help info

/usr/local/lib/python3.7/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    313                 raise e
    314             else:
--> 315                 reraise(type(e), e, None)
    316 
    317         argtypes = []

/usr/local/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.typeinfer.ArgConstraint object at 0x11c14fd68>:
--%<----------------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/numba/errors.py", line 617, in new_error_context
    yield
  File "/usr/local/lib/python3.7/site-packages/numba/typeinfer.py", line 198, in __call__
    assert ty.is_precise()
AssertionError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/numba/typeinfer.py", line 141, in propagate
    constraint(typeinfer)
  File "/usr/local/lib/python3.7/site-packages/numba/typeinfer.py", line 199, in __call__
    typeinfer.add_type(self.dst, ty, loc=self.loc)
  File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/local/lib/python3.7/site-packages/numba/errors.py", line 625, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/usr/local/lib/python3.7/site-packages/numba/six.py", line 659, in reraise
    raise value
numba.errors.InternalError: 
[1] During: typing of argument at <ipython-input-1-95ca53cca6e8> (9)
--%<----------------------------------------------------------------------------


File "<ipython-input-1-95ca53cca6e8>", line 9:
def bar(x):
    return list(x)
    ^

This error may have been caused by the following argument(s):
- argument 0: cannot determine Numba type of <class 'range'>
```

</details>

I thought both of these were intended to work, as the docs say [range types are supported](http://numba.pydata.org/numba-doc/latest/reference/pysupported.html#built-in-functions).

I'm running numba `0.42.1` on macOS `10.14.3`, in python `3.7.2`.
user: ivirshup
issue_3781: state: open
title: Failure when trying to use a JitClass
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

The following code produces an error message telling me to submit a bug report, so I am doing so.

I expected it to call `test.get_value()` and print the returned value of 1. If I remove the line `@nb.njit`, it works as expected

```
import numba as nb

@nb.jitclass([])
class Test:
	def __init__(self):
		pass
	def get_value(self):
		return 1

test = Test()

@nb.njit
def use_test():
	return test.get_value()

print(use_test())
```

Here is the error message it gives:

```
Traceback (most recent call last):
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/targets/base.py", line 499, in get_constant_generic
    impl = self._get_constants.find((ty,))
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/targets/base.py", line 50, in find
    out = self._find(sig)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/targets/base.py", line 59, in _find
    raise NotImplementedError(self, sig)
NotImplementedError: (<numba.targets.base.OverloadSelector object at 0x11c2e1a58>, (instance.jitclass.Test#7f9f394d82a8<>,))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/errors.py", line 617, in new_error_context
    yield
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 259, in lower_block
    self.lower_inst(inst)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 308, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 449, in lower_assign
    value.value)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/targets/base.py", line 502, in get_constant_generic
    raise NotImplementedError("Cannot lower constant of type '%s'" % (ty,))
NotImplementedError: Cannot lower constant of type 'instance.jitclass.Test#7f9f394d82a8<>'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "minrep3.py", line 16, in <module>
    print(use_test())
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 367, in _compile_for_args
    raise e
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 324, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 655, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 82, in compile
    pipeline_class=self.pipeline_class)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 926, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 374, in compile_extra
    return self._compile_bytecode()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 857, in _compile_bytecode
    return self._compile_core()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 844, in _compile_core
    res = pm.run(self.status)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 255, in run
    raise patched_exception
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 246, in run
    stage()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 717, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 666, in _backend
    lowered = lowerfn()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 653, in backend_nopython_mode
    self.metadata)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 1048, in native_lowering_stage
    lower.lower()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 178, in lower
    self.lower_normal_function(self.fndesc)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 219, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 244, in lower_function_body
    self.lower_block(block)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 259, in lower_block
    self.lower_inst(inst)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/errors.py", line 625, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/six.py", line 659, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Cannot lower constant of type 'instance.jitclass.Test#7f9f394d82a8<>'

File "minrep3.py", line 14:
def use_test():
	return test.get_value()
 ^

[1] During: lowering "$0.1 = global(test: <numba.jitclass.boxing.Test object at 0x11cd45f10>)" at minrep3.py (14)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```
user: nathanielvirgo
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_3780: state: open
title: Failure when trying to use return value of yield
body: When running the following code, I get an error telling me to submit a bug report, so I am doing so.

```
import numba as nb

@nb.njit
def test():
    i=0
    while True:
       i = yield i

g = test()
```

So far, any time I try to use the return value of yield it throws one error or another. Is this supported? 

The notes at https://numba.pydata.org/numba-doc/dev/reference/pysupported.html say that the `yield from` construct is not supported, but they don't mention using the return value of `yield`, so I was hopeful that it would be supported.

Here is the error that the above code gives:

```
Traceback (most recent call last):
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/errors.py", line 617, in new_error_context
    yield
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 259, in lower_block
    self.lower_inst(inst)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 308, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 482, in lower_assign
    res = self.lower_yield(ty, value)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 502, in lower_yield
    retval = self.context.get_return_value(self.builder, typ, yret)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/targets/base.py", line 653, in get_return_value
    return self.data_model_manager[ty].as_return(builder, val)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/datamodel/models.py", line 895, in as_return
    raise NotImplementedError
NotImplementedError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "minrep2.py", line 9, in <module>
    g = test()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 367, in _compile_for_args
    raise e
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 324, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 655, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/dispatcher.py", line 82, in compile
    pipeline_class=self.pipeline_class)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 926, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 374, in compile_extra
    return self._compile_bytecode()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 857, in _compile_bytecode
    return self._compile_core()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 844, in _compile_core
    res = pm.run(self.status)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 255, in run
    raise patched_exception
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 246, in run
    stage()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 717, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 666, in _backend
    lowered = lowerfn()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 653, in backend_nopython_mode
    self.metadata)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/compiler.py", line 1048, in native_lowering_stage
    lower.lower()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 184, in lower
    self.genlower.lower_next_func(self)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/generators.py", line 153, in lower_next_func
    entry_block_tail = lower.lower_function_body()
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 244, in lower_function_body
    self.lower_block(block)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/lowering.py", line 259, in lower_block
    self.lower_inst(inst)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/errors.py", line 625, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/Users/ndv/Library/Python/3.6/lib/python/site-packages/numba/six.py", line 659, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)


File "minrep2.py", line 7:
def test():
    <source elided>
    while True:
       i = yield i
       ^

[1] During: lowering "$6.2 = yield i" at minrep2.py (7)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```


user: nathanielvirgo
issue_3774: state: open
title: Add alias analysis information to parallel diagnostics reporting.
body: 

## Feature request

As title.

CC: @anton-malakhov @DrTodd13 
user: stuartarchibald
issue_3772: state: open
title: Use of set spins/fails to terminate
body: I'm trying to speed up my calculation of the personalized PageRank vector (PPV) with Numba using sets. `indices` and `indptr` are from a CSR-matrix representing the adjacency matrix of a graph.

The following code works without Numba but freezes with it. I've tried to reduce this as much as possible, but I couldn't get further than this.

```Python
import numpy as np
import numba

indices = np.array([ 7, 19,  9, 11,  9, 18, 14, 18,  0, 16, 19,  1,  5, 16,  2, 14, 21,
                    14,  6, 11, 12, 18, 16,  7, 10, 15, 18,  5,  6, 14, 16,  0,  7, 11],
                   dtype=np.int32)
indptr = np.array([ 0,  2,  3,  4,  4,  4,  6,  8, 11, 11, 13, 14,
                   17, 18, 18, 22, 23, 27, 27, 31, 33, 33, 34],
                  dtype=np.int32)

@numba.jit(nopython=True)
def calc_ppv_test(inode: int, nnodes: int, indptr: np.ndarray, indices: np.ndarray,
                  deg: np.ndarray, alpha: float, epsilon: float):
    r = np.zeros(nnodes, dtype=np.float32)
    r[inode] = 1.
    q = {inode}
    while len(q) > 0:
        unode = q.pop()
        res = r[unode]
        r[unode] = 0
        for vnode in indices[indptr[unode]:indptr[unode + 1]]:
            r[vnode] += (1 - alpha) * res / deg[unode]
            if r[vnode] >= epsilon * deg[vnode]:
                q.add(vnode)

deg = indptr[1:] - indptr[:-1]
nnodes = len(indptr) - 1
for inode in range(nnodes):
    calc_ppv_test(inode, nnodes, indptr, indices, deg, 0.1, 1e-3)
```
user: gasteigerjo
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_3770: state: open
title: Feature request: branching hints
body: ## Feature request: Branching hints

Low-level language compilers, such as GCC for C, allow to insert information about the more likely branch of an if statement (__builtin_expect), often in the form of macros:

```C
#define LIKELY(condition) __builtin_expect(static_cast<bool>(condition), 1)
#define UNLIKELY(condition) __builtin_expect(static_cast<bool>(condition), 0)
...
if LIKELY(ptr!=NULL)
{
    ...
}
```

Since numba's goal is to speed up performance critical code, it would be helpful to support this in some way, though I find this less important than prefetching (#3769).
(Also, careless use of this feature will degrade performance.)

Any opinions on this request?

user: svenrahmann
issue_3769: state: open
title: Feature request: support prefetching
body: ## Feature request: Prefetching

Many low-level languages (or their compilers) allow to insert prefetching instructions ("software prefetching"), such as the __builtin_prefetch in GCC.

For certain types of algorithms, this is extremely useful; we recently encountered a situation (with a lot of hash table lookups), where well placed prefetch instructions reduced running time to about 66%.
(Unfortunately, careless prefetching may also result in performance degradation.)

Since numba's goal is to speed up performance critical code, it would be extremely helpful to support prefetch in some way.
The most common use case would be to prefetch a certain array element, e.g.
```python
numba.__prefetch(a[i])
```

It would probably be sufficient to directly pass the instruction to LLVM, although I do not understand enough of the mechanisms involved to see how to obtain the address to prefetch.

Some background information from the GCC docs:

> Built-in Function: void __builtin_prefetch (const void *addr, ...)
> This function is used to minimize cache-miss latency by moving data into a cache before it is accessed. You can insert calls to __builtin_prefetch into code for which you know addresses of data in memory that is likely to be accessed soon. If the target supports them, data prefetch instructions are generated. If the prefetch is done early enough before the access then the data will be in the cache by the time it is accessed.
> 
> The value of addr is the address of the memory to prefetch. There are two optional arguments, rw and locality. The value of rw is a compile-time constant one or zero; one means that the prefetch is preparing for a write to the memory address and zero, the default, means that the prefetch is preparing for a read. The value locality must be a compile-time constant integer between zero and three. A value of zero means that the data has no temporal locality, so it need not be left in the cache after the access. A value of three means that the data has a high degree of temporal locality and should be left in all levels of cache possible. Values of one and two mean, respectively, a low or moderate degree of temporal locality. The default is three.
> 
```C
for (i = 0; i < n; i++)
  {
    a[i] = a[i] + b[i];
    __builtin_prefetch (&a[i+j], 1, 1);
    __builtin_prefetch (&b[i+j], 0, 1);
    /* … */
  }
```
> Data prefetch does not generate faults if addr is invalid, but the address expression itself must be valid. For example, a prefetch of p->next does not fault if p->next is not a valid address, but evaluation faults if p is not a valid address.
> 
> If the target does not support data prefetch, the address expression is evaluated if it includes side effects but no other code is generated and GCC does not issue a warning.
> 

user: svenrahmann
issue_3766: state: open
title: Inline overload implementation IR during typing
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Currently, `@overload` compiles and inserts the implementation during type inference. The analysis and optimization passes don't see the implementation, which is a significant limitation. For example, implementations of two overloaded functions can't be fused together.

The solution is to inline the IR of the implementation instead of lowering right away. 
user: ehsantn
issue_3761: state: open
title: Crash when using AOT compiled code containing namedtuples
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

OS: Windows 10
Numba version: 0.42.0
Reproducer:
```
import collections
import numba as nb
import numba.pycc as pycc


T = collections.namedtuple('T', ['a', 'b'])
t_type = nb.types.NamedTuple((nb.i8, nb.f8), T)
cc = pycc.CC('test')

@cc.export('instantiate', t_type())
def instantiate():
    return T(1, 2.0)

cc.verbose = True
cc.compile()
```

Compiles ok. Then on runtime:

```
import test
test.instantiate() // crashes
```

workaround:
```
import test
T = collections.namedtuple('T', ['a', 'b'])
test.instantiate() // does not crash
```

The namespace that `T` needs to be in depends on the namespace it was in during compilation. In this case, that namespace is `__main__`.
user: AndrewYY
labels: AOT: ahead of time compilation issue
issue_3759: state: open
title: LinkError using np.arctan2 in AOT compilation on Windows
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

OS: Windows 10
Numba version: 0.42.0
Reproducer:
```
import numpy as np
import numba as nb
import numba.pycc as pycc

cc = pycc.CC('test')

@cc.export('atan2', 'f8(f8, f8)')
def atan2(y, x):
    return np.arctan2(y, x)

cc.verbose = True
cc.compile()
```
Error: 
```
test.cp36-win_amd64.o : error LNK2001: unresolved external symbol atan2_fixed
C:\[snip]\test.cp36-win_amd64.pyd : fatal error LNK1120: 1 unresolved externals
```

user: AndrewYY
labels: AOT: ahead of time compilation issue
bug - failure to compile: Bugs: failed to compile valid code
issue_3751: state: open
title: TypeError: 'ByteCodeInst' object is not iterable
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

First time trying Numba. Got this error when I decorated my function with jit (both with and without nopython). It's a function that treats values found on a CSV file.

```
@jit
def treat_value_csv(cell, locale=None):
    try:
        is_nan = math.isnan(cell)
    except:
        is_nan = False

    if is_nan or isinstance(cell, NaTType):
        return ''
    # -----------------------------

    elif isinstance(cell, Timestamp) or isinstance(cell, datetime.time):
        if isinstance(cell, Timestamp):
            # Case the cell is timestamp python object parse it to string
            datetime_obj = datetime.datetime(
                year=cell.year, month=cell.month, day=cell.day, second=cell.second, microsecond=cell.microsecond
            )
            return convert_to_docs_timestamp(datetime_obj)
        else:
            return str(cell)
    elif isinstance(cell, datetime.datetime) or isinstance(cell, datetime.date):
        # Get the timestamp from datetime object
        if isinstance(cell, datetime.datetime):
            datetime_obj = cell
        else:
            datetime_obj = datetime.datetime.combine(cell, datetime.datetime.min.time())
        return convert_to_docs_timestamp(datetime_obj)
    elif isinstance(cell, int) or isinstance(cell, float):
        return cell
    else:
        try:
            # Case the cell is string representing an integer, parse it to integer so it won't try to parse it
            # timestamp
            int_val = int(cell)
            if len(cell) > 0 and cell[0] == '0':
                return cell
            else:
                return int_val
        except:
            try:
                # Case the cell is string representing a float, parse it to float so it won't try to parse
                # it to timestamp

                scientific_notation_matches = []
                if isinstance(cell, str) or isinstance(cell, unicode):
                    # Check if the string represents scientific number to prevent it from being parsed to float
                    match_rule = re.compile('[+\-]?[^A-Za-z]?(?:0|[1-9]\d*)(?:\.\d*)?(?:[eE][+\-]?\d+)')
                    scientific_notation_matches = re.findall(match_rule, cell)

                if cell.lower() == 'nan' or cell.lower() == 'infinity' or cell.lower() == 'inf' \
                        or scientific_notation_matches:
                    # avoid 'nan', 'infinity' or 'scientific number' string from being converted to float
                    return cell
                else:
                    return float(cell)
                    # if len(cell) > 0 and cell[0] == '0':
                    #     out_row.append(cell)
                    # else:
                    #     out_row.append(float(cell))
            except:
                # Prevents trying to convert every string to date
                if looks_like_datetime(cell):
                    try:
                        # Try to parse the string to timestamp
                        if locale and locale.get('date_format'):
                            datetime_obj = try_parsing_date(cell, date_format=locale.get('date_format'))
                        else:
                            try:
                                datetime_obj = try_parsing_date(cell, date_format="month/day/year")
                            except:
                                try:
                                    datetime_obj = try_parsing_date(cell, date_format="year/month/day")
                                except:
                                    datetime_obj = try_parsing_date(cell, date_format="day/month/year")

                        return convert_to_docs_timestamp(datetime_obj)
                    except:
                        return cell
                else:
                    return cell
```


user: mau21mau
labels: objectmode: object mode related issue
issue_3750: state: open
title: Parallel Accelerator: automatically dispatch optimization for non-aliasing arrays
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request
The issue #3745 brought up the question that Parallel Accelerator pessimistically assumes aliasing of arguments and thus requires rearranging user code in order to achieve better performance.  Example of a naive user code (based on IntelPython/BlackScholes_bench) which suffers from this issue is:
```python
# Numba does know erf function from numpy or scipy
@nb.vectorize(nopython=True)
def nberf(x):
    return erf(x)

@nb.jit(nopython=True, parallel=True)
def black_scholes( nopt, price, strike, t, rate, vol, call, put ):
    mr = -rate
    sig_sig_two = vol * vol * 2

    P = price
    S = strike
    T = t

    a = log(P / S)
    b = T * mr

    z = T * sig_sig_two
    c = 0.25 * z
    y = 1./sqrt(z)

    w1 = (a - b + c) * y
    w2 = (a - b - c) * y

    d1 = 0.5 + 0.5 * nberf(w1)
    d2 = 0.5 + 0.5 * nberf(w2)

    Se = exp(b) * S

    call[:] = P * d1 - Se * d2
    put[:] = call - P + Se

``` 
assigning `call` result to a temporary variable first and using it for `put` increases performance significantly.
```
    r = P * d1 - Se * d2
    call[:] = r
    put[:] = r - P + Se
```
@DrTodd13 
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: anton-malakhov
labels: performance: performance related issue
issue_3747: state: open
title: Support for unicode/string in cfuncs
body: Hello,
I saw in the [documentation](https://numba.pydata.org/numba-doc/dev/reference/pysupported.html#str) that some operations with str type are supported. I tested it with @jit decorator and it certainly works:

```In [14]: @numba.jit("boolean(unicode_type, unicode_type)")
    ...: def compare_str(a, b):
    ...:     return a == b
    ...:                  
In [15]: compare_str("a","a")                                                                                                                                                                                    
Out[15]: True
```

But this is not yet allowed in cfuncs, although it actually compiles:

```In [13]: @numba.cfunc("boolean(unicode_type, unicode_type)")
    ...: def compare_str(a, b):
    ...:     return a == b
    ...:    
In [12]: compare_str.ctypes("a","a")  ---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-17-63a3266c663d> in <module>
----> 1 compare_str.ctypes("a", "a")

~/.virtualenvs/py3cpp/lib/python3.6/site-packages/numba/utils.py in __get__(self, instance, type)
    351         if instance is None:
    352             return self
--> 353         res = instance.__dict__[self.name] = self.func(instance)
    354         return res
    355

~/.virtualenvs/py3cpp/lib/python3.6/site-packages/numba/ccallback.py in ctypes(self)
    159         A ctypes function object representing the C callback.
    160         """
--> 161         ctypes_args = [to_ctypes(ty) for ty in self._sig.args]
    162         ctypes_restype = to_ctypes(self._sig.return_type)
    163         functype = ctypes.CFUNCTYPE(ctypes_restype, *ctypes_args)

~/.virtualenvs/py3cpp/lib/python3.6/site-packages/numba/ccallback.py in <listcomp>(.0)
    159         A ctypes function object representing the C callback.
    160         """
--> 161         ctypes_args = [to_ctypes(ty) for ty in self._sig.args]
    162         ctypes_restype = to_ctypes(self._sig.return_type)
    163         functype = ctypes.CFUNCTYPE(ctypes_restype, *ctypes_args)

~/.virtualenvs/py3cpp/lib/python3.6/site-packages/numba/typing/ctypes_utils.py in to_ctypes(ty)
     80     if ctypeobj is None:
     81         raise TypeError("Cannot convert Numba type '%s' to ctypes type"
---> 82                         % (ty,))
     83     return ctypeobj
     84

TypeError: Cannot convert Numba type 'unicode_type' to ctypes type
```

I would like to have a C callback that does some basic operations over strings, like it is done with jitted functions.
Thanks!

user: lilsnore
issue_3744: state: open
title: Allow callee to update imprecise type in the caller
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

```python
def foo():
    a = []
    # a: List[?]
    bar(a)  # updates typeof a  to List[int]


def bar(alist):
    # alist : List[?]
    alist.append(1)
    # alist : List[int]
```
user: sklam
issue_3735: state: open
title: docs request: How to add optional jit support to a package
body: I'm worrying about adding too many dependencies to a package. I could not find any documentation on  good practice for adding optional support for the jit decorator? I would have imagined that there would have been a "How to add optional numba support to my package" in the docs.

Currently I'm thinking of doing something along the lines of the following, but I don't know if that's a good idea:
```python

try:
    from numba import jit
    print('Importing jit from Numba')
except:
    def jit(func):
        def wrapper():
            func() 
        return wrapper
    print('Numba not installed')
    
@jit
def my_optionally_jitted_function():
    pass
```
I think many developers would enjoy there being a clear way to do this.
user: thomasaarholt
issue_3729: state: open
title: array broadcast fails when using njit(parallel=True)
body: Description:
When using the jit (parallel=True), numpy array broadcasting fails incorrectly.

100% reproducible

tested on: 
Linux Mint Conda installed    numba                     0.42.0           py37h962f231_0  
Mac Osx Conda installed    numba                     0.39.0           py36h6440ff4_0  
tested from both jupyter notebook and also command line ipython.





sample code:  Multiply a 5,3 matrix by a 5,1 matrix using numpy broadcasting

```python
import numba as nb
import numpy as np

@nb.njit()
def testweird1(u,f):
   print(u.shape)
   print(f.shape)
   fzz = u*f
   print (fzz.shape)

@nb.njit(parallel=True)
def testweird2(u,f):
    print(u.shape)
    print(f.shape)
    fzz = u*f
    print (fzz.shape)
        
u = np.ones((5,3),dtype=np.float32) 
f = np.ones((5,1),dtype=np.float32)
testweird1(u,f)
print ("that worked\n")
testweird2(u,f)
```


Output:
```
(5, 3)
(5, 1)
(5, 3)
```
that worked
```
(5, 3)
(5, 1)
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-2-dcdc949288c2> in <module>
      9 u = np.ones((5,3),dtype=np.float32)
     10 f = np.ones((5,1),dtype=np.float32)
---> 11 testweird2(u,f)

AssertionError: Sizes of u, f do not match on <ipython-input-2-dcdc949288c2> (6)
```
`

user: cems2
issue_3726: state: open
title: np.cumsum returns np.int64 not np.int32 when applied to an array of np.int32
body: There is a difference between numpy and numba.  Numpy returns an array of np.int32 when np.cumsum is applied to an array of np.int32, whereas numba returns an array of np.int64.  (Apologies, I'm not quite sure why the formatting of the code has gone wrong.)

Here is a minimum viable example:

```python
import numpy as np
import numba as nb

@nb.njit()
def ReturnNumba(a):
    return np.cumsum(a)

def ReturnWithoutNumba(a):
    return np.cumsum(a)


if __name__ == '__main__':
    a = np.zeros(10,dtype = np.int32)

    combinedNumba = ReturnNumba(a)
    print("Numba return type",type(combinedNumba[0]))

    combinedNotNumba = ReturnWithoutNumba(a)
    print("Normal return type",type(combinedNotNumba[0]))

```


user: gavinpotter
issue_3723: state: open
title: Implement copy_to_host() for negative strided array
body: ## Feature request

https://github.com/numba/numba/pull/3722 fixed #3705 for `__cuda_array_interface__` but did not implement `.copy_to_host()` for negative strided array.  
user: sklam
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_3721: state: open
title: @stencil support for more complex indexing scenarios and slice bound computation
body: As outlined by tests here https://github.com/IntelLabs/numba/blob/bbca663f8e4217c353f2877389875d6644b62210/numba/tests/test_stencils.py#L2755-L2777

<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
issue_3714: state: open
title: Feature request for IntFlag support
body: Here is a minimal example:

```
from enum import IntFlag
import numba as nb
class Precip(IntFlag):
    RA = 1
    DZ = 2
    SN = 4
    
@nb.njit
def example():
    ptype = np.zeros((2,), dtype=np.uint64)
    ptype[0] = np.uint64(Precip.RA)
    return ptype
nb.__version__
example()
```
The exception message is not clear. First it states `NotImplementedError`, at the end it says "This should not have happened, a problem has occurred in Numba's internals."

```
'0.42.0'

---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/targets/base.py in cast(self, builder, val, fromty, toty)
    688         try:
--> 689             impl = self._casts.find((fromty, toty))
    690             return impl(self, builder, fromty, toty, val)

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/targets/base.py in find(self, sig)
     49         if out is None:
---> 50             out = self._find(sig)
     51             self._cache[sig] = out

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/targets/base.py in _find(self, sig)
     58         else:
---> 59             raise NotImplementedError(self, sig)
     60 

NotImplementedError: (<numba.targets.base.OverloadSelector object at 0x7fcc687a92b0>, (Enum<int64>(Precip), uint64))

During handling of the above exception, another exception occurred:

NotImplementedError                       Traceback (most recent call last)
~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    616     try:
--> 617         yield
    618     except NumbaError as e:

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    258                                    loc=self.loc, errcls_=defaulterrcls):
--> 259                 self.lower_inst(inst)
    260 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_inst(self, inst)
    307             ty = self.typeof(inst.target.name)
--> 308             val = self.lower_assign(ty, inst)
    309             self.storevar(val, inst.target.name)

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    453         elif isinstance(value, ir.Expr):
--> 454             return self.lower_expr(ty, value)
    455 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_expr(self, resty, expr)
    882         elif expr.op == 'call':
--> 883             res = self.lower_call(resty, expr)
    884             return res

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_call(self, resty, expr)
    848 
--> 849             res = impl(self.builder, argvals, self.loc)
    850 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/targets/base.py in __call__(self, builder, args, loc)
   1123     def __call__(self, builder, args, loc=None):
-> 1124         return self._imp(self._context, builder, self._sig, args, loc=loc)
   1125 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/targets/base.py in wrapper(*args, **kwargs)
   1146             kwargs.pop('loc')     # drop unused loc
-> 1147             return fn(*args, **kwargs)
   1148 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/targets/builtins.py in number_constructor(context, builder, sig, args)
    275         [valty] = sig.args
--> 276         return context.cast(builder, val, valty, sig.return_type)
    277 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/targets/base.py in cast(self, builder, val, fromty, toty)
    692             raise NotImplementedError(
--> 693                 "Cannot cast %s to %s: %s" % (fromty, toty, val))
    694 

NotImplementedError: Cannot cast Enum<int64>(Precip) to uint64: %".104" = load i64, i64* %"$0.11"

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-24-eb2c67621d0b> in <module>
     12     return ptype
     13 nb.__version__
---> 14 example()

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    365                     e.patch_message(''.join(e.args) + help_msg)
    366             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 367             raise e
    368 
    369     def inspect_llvm(self, signature=None):

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    322                 argtypes.append(self.typeof_pyval(a))
    323         try:
--> 324             return self.compile(tuple(argtypes))
    325         except errors.TypingError as e:
    326             # Intercept typing error that may be due to an argument

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, sig)
    653 
    654             self._cache_misses[sig] += 1
--> 655             cres = self._compiler.compile(args, return_type)
    656             self.add_overload(cres)
    657             self._cache.save_overload(sig, cres)

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     80                                       args=args, return_type=return_type,
     81                                       flags=flags, locals=self.locals,
---> 82                                       pipeline_class=self.pipeline_class)
     83         # Check typing error if object mode is used
     84         if cres.typing_error is not None and not flags.enable_pyobject:

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    924     pipeline = pipeline_class(typingctx, targetctx, library,
    925                               args, return_type, flags, locals)
--> 926     return pipeline.compile_extra(func)
    927 
    928 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    372         self.lifted = ()
    373         self.lifted_from = None
--> 374         return self._compile_bytecode()
    375 
    376     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    855         """
    856         assert self.func_ir is None
--> 857         return self._compile_core()
    858 
    859     def _compile_ir(self):

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    842         self.define_pipelines(pm)
    843         pm.finalize()
--> 844         res = pm.run(self.status)
    845         if res is not None:
    846             # Early pipeline completion

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    253                     # No more fallback pipelines?
    254                     if is_final_pipeline:
--> 255                         raise patched_exception
    256                     # Go to next fallback pipeline
    257                     else:

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    244                 try:
    245                     event(stage_name)
--> 246                     stage()
    247                 except _EarlyPipelineCompletion as e:
    248                     return e.result

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in stage_nopython_backend(self)
    715         """
    716         lowerfn = self.backend_nopython_mode
--> 717         self._backend(lowerfn, objectmode=False)
    718 
    719     def stage_compile_interp_mode(self):

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    664             self.library.enable_object_caching()
    665 
--> 666         lowered = lowerfn()
    667         signature = typing.signature(self.return_type, *self.args)
    668         self.cr = compile_result(

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in backend_nopython_mode(self)
    651                 self.calltypes,
    652                 self.flags,
--> 653                 self.metadata)
    654 
    655     def _backend(self, lowerfn, objectmode):

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags, metadata)
   1046         lower = lowering.Lower(targetctx, library, fndesc, interp,
   1047                                metadata=metadata)
-> 1048         lower.lower()
   1049         if not flags.no_cpython_wrapper:
   1050             lower.create_cpython_wrapper(flags.release_gil)

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower(self)
    176         if self.generator_info is None:
    177             self.genlower = None
--> 178             self.lower_normal_function(self.fndesc)
    179         else:
    180             self.genlower = self.GeneratorLower(self)

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    217         # Init argument values
    218         self.extract_function_arguments()
--> 219         entry_block_tail = self.lower_function_body()
    220 
    221         # Close tail of entry block

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_function_body(self)
    242             bb = self.blkmap[offset]
    243             self.builder.position_at_end(bb)
--> 244             self.lower_block(block)
    245 
    246         self.post_lower()

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    257             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    258                                    loc=self.loc, errcls_=defaulterrcls):
--> 259                 self.lower_inst(inst)
    260 
    261     def create_cpython_wrapper(self, release_gil=False):

~/miniconda3/envs/devel1/lib/python3.7/contextlib.py in __exit__(self, type, value, traceback)
    128                 value = type()
    129             try:
--> 130                 self.gen.throw(type, value, traceback)
    131             except StopIteration as exc:
    132                 # Suppress StopIteration *unless* it's the same exception that

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    623         from numba import config
    624         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 625         six.reraise(type(newerr), newerr, tb)
    626 
    627 

~/miniconda3/envs/devel1/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660 
    661 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Cannot cast Enum<int64>(Precip) to uint64: %".104" = load i64, i64* %"$0.11"

File "<ipython-input-24-eb2c67621d0b>", line 11:
def example():
    <source elided>
    ptype = np.zeros((2,), dtype=np.uint64)
    ptype[0] = np.uint64(Precip.RA)
    ^

[1] During: lowering "$0.12 = call $0.9($0.11, func=$0.9, args=[Var($0.11, <ipython-input-24-eb2c67621d0b> (11))], kws=(), vararg=None)" at <ipython-input-24-eb2c67621d0b> (11)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```


user: yt87
issue_3711: state: open
title: Return of scalar record from structured array fails
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest ~~released~~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
Returning a scalar record from a structured array created in njit function shows corrupted output:
```python
In [109]: dt = np.dtype([('A', np.int64), ('B', np.float64)]) 

In [113]: @numba.njit 
     ...: def f(): 
     ...:     A = np.zeros(1, dt) 
     ...:     A[0].A = 3 
     ...:     A[0].B = 1.1 
     ...:     return A[0] 
     ...:                                                                                                                                                        

In [114]: f()                                                                                                                                                    
Out[114]: (-2387225703656530210, -9.86830992e+148)
```
user: ehsantn
issue_3709: state: open
title: Lower Error when creating numpy array
body: I am creating a 2D numpy array with a mix of ints and floats:

```python
import numpy as np
from numba import jit

@njit
def fj():
    return np.array([[1, 2.1],[0,1]])

fj()
```

It fails with the following errors:

```
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
~\Anaconda3\lib\site-packages\numba\errors.py in new_error_context(fmt_, *args, **kwargs)
    598     try:
--> 599         yield
    600     except NumbaError as e:

~\Anaconda3\lib\site-packages\numba\lowering.py in lower_block(self, block)
    253                                    loc=self.loc, errcls_=defaulterrcls):
--> 254                 self.lower_inst(inst)
    255 

~\Anaconda3\lib\site-packages\numba\lowering.py in lower_inst(self, inst)
    302             ty = self.typeof(inst.target.name)
--> 303             val = self.lower_assign(ty, inst)
    304             self.storevar(val, inst.target.name)

~\Anaconda3\lib\site-packages\numba\lowering.py in lower_assign(self, ty, inst)
    448         elif isinstance(value, ir.Expr):
--> 449             return self.lower_expr(ty, value)
    450 

~\Anaconda3\lib\site-packages\numba\lowering.py in lower_expr(self, resty, expr)
    993             castvals = [self.context.cast(self.builder, val, fromty, resty.dtype)
--> 994                         for val, fromty in zip(itemvals, itemtys)]
    995             return self.context.build_list(self.builder, resty, castvals)

~\Anaconda3\lib\site-packages\numba\lowering.py in <listcomp>(.0)
    993             castvals = [self.context.cast(self.builder, val, fromty, resty.dtype)
--> 994                         for val, fromty in zip(itemvals, itemtys)]
    995             return self.context.build_list(self.builder, resty, castvals)

~\Anaconda3\lib\site-packages\numba\targets\base.py in cast(self, builder, val, fromty, toty)
    676             impl = self._casts.find((fromty, toty))
--> 677             return impl(self, builder, fromty, toty, val)
    678         except NotImplementedError:

~\Anaconda3\lib\site-packages\numba\targets\listobj.py in list_to_list(context, builder, fromty, toty, val)
   1089     # Casting from non-reflected to reflected
-> 1090     assert fromty.dtype == toty.dtype
   1091     return val

AssertionError: 

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-30-d0de78b978b7> in <module>()
----> 1 fj()

~\Anaconda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    365                     e.patch_message(''.join(e.args) + help_msg)
    366             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 367             raise e
    368 
    369     def inspect_llvm(self, signature=None):

~\Anaconda3\lib\site-packages\numba\dispatcher.py in _compile_for_args(self, *args, **kws)
    322                 argtypes.append(self.typeof_pyval(a))
    323         try:
--> 324             return self.compile(tuple(argtypes))
    325         except errors.TypingError as e:
    326             # Intercept typing error that may be due to an argument

~\Anaconda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~\Anaconda3\lib\site-packages\numba\dispatcher.py in compile(self, sig)
    653 
    654             self._cache_misses[sig] += 1
--> 655             cres = self._compiler.compile(args, return_type)
    656             self.add_overload(cres)
    657             self._cache.save_overload(sig, cres)

~\Anaconda3\lib\site-packages\numba\dispatcher.py in compile(self, args, return_type)
     80                                       args=args, return_type=return_type,
     81                                       flags=flags, locals=self.locals,
---> 82                                       pipeline_class=self.pipeline_class)
     83         # Check typing error if object mode is used
     84         if cres.typing_error is not None and not flags.enable_pyobject:

~\Anaconda3\lib\site-packages\numba\compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    902     pipeline = pipeline_class(typingctx, targetctx, library,
    903                               args, return_type, flags, locals)
--> 904     return pipeline.compile_extra(func)
    905 
    906 

~\Anaconda3\lib\site-packages\numba\compiler.py in compile_extra(self, func)
    365         self.lifted = ()
    366         self.lifted_from = None
--> 367         return self._compile_bytecode()
    368 
    369     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~\Anaconda3\lib\site-packages\numba\compiler.py in _compile_bytecode(self)
    833         """
    834         assert self.func_ir is None
--> 835         return self._compile_core()
    836 
    837     def _compile_ir(self):

~\Anaconda3\lib\site-packages\numba\compiler.py in _compile_core(self)
    820         self.define_pipelines(pm)
    821         pm.finalize()
--> 822         res = pm.run(self.status)
    823         if res is not None:
    824             # Early pipeline completion

~\Anaconda3\lib\site-packages\numba\compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~\Anaconda3\lib\site-packages\numba\compiler.py in run(self, status)
    251                     # No more fallback pipelines?
    252                     if is_final_pipeline:
--> 253                         raise patched_exception
    254                     # Go to next fallback pipeline
    255                     else:

~\Anaconda3\lib\site-packages\numba\compiler.py in run(self, status)
    242                 try:
    243                     event(stage_name)
--> 244                     stage()
    245                 except _EarlyPipelineCompletion as e:
    246                     return e.result

~\Anaconda3\lib\site-packages\numba\compiler.py in stage_nopython_backend(self)
    694         """
    695         lowerfn = self.backend_nopython_mode
--> 696         self._backend(lowerfn, objectmode=False)
    697 
    698     def stage_compile_interp_mode(self):

~\Anaconda3\lib\site-packages\numba\compiler.py in _backend(self, lowerfn, objectmode)
    644             self.library.enable_object_caching()
    645 
--> 646         lowered = lowerfn()
    647         signature = typing.signature(self.return_type, *self.args)
    648         self.cr = compile_result(

~\Anaconda3\lib\site-packages\numba\compiler.py in backend_nopython_mode(self)
    631                 self.return_type,
    632                 self.calltypes,
--> 633                 self.flags)
    634 
    635     def _backend(self, lowerfn, objectmode):

~\Anaconda3\lib\site-packages\numba\compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags)
   1021 
   1022     lower = lowering.Lower(targetctx, library, fndesc, interp)
-> 1023     lower.lower()
   1024     if not flags.no_cpython_wrapper:
   1025         lower.create_cpython_wrapper(flags.release_gil)

~\Anaconda3\lib\site-packages\numba\lowering.py in lower(self)
    171         if self.generator_info is None:
    172             self.genlower = None
--> 173             self.lower_normal_function(self.fndesc)
    174         else:
    175             self.genlower = self.GeneratorLower(self)

~\Anaconda3\lib\site-packages\numba\lowering.py in lower_normal_function(self, fndesc)
    212         # Init argument values
    213         self.extract_function_arguments()
--> 214         entry_block_tail = self.lower_function_body()
    215 
    216         # Close tail of entry block

~\Anaconda3\lib\site-packages\numba\lowering.py in lower_function_body(self)
    237             bb = self.blkmap[offset]
    238             self.builder.position_at_end(bb)
--> 239             self.lower_block(block)
    240 
    241         self.post_lower()

~\Anaconda3\lib\site-packages\numba\lowering.py in lower_block(self, block)
    252             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    253                                    loc=self.loc, errcls_=defaulterrcls):
--> 254                 self.lower_inst(inst)
    255 
    256     def create_cpython_wrapper(self, release_gil=False):

~\Anaconda3\lib\contextlib.py in __exit__(self, type, value, traceback)
     97                 value = type()
     98             try:
---> 99                 self.gen.throw(type, value, traceback)
    100             except StopIteration as exc:
    101                 # Suppress StopIteration *unless* it's the same exception that

~\Anaconda3\lib\site-packages\numba\errors.py in new_error_context(fmt_, *args, **kwargs)
    605         from numba import config
    606         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 607         six.reraise(type(newerr), newerr, tb)
    608 
    609 

~\Anaconda3\lib\site-packages\numba\six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660 
    661 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)


File "<ipython-input-29-a5afb679cd70>", line 3:
def fj():
    return np.array([[1, 2.1],[0,1]])
    ^

[1] During: lowering "$0.9 = build_list(items=[Var($0.5, <ipython-input-29-a5afb679cd70> (3)), Var($0.8, <ipython-input-29-a5afb679cd70> (3))])" at <ipython-input-29-a5afb679cd70> (3)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
```

If I explicitly supply the dtype, the same errors occur:

```python
@njit
def fj():
    return np.array([[1, 2.1],[0,1]], dtype=np.float64)
```
It works fine if at least one element in each sub-list is a float:

```python
@njit
def fj():
    return np.array([[1, 2.1],[0.,1]])
```
I expect this isn't the desired behavior.
user: ngharrison
issue_3708: state: open
title: Extend the use of `_OverloadFunctionTemplate::_validate_sigs` to other extending decorators
body: 
## Feature request

As title, e.g. `@overload_method` needs to also validate typing and implementation in a similar manner to `@overload`.
user: stuartarchibald
issue_3707: state: open
title: Error when accessing array from imported file
body: I am using numba from within a Jupyter notebook and encountered an error when I tried to access an array defined in a file. This is the first issue that I am reporting, so if there is anything I missed or anything else that would be helpful to you, do let me know.

```
python --version
Python 3.7.2

pipenv --version
pipenv, version 11.10.1

pip freeze | ag numba
numba==0.42.0

pip freeze | ag jupyter
jupyter==1.0.0
jupyter-client==5.2.4
jupyter-console==6.0.0
jupyter-core==4.4.0
```

Minimal example 
````
from numba import njit
from values import array
import values

@njit
def array_fail():
    values.array 

@njit
def array_success():
    array
````

where values.py is just:
````
import numpy as np
array = np.asarray([n for n in range(10)], dtype=np.int64)
````

where array_success() works fine but array_fail(), well as the name implies fails with:

````
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    616     try:
--> 617         yield
    618     except NumbaError as e:

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    258                                    loc=self.loc, errcls_=defaulterrcls):
--> 259                 self.lower_inst(inst)
    260 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower_inst(self, inst)
    307             ty = self.typeof(inst.target.name)
--> 308             val = self.lower_assign(ty, inst)
    309             self.storevar(val, inst.target.name)

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    453         elif isinstance(value, ir.Expr):
--> 454             return self.lower_expr(ty, value)
    455 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower_expr(self, resty, expr)
    972             else:
--> 973                 impl = self.context.get_getattr(ty, expr.attr)
    974                 attrty = self.context.typing_context.resolve_getattr(ty,

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/targets/base.py in get_getattr(self, typ, attr)
    585                 pyval = getattr(typ.pymod, attr)
--> 586                 llval = self.get_constant(attrty, pyval)
    587                 def imp(context, builder, typ, val, attr):

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/targets/base.py in get_constant(self, ty, val)
    509         # HACK: pass builder=None to preserve get_constant() API
--> 510         return self.get_constant_generic(None, ty, val)
    511 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/targets/base.py in get_constant_generic(self, builder, ty, val)
    499             impl = self._get_constants.find((ty,))
--> 500             return impl(self, builder, ty, val)
    501         except NotImplementedError:

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/targets/arrayobj.py in constant_record(context, builder, ty, pyval)
   2283     """
-> 2284     return context.make_constant_array(builder, ty, pyval)
   2285 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/targets/base.py in make_constant_array(self, builder, typ, ary)
   1013             consts = Constant.array(Type.int(8), bytearray(flat.data))
-> 1014             data = cgutils.global_constant(builder, ".const.array.data", consts)
   1015             # Ensure correct data alignment (issue #1933)

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/cgutils.py in global_constant(builder_or_module, name, value, linkage)
    856     else:
--> 857         module = builder_or_module.module
    858     data = module.add_global_variable(value.type, name=name)

AttributeError: 'NoneType' object has no attribute 'module'

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-17-b08c8874ea8a> in <module>
----> 1 array_fail()

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    365                     e.patch_message(''.join(e.args) + help_msg)
    366             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 367             raise e
    368 
    369     def inspect_llvm(self, signature=None):

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    322                 argtypes.append(self.typeof_pyval(a))
    323         try:
--> 324             return self.compile(tuple(argtypes))
    325         except errors.TypingError as e:
    326             # Intercept typing error that may be due to an argument

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, sig)
    653 
    654             self._cache_misses[sig] += 1
--> 655             cres = self._compiler.compile(args, return_type)
    656             self.add_overload(cres)
    657             self._cache.save_overload(sig, cres)

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     80                                       args=args, return_type=return_type,
     81                                       flags=flags, locals=self.locals,
---> 82                                       pipeline_class=self.pipeline_class)
     83         # Check typing error if object mode is used
     84         if cres.typing_error is not None and not flags.enable_pyobject:

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    924     pipeline = pipeline_class(typingctx, targetctx, library,
    925                               args, return_type, flags, locals)
--> 926     return pipeline.compile_extra(func)
    927 
    928 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in compile_extra(self, func)
    372         self.lifted = ()
    373         self.lifted_from = None
--> 374         return self._compile_bytecode()
    375 
    376     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in _compile_bytecode(self)
    855         """
    856         assert self.func_ir is None
--> 857         return self._compile_core()
    858 
    859     def _compile_ir(self):

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in _compile_core(self)
    842         self.define_pipelines(pm)
    843         pm.finalize()
--> 844         res = pm.run(self.status)
    845         if res is not None:
    846             # Early pipeline completion

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    253                     # No more fallback pipelines?
    254                     if is_final_pipeline:
--> 255                         raise patched_exception
    256                     # Go to next fallback pipeline
    257                     else:

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in run(self, status)
    244                 try:
    245                     event(stage_name)
--> 246                     stage()
    247                 except _EarlyPipelineCompletion as e:
    248                     return e.result

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in stage_nopython_backend(self)
    715         """
    716         lowerfn = self.backend_nopython_mode
--> 717         self._backend(lowerfn, objectmode=False)
    718 
    719     def stage_compile_interp_mode(self):

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    664             self.library.enable_object_caching()
    665 
--> 666         lowered = lowerfn()
    667         signature = typing.signature(self.return_type, *self.args)
    668         self.cr = compile_result(

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in backend_nopython_mode(self)
    651                 self.calltypes,
    652                 self.flags,
--> 653                 self.metadata)
    654 
    655     def _backend(self, lowerfn, objectmode):

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags, metadata)
   1046         lower = lowering.Lower(targetctx, library, fndesc, interp,
   1047                                metadata=metadata)
-> 1048         lower.lower()
   1049         if not flags.no_cpython_wrapper:
   1050             lower.create_cpython_wrapper(flags.release_gil)

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower(self)
    176         if self.generator_info is None:
    177             self.genlower = None
--> 178             self.lower_normal_function(self.fndesc)
    179         else:
    180             self.genlower = self.GeneratorLower(self)

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    217         # Init argument values
    218         self.extract_function_arguments()
--> 219         entry_block_tail = self.lower_function_body()
    220 
    221         # Close tail of entry block

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower_function_body(self)
    242             bb = self.blkmap[offset]
    243             self.builder.position_at_end(bb)
--> 244             self.lower_block(block)
    245 
    246         self.post_lower()

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/lowering.py in lower_block(self, block)
    257             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    258                                    loc=self.loc, errcls_=defaulterrcls):
--> 259                 self.lower_inst(inst)
    260 
    261     def create_cpython_wrapper(self, release_gil=False):

~/.pyenv/versions/3.7.2/lib/python3.7/contextlib.py in __exit__(self, type, value, traceback)
    128                 value = type()
    129             try:
--> 130                 self.gen.throw(type, value, traceback)
    131             except StopIteration as exc:
    132                 # Suppress StopIteration *unless* it's the same exception that

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    623         from numba import config
    624         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 625         six.reraise(type(newerr), newerr, tb)
    626 
    627 

~/.local/share/virtualenvs/poker-ai-zNaDkIqV/lib/python3.7/site-packages/numba/six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660 
    661 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
'NoneType' object has no attribute 'module'

File "<ipython-input-15-a4833f36ab2f>", line 6:
def array_fail():
    values.array 
    ^

[1] During: lowering "$0.2 = getattr(value=$0.1, attr=array)" at <ipython-input-15-a4833f36ab2f> (6)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!

````


user: cstich
issue_3689: state: open
title: Support np.lexsort
body: It would be nice to have a `nopython` compatible version of `np.lexsort` available. 
user: synapticarbors
labels: good second issue: A good issue for second time contributors
issue_3682: state: open
title: Expand ctypes documentation passing np.array with `.ctypes`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Following on from https://gitter.im/numba/numba?at=5c3f0e4095e17b45255da31f, document that `ctypes` bound functions can accept `np.ndarray` if a `dtype *` like argument type is required via the `.ctypes` attr on `ndarray`.
user: stuartarchibald
issue_3674: state: open
title: String Features
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
We had a discussion about string features that could be useful. Here are things I could find in some real workloads I have around:

- `hash(str_value)` (this is a blocking issue for many things)
- `int(str_value)`, `float(str_value)`
- `str_value.split(',')`
- `str_value.join(...)`
- regular expressions
- string methods: `str_value.upper()/lower()/isnumeric()/...`,

user: ehsantn
issue_3664: state: open
title: Trace var types in undefined lists for better error message
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

Following on from https://github.com/numba/numba/issues/3654, it should be possible to trace the vars in lists to determine if the reason it cannot be typed is that it is inhomogeneous in type. This can then be reported to the user in the error message (and appropriate documentation written and referenced).
user: stuartarchibald
issue_3656: state: open
title: Threading improvements in roadmap
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
The Numba roadmap ([here](http://numba.pydata.org/numba-doc/latest/developer/roadmap.html?highlight=roadmap)) doesn't include anything about the threading backend. I think we somehow just missed it. Example features to include:

- Exposing thread id
- Thread private variables
- Concurrent containers (e.g. from TBB or upcoming parallel STL)
- Scheduling policy
user: ehsantn
issue_3642: state: open
title: gdb launch potential race condition (safe, just undesirable)
body: 
## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

`numba.gdb()` relies on making the parent sleep whilst the child launches `gdb`, if the sleep isn't long enough (because of e.g. slow CPU/heavily loaded machine) then it's possible the parent wakes up before `gdb` has attached. Fix this!
user: stuartarchibald
issue_3641: state: open
title: trouble with Literal{T} & undefined local
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```python

In [2]: @njit
   ...: def foo(x):
   ...:     if x:
   ...:         y = 1
   ...:     return y
   ...:
   ...:

In [3]: foo(10)
Out[3]: 1

In [4]: foo(0)
Out[4]: 1
```

`y` is typed to be `LiteralInt(1)` so the function is always returning `1`.  Previously, this would return `0` if `x` evaluates to False.  


I'm not sure what to do about it.  It's like encountering an undefined behavior when `y` is not defined.
user: sklam
labels: bug - incorrect behavior: Bugs: incorrect behavior
bug - typing: Bugs: occuring at typing time
issue_3639: state: open
title: [Docs?] Numba creates multiple Python objects for an object returned more than once
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

If an object created in `nopython` is returned more than once from a function (in a tuple, say), Numba creates separate instances each time, ie the code below fails on the assertions.
```python
from numba import int64, jit, jitclass
from numpy import array

@jit(nopython=True)
def return_list_twice():
    the_list = [1, 2, 3]
    return the_list, the_list

@jit(nopython=True)
def return_array_twice():
    the_array = array([1, 2, 3])
    return the_array, the_array


@jitclass([('value', int64)])
class MyJitClass:
    def __init__(self):
        self.value = 42


@jit(nopython=True)
def return_jitclass_twice():
    the_class = MyJitClass()
    return the_class, the_class


list1, list2 = return_list_twice()
array1, array2 = return_array_twice()
class1, class2 = return_jitclass_twice()

assert list1 is list2
assert array1 is array2
assert class1 is class2
```
Not sure there is a use-case that really requires this, hence probably more of a documentation issue.

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->
 


user: asodeur
labels: good first issue: A good issue for a first time contributor
issue_3636: state: open
title: Add outdated warning to old docs.
body: ## Feature request

Following on from https://gitter.im/numba/numba?at=5c2a1cbbf6166a302799b1ae, work out if it's possible to add `This documentation is outdated, current Numba version is X.Y` or similar to the headers of all old docs.
user: stuartarchibald
issue_3634: state: open
title: kmeans list comprehension
body: Taking the kmeans numba implementation provided here https://github.com/numba/numba/tree/master/examples/k-means (only change being additional outputs returned and use if prange instead of range):

```
from numba import njit, prange

@njit(parallel=True)
def kmeans(A, numCenter, numIter, init_centroids):
    N = A.shape[0]
    D = A.shape[1]

    centroids = init_centroids

    for l in range(numIter):
        dist = np.array([[np.sqrt(np.sum((A[i, :] - centroids[j, :])**2))
                                for j in prange(numCenter)] for i in prange(N)])

        labels = np.array([dist[i, :].argmin() for i in prange(N)])
            
        centroids = np.array([[np.sum(A[labels == i, j])/np.sum(labels == i)
                                 for j in prange(D)] for i in prange(numCenter)])

    return centroids, dist, labels

centers = 6
init_centroids = np.random.ranf((centers, len(category_columns)))
array_form = np.array(rolling_category_profile_frame[category_columns])
centroids, distances, labels = kmeans(array_form, centers, 50, init_centroids)
```
I get the following error that claims this is an internal numba error.

```
LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
'$36.13'

File "<ipython-input-14-f5b70beab834>", line 12:
def kmeans(A, numCenter, numIter, init_centroids):
    <source elided>
        dist = np.array([[np.sqrt(np.sum((A[i, :] - centroids[j, :])**2))
                                for j in prange(numCenter)] for i in prange(N)])
                                ^

[1] During: lowering "$implicit0.793.1253 = getiter(value=$36.13)" at <ipython-input-14-f5b70beab834> (12)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.
```

I am using numba==0.41.0 with macOS Mojave Version 10.14.2 (18C54)
user: banalytics
issue_3632: state: open
title: Using CC cant use function defined in own module
body: ## Reporting a bug

When using CC to pre-compile code, I wanted to use a function defined in the module to do something in another function. This fails with saying the function is unknown. The same procedure works using jit even with nopython.

```
import numba
from numba.pycc import CC

cc = CC('calFast')
cc.verbose = True

@cc.export('suma', 'i4(i4,i4)')
def suma(a, b):
    return a+b

@cc.export('squareSum', 'i4(i4,i4)')
def squareSum(a,b):
    c = suma(a, b)
    return c**2

if __name__ == '__main__':
    cc.compile()
```

yields

```
...
...
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/typeinfer.py", line 1138, in typeof_assign
    self.typeof_global(inst, inst.target, value)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/typeinfer.py", line 1235, in typeof_global
    typ = self.resolve_value_type(inst, gvar.value)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numba/typeinfer.py", line 1159, in resolve_value_type
    raise TypingError(msg, loc=inst.loc)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'suma': cannot determine Numba type of <class 'function'>

File "numbaTest.py", line 13:
def squareSum(a,b):
    c = suma(a, b)
    ^

``
user: max3-2
issue_3602: state: open
title: unsupported keyword arguments when calling Function(<ufunc 'add'>)
body: When running the following code:

```
In [1]: import numpy as np                                                                                                                                                                    
In [2]: import numba                                                                                                                                                                          
In [3]: ls = np.linspace(0, 1000, 1000)                                                                                                                                                       
In [4]: @numba.jit(nopython=True, fastmath=True)  
   ...: def test():  
   ...:     np.add(ls, 1024, out=ls)  
```

I get an error:
`unsupported keyword arguments when calling Function(<ufunc 'add'>)`

Which may it is just a missing feature, but the error also says:
```
File "<ipython-input-5-71496563ec4b>", line 3:
def test(): 
    np.add(ls, 1024, out=ls) 
    ^

[1] During: lowering "$0.7 = call $0.2($0.3, $const0.4, func=$0.2, args=[Var($0.3, <ipython-input-5-71496563ec4b> (3)), Var($const0.4, <ipython-input-5-71496563ec4b> (3))], kws=[('out', Var($0.5, <ipython-input-5-71496563ec4b> (3)))], vararg=None)" at <ipython-input-5-71496563ec4b> (3)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.

Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new

If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba

Thanks in advance for your help in improving Numba!
```
So i complied :)
user: luciotorre
issue_3601: state: open
title: internal error, calling @vectorize'd code from parfors.
body: Friendly greetings !

I'm learning scipy and numba (since i discovered numba python kind of make sense now) so sorry about the mess.

1st : a notebook that do not give any error with parallel=False except that the code doesn't work as expected because of a silly mistake : https://gist.github.com/ker2x/3c2c1bb0060ceba59050af4f02236044

2nd : the same code with the silly mistake, but crash with an internal error with parallel=True : https://gist.github.com/ker2x/17cd0c643a7f09425b516622136798d7

3rd : the fixed code but with an internal error : https://gist.github.com/ker2x/911c993296e53d4d4a2fb788a872b3c1

4th :the fixed code but with a "normal" error if a comment @vectorize :  https://gist.github.com/ker2x/0888bac73d66949cd124decbaa1ea7bc

5th: fixed code that works if i set parallel=False : https://gist.github.com/ker2x/e7c223cb7a1cf4745dae63d4477f4d40


user: ker2x
issue_3599: state: open
title: Njitted permutations
body: Hello, I'm trying to get permutations from a list of integers:

```python
@numba.njit()
def permutations(A, k):
    r = [[]]
    for i in range(k):
        t=[]
        for next_num in A:
            for next_chain in r:            
                if next_num not in next_chain:
                    t.append([next_num,] + next_chain)
        r=t
    return r
permutations([1,2,3],3)
```

with numba decorator commented out, result is as expected:
[[1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1]]

Otherwise, it's giving me various errors which make no sense:
```

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Undefined variable 'next_chain', operation: $phi42.1, location: <ipython-input-113-8321626fa1fb> (7)

File "<ipython-input-113-8321626fa1fb>", line 7:
def permutations(A, k):
    <source elided>
        for next_num in A:
            for next_chain in r:

```
Please advise )

Python version: ['3.6.3 |Anaconda, Inc.| (default, Oct 15 2017, 03:27:45) [MSC v.1900 64 bit (AMD64)]'] 
platform: AMD64 
system: Windows-10-10.0.14393-SP0 
Numba version: 0.41.0
user: fingoldo
labels: bug - typing: Bugs: occuring at typing time
issue_3595: state: open
title: llvm.dbg.declare deprecation
body: Variable debug info is marked with `llvm.dbg.declare`, which is pending deprecation according to llvm docs.  A new `llvm.dbg.addr`  is available to replace the deprecated API.  The two API have the same interface so we can easily substitute the one API.  See https://reviews.llvm.org/D37768.

However, NVVM IR 1.5 doesn't support the new `llvm.dbg.addr` yet.  Otherwise, we could make the change right now.
user: sklam
labels: llvm: LLVM related issues
bug - DWARF: Bugs related to debugging support
issue_3593: state: open
title: Remove code duplication in cuda real hw vs simulator
body: There are two `devicearray.py` files for the cuda backend and there are several methods that are either duplicated or looks very similar.  We should consolidate the code to avoid repeating ourselves.  The first step may just be moving the duplicated code to a file that the real hw and simulator codepaths can share.  In the long term, we should also consider refactoring the interface to reduce the similar looking code.  
user: sklam
labels: CUDA: CUDA related issue/PR
issue_3588: state: open
title: Force compilation caching
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

I searched through the doc and past issues but couldn't find anything: is there a way to globally force compilation caching? E.g. with an instruction, or better with an environment variable?

My use-case is that I'm building a package, and I'd like the user to choose whether they want to cache the compilation (which takes about 10 seconds)

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: NicolasHug
labels: caching: Issue involving caching
issue_3582: state: open
title: Error when calling parallelized function from compiled function
body: While playing around with parallelization in numba using `numba.prange` I encountered the following error, which might be a bug. A self-contained example is

```python
from numba import njit, prange
import numpy as np

@njit(parallel=True)
def func_(arr, out):
    for i in prange(arr.size):
        out[i] = arr[i]
        
@njit
def func(arr, out=None):
    """ apply laplace operator to array `arr` """
    if out is None:
        out = np.empty_like(arr)
    func_(arr, out)
    return out

func(np.arange(3))
```

The resulting error is 
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-3-5c0fe7e83cab> in <module>()
     15     return out
     16 
---> 17 func(np.arange(3))

/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    346                 e.patch_message(msg)
    347 
--> 348             error_rewrite(e, 'typing')
    349         except errors.UnsupportedError as e:
    350             # Something unsupported is present in the user code, add help info

/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py in error_rewrite(e, issue_type)
    313                 raise e
    314             else:
--> 315                 reraise(type(e), e, None)
    316 
    317         argtypes = []

/srv/conda/lib/python3.6/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.typeinfer.CallConstraint object at 0x7f0dd4b1ba58>:
--%<----------------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/conda/lib/python3.6/site-packages/numba/errors.py", line 609, in new_error_context
    yield
  File "/srv/conda/lib/python3.6/site-packages/numba/lowering.py", line 259, in lower_block
    self.lower_inst(inst)
  File "/srv/conda/lib/python3.6/site-packages/numba/lowering.py", line 408, in lower_inst
    func(self, inst)
  File "/srv/conda/lib/python3.6/site-packages/numba/npyufunc/parfor.py", line 280, in _lower_parfor_parallel
    parfor.races)
  File "/srv/conda/lib/python3.6/site-packages/numba/npyufunc/parfor.py", line 1261, in call_parallel_gufunc
    builder.store(arg, ptr)
  File "/srv/conda/lib/python3.6/site-packages/llvmlite/ir/builder.py", line 704, in store
    % (value.type, ptr.type))
TypeError: cannot store {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i1} to {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i8}*: mismatching types

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/conda/lib/python3.6/site-packages/numba/typeinfer.py", line 141, in propagate
    constraint(typeinfer)
  File "/srv/conda/lib/python3.6/site-packages/numba/typeinfer.py", line 422, in __call__
    self.resolve(typeinfer, typevars, fnty)
  File "/srv/conda/lib/python3.6/site-packages/numba/typeinfer.py", line 446, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "/srv/conda/lib/python3.6/site-packages/numba/typeinfer.py", line 1231, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "/srv/conda/lib/python3.6/site-packages/numba/typing/context.py", line 190, in resolve_function_type
    res = self._resolve_user_function_type(func, args, kws)
  File "/srv/conda/lib/python3.6/site-packages/numba/typing/context.py", line 242, in _resolve_user_function_type
    return func.get_call_type(self, args, kws)
  File "/srv/conda/lib/python3.6/site-packages/numba/types/functions.py", line 280, in get_call_type
    template, pysig, args, kws = self.dispatcher.get_call_template(args, kws)
  File "/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py", line 272, in get_call_template
    self.compile(tuple(args))
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py", line 655, in compile
    cres = self._compiler.compile(args, return_type)
  File "/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py", line 82, in compile
    pipeline_class=self.pipeline_class)
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 926, in compile_extra
    return pipeline.compile_extra(func)
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 374, in compile_extra
    return self._compile_bytecode()
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 857, in _compile_bytecode
    return self._compile_core()
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 844, in _compile_core
    res = pm.run(self.status)
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 255, in run
    raise patched_exception
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 246, in run
    stage()
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 717, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 666, in _backend
    lowered = lowerfn()
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 653, in backend_nopython_mode
    self.metadata)
  File "/srv/conda/lib/python3.6/site-packages/numba/compiler.py", line 1048, in native_lowering_stage
    lower.lower()
  File "/srv/conda/lib/python3.6/site-packages/numba/lowering.py", line 178, in lower
    self.lower_normal_function(self.fndesc)
  File "/srv/conda/lib/python3.6/site-packages/numba/lowering.py", line 219, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/srv/conda/lib/python3.6/site-packages/numba/lowering.py", line 244, in lower_function_body
    self.lower_block(block)
  File "/srv/conda/lib/python3.6/site-packages/numba/lowering.py", line 259, in lower_block
    self.lower_inst(inst)
  File "/srv/conda/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/srv/conda/lib/python3.6/site-packages/numba/errors.py", line 617, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/srv/conda/lib/python3.6/site-packages/numba/six.py", line 659, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
cannot store {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i1} to {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i8}*: mismatching types

File "<ipython-input-3-5c0fe7e83cab>", line 6:
def func_(arr, out):
    for i in prange(arr.size):
    ^

[1] During: lowering "id=1[LoopNest(index_variable = parfor_index.47, range = (0, $2.3, 1))]{14: <ir.Block at <ipython-input-3-5c0fe7e83cab> (6)>}Var(parfor_index.47, <ipython-input-3-5c0fe7e83cab> (6))" at <ipython-input-3-5c0fe7e83cab> (6)
[2] During: resolving callee type: type(CPUDispatcher(<function func_ at 0x7f0dd4b806a8>))
[3] During: typing of call at <ipython-input-3-5c0fe7e83cab> (14)

--%<----------------------------------------------------------------------------


File "<ipython-input-3-5c0fe7e83cab>", line 14:
def func(arr, out=None):
    <source elided>
        out = np.empty_like(arr)
    func_(arr, out)
    ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.
[...]
```

Note that my intention was to write a function like the following
```python
@njit(parallel=True)
def func(arr, out=None):
    """ apply laplace operator to array `arr` """
    if out is None:
        out = np.empty_like(arr)
    for i in prange(arr.size):
        out[i] = arr[i]
    return out
```
which fails with a different error:

```
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
/srv/conda/lib/python3.6/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    608     try:
--> 609         yield
    610     except NumbaError as e:

/srv/conda/lib/python3.6/site-packages/numba/lowering.py in lower_block(self, block)
    258                                    loc=self.loc, errcls_=defaulterrcls):
--> 259                 self.lower_inst(inst)
    260 

/srv/conda/lib/python3.6/site-packages/numba/lowering.py in lower_inst(self, inst)
    407                 if isinstance(inst, _class):
--> 408                     func(self, inst)
    409                     return

/srv/conda/lib/python3.6/site-packages/numba/npyufunc/parfor.py in _lower_parfor_parallel(lowerer, parfor)
    279         index_var_typ,
--> 280         parfor.races)
    281     if config.DEBUG_ARRAY_OPT:

/srv/conda/lib/python3.6/site-packages/numba/npyufunc/parfor.py in call_parallel_gufunc(lowerer, cres, gu_signature, outer_sig, expr_args, expr_arg_types, loop_ranges, redvars, reddict, redarrdict, init_block, index_var_typ, races)
   1260                 ptr = cgutils.alloca_once(builder, typ)
-> 1261                 builder.store(arg, ptr)
   1262             else:

/srv/conda/lib/python3.6/site-packages/llvmlite/ir/builder.py in store(self, value, ptr, align)
    703             raise TypeError("cannot store %s to %s: mismatching types"
--> 704                             % (value.type, ptr.type))
    705         st = instructions.StoreInstr(self.block, value, ptr)

TypeError: cannot store {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i1} to {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i8}*: mismatching types

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-6-476298123cdd> in <module>()
      7         out[i] = arr[i]
      8     return out
----> 9 func(np.arange(3))

/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    365                     e.patch_message(''.join(e.args) + help_msg)
    366             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 367             raise e
    368 
    369     def inspect_llvm(self, signature=None):

/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    322                 argtypes.append(self.typeof_pyval(a))
    323         try:
--> 324             return self.compile(tuple(argtypes))
    325         except errors.TypingError as e:
    326             # Intercept typing error that may be due to an argument

/srv/conda/lib/python3.6/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, sig)
    653 
    654             self._cache_misses[sig] += 1
--> 655             cres = self._compiler.compile(args, return_type)
    656             self.add_overload(cres)
    657             self._cache.save_overload(sig, cres)

/srv/conda/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     80                                       args=args, return_type=return_type,
     81                                       flags=flags, locals=self.locals,
---> 82                                       pipeline_class=self.pipeline_class)
     83         # Check typing error if object mode is used
     84         if cres.typing_error is not None and not flags.enable_pyobject:

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    924     pipeline = pipeline_class(typingctx, targetctx, library,
    925                               args, return_type, flags, locals)
--> 926     return pipeline.compile_extra(func)
    927 
    928 

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in compile_extra(self, func)
    372         self.lifted = ()
    373         self.lifted_from = None
--> 374         return self._compile_bytecode()
    375 
    376     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in _compile_bytecode(self)
    855         """
    856         assert self.func_ir is None
--> 857         return self._compile_core()
    858 
    859     def _compile_ir(self):

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in _compile_core(self)
    842         self.define_pipelines(pm)
    843         pm.finalize()
--> 844         res = pm.run(self.status)
    845         if res is not None:
    846             # Early pipeline completion

/srv/conda/lib/python3.6/site-packages/numba/compiler_lock.py in _acquire_compile_lock(*args, **kwargs)
     30         def _acquire_compile_lock(*args, **kwargs):
     31             with self:
---> 32                 return func(*args, **kwargs)
     33         return _acquire_compile_lock
     34 

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in run(self, status)
    253                     # No more fallback pipelines?
    254                     if is_final_pipeline:
--> 255                         raise patched_exception
    256                     # Go to next fallback pipeline
    257                     else:

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in run(self, status)
    244                 try:
    245                     event(stage_name)
--> 246                     stage()
    247                 except _EarlyPipelineCompletion as e:
    248                     return e.result

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in stage_nopython_backend(self)
    715         """
    716         lowerfn = self.backend_nopython_mode
--> 717         self._backend(lowerfn, objectmode=False)
    718 
    719     def stage_compile_interp_mode(self):

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    664             self.library.enable_object_caching()
    665 
--> 666         lowered = lowerfn()
    667         signature = typing.signature(self.return_type, *self.args)
    668         self.cr = compile_result(

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in backend_nopython_mode(self)
    651                 self.calltypes,
    652                 self.flags,
--> 653                 self.metadata)
    654 
    655     def _backend(self, lowerfn, objectmode):

/srv/conda/lib/python3.6/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags, metadata)
   1046         lower = lowering.Lower(targetctx, library, fndesc, interp,
   1047                                metadata=metadata)
-> 1048         lower.lower()
   1049         if not flags.no_cpython_wrapper:
   1050             lower.create_cpython_wrapper(flags.release_gil)

/srv/conda/lib/python3.6/site-packages/numba/lowering.py in lower(self)
    176         if self.generator_info is None:
    177             self.genlower = None
--> 178             self.lower_normal_function(self.fndesc)
    179         else:
    180             self.genlower = self.GeneratorLower(self)

/srv/conda/lib/python3.6/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    217         # Init argument values
    218         self.extract_function_arguments()
--> 219         entry_block_tail = self.lower_function_body()
    220 
    221         # Close tail of entry block

/srv/conda/lib/python3.6/site-packages/numba/lowering.py in lower_function_body(self)
    242             bb = self.blkmap[offset]
    243             self.builder.position_at_end(bb)
--> 244             self.lower_block(block)
    245 
    246         self.post_lower()

/srv/conda/lib/python3.6/site-packages/numba/lowering.py in lower_block(self, block)
    257             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    258                                    loc=self.loc, errcls_=defaulterrcls):
--> 259                 self.lower_inst(inst)
    260 
    261     def create_cpython_wrapper(self, release_gil=False):

/srv/conda/lib/python3.6/contextlib.py in __exit__(self, type, value, traceback)
     97                 value = type()
     98             try:
---> 99                 self.gen.throw(type, value, traceback)
    100             except StopIteration as exc:
    101                 # Suppress StopIteration *unless* it's the same exception that

/srv/conda/lib/python3.6/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    615         from numba import config
    616         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 617         six.reraise(type(newerr), newerr, tb)
    618 
    619 

/srv/conda/lib/python3.6/site-packages/numba/six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660 
    661 else:

LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
cannot store {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i1} to {{i8*, i8*, i64, i64, i64*, [1 x i64], [1 x i64]}, i8}*: mismatching types

File "<ipython-input-6-476298123cdd>", line 6:
def func(arr, out=None):
    <source elided>
        out = np.empty_like(arr)
    for i in prange(arr.size):
    ^

[1] During: lowering "id=2[LoopNest(index_variable = parfor_index.92, range = (0, $20.3, 1))]{32: <ir.Block at <ipython-input-6-476298123cdd> (6)>}Var(parfor_index.92, <ipython-input-6-476298123cdd> (6))" at <ipython-input-6-476298123cdd> (6)
[...]
```
user: david-zwicker
labels: bug - ice: Bugs: internal compiler error
issue_3579: state: open
title: Typing empty list across branches breaks array ctor
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the ~latest released~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This breaks as type inference decides that `x` is a `list(list(int64))` but the `if z` branch does not execute if `z` is zero, `x` then arrives at the array constructor as an effectively empty `list` and an `IndexError: getitem out of range` is raised (presumably from indexing `x[0]` of an empty list). A workaround is in the code below and commented out, this adds an empty list to `x` to create data that is expected by the compiled code.
```python
from numba import njit
import numpy as np

@njit
def foo(z):
    x = []
    if z:
        x.append([10])
    #if len(x) == 0:
        #x.append([_ for _ in range(0)])
    return np.array(x)

print(foo(0))
print(foo(1))
```
See https://gitter.im/numba/numba?at=5c0ea29580986419d56d350d for context.
user: stuartarchibald
labels: bug - typing: Bugs: occuring at typing time
issue_3573: state: open
title: Incorrect LoweringError when assigning to complex128 .imag
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I believe the `.imag` and `.real` attributes are incorrectly identified as complex, leading to a `LoweringError` when assigning to these attributes with a real array.

    c = np.zeros((100, 4), dtype=np.complex128)
    @numba.jit(nopython=True)
    def sum_real_imag(c):
        c.imag += c.real
    sum_real_imag(c)

Results in a `LoweringError`:
`No definition for lowering array(complex128, 2d, C).imag = array(float64, 2d, A)`

In object mode or without numba, there's no error. Likewise if `tmp = c.imag` is used in the assignment instead of `c.imag`.

I found this when using complex types for packing two related values. My apologies if this is expected behavior.
user: asarnow
labels: bug - typing: Bugs: occuring at typing time
issue_3571: state: open
title: DeviceNDArray needs to expose 'contiguous' and/or 'c_contiguous' flag as property(s) on flagsobj
body: The 'DeviceNDArray' object has methods for checking whether the array is c-contiguous or f-contiguous, however, its `flags` object does not seem to follow the same semantics as numpy or cupy, where the properties of the underlying dict can be referenced as (lower-cased) properties on the `flags` object itself. 

According to the latest documentation (0.41.0 as of writing this), the `contiguous` property is supported on the `flags` object in Numba arrays [1]. This does not appear to be the case with `DeviceNDArray`

I get the following error when attempting to call `flags.contiguous` on a `DeviceNDArray` object:

```python
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'dict' object has no attribute 'contiguous'
```

[1] https://numba.pydata.org/numba-doc/latest/reference/numpysupported.html#the-flags-object
user: cjnolet
labels: CUDA: CUDA related issue/PR
issue_3569: state: open
title: Fortran array signature does not accept array that is both F and C contiguous
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

I'm not sure if that is a bug or a feature, but passing a 2D array that is both Fortran and C contiguous will fail if the signature expected a Fortran-aligned array:

```python
from numba import jitclass, uint8
import numpy as np

@jitclass([
    ('X', uint8[::1, :]),  # fortran aligned array
])
class Class:
    def __init__(self, X):
        self.X = X

# F contiguous, not C contiguous
X = np.arange(10).reshape(2, 5).astype(np.uint8)
X = np.asfortranarray(X)
assert not X.flags['C_CONTIGUOUS']
assert X.flags['F_CONTIGUOUS']
Class(X)  # OK

X = np.arange(10).reshape(10, 1).astype(np.uint8)
assert X.flags['C_CONTIGUOUS']
assert X.flags['F_CONTIGUOUS']
Class(X)  # fails
```

<details>

```
Traceback (most recent call last):
  File "numba_lol.py", line 21, in <module>
    Class(X)  # fails
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/jitclass/base.py", line 123, in __call__
    return cls._ctor(*args, **kwargs)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/dispatcher.py", line 348, in _compile_for_args
    error_rewrite(e, 'typing')
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/dispatcher.py", line 315, in error_rewrite
    reraise(type(e), e, None)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/six.py", line 658, in reraise
    raise value.with_traceback(tb)
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.typeinfer.CallConstraint object at 0x7fe5fa702160>:
--%<----------------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/errors.py", line 599, in new_error_context
    yield
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/lowering.py", line 254, in lower_block
    self.lower_inst(inst)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/lowering.py", line 393, in lower_inst
    signature.args[1])
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/targets/base.py", line 677, in cast
    return impl(self, builder, fromty, toty, val)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/targets/arrayobj.py", line 4673, in array_to_array
    assert fromty.mutable != toty.mutable or toty.layout == 'A'
AssertionError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/typeinfer.py", line 142, in propagate
    constraint(typeinfer)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/typeinfer.py", line 423, in __call__
    self.resolve(typeinfer, typevars, fnty)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/typeinfer.py", line 450, in resolve
    literals=literals)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/typeinfer.py", line 1173, in resolve_call
    literals=literals)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/typing/context.py", line 211, in resolve_function_type
    return func.get_call_type_with_literals(self, args, kws, literals)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/types/abstract.py", line 268, in get_call_type_with_literals
    return self.get_call_type(context, args, kws)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/types/misc.py", line 375, in get_call_type
    return self.ctor_template(context).apply(args, kws)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/typing/templates.py", line 207, in apply
    sig = generic(args, kws)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/jitclass/base.py", line 240, in generic
    sig = disp_type.get_call_type(self.context, boundargs, kws)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/types/functions.py", line 258, in get_call_type
    template, pysig, args, kws = self.dispatcher.get_call_template(args, kws)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/dispatcher.py", line 272, in get_call_template
    self.compile(tuple(args))
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/dispatcher.py", line 655, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/dispatcher.py", line 82, in compile
    pipeline_class=self.pipeline_class)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 904, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 367, in compile_extra
    return self._compile_bytecode()
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 835, in _compile_bytecode
    return self._compile_core()
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 822, in _compile_core
    res = pm.run(self.status)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 253, in run
    raise patched_exception
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 244, in run
    stage()
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 696, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 646, in _backend
    lowered = lowerfn()
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 633, in backend_nopython_mode
    self.flags)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/compiler.py", line 1023, in native_lowering_stage
    lower.lower()
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/lowering.py", line 173, in lower
    self.lower_normal_function(self.fndesc)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/lowering.py", line 214, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/lowering.py", line 239, in lower_function_body
    self.lower_block(block)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/lowering.py", line 254, in lower_block
    self.lower_inst(inst)
  File "/usr/lib64/python3.7/contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/errors.py", line 607, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/home/nico/.virtualenvs/pygbm/lib/python3.7/site-packages/numba/six.py", line 659, in reraise
    raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)


File "numba_lol.py", line 9:
    def __init__(self, X):
        self.X = X
        ^

[1] During: lowering "(self).X = X" at numba_lol.py (9)
[2] During: resolving callee type: jitclass.Class#55644369be18<X:array(uint8, 2d, F)>
[3] During: typing of call at <string> (3)

--%<----------------------------------------------------------------------------


```
</details>
user: NicolasHug
issue_3562: state: open
title: itertools support
body: ## Feature request

It would be nice to have support for itertools, e.g. product:
I am trying to do following code with some constraints:
temp = itertools.product(range(4), repeat=50)
If the work could be split equally to each cuda thread, and each thread could check those constraints, it could save the desired combinations to a file, having a thread ID as a combination prefix
user: cristipurdel
issue_3553: state: open
title: CUDA device->host transfer with non-contiguous arrays overwrites adjacent elements
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

CUDA device->host transfers using `DeviceNDArrayBase.copy_to_host` do not require memory contiguity (unlike host->device and device->device transfers using `DeviceNDArrayBase.copy_to_device`). This results in the following behavior:
```python
>>> import numpy as np
>>> from numba import cuda
>>> arr = np.arange(12).reshape((3, 4))
>>> arr
array([[ 0,  1,  2,  3],
       [ 4,  5,  6,  7],
       [ 8,  9, 10, 11]])
>>> darr = cuda.to_device(arr)
>>> darr[1:, 2:].copy_to_host(arr[:2, :2])
array([[ 6,  7],
       [10, 11]])
>>> arr
array([[ 6,  7,  8,  9],
       [10, 11,  6,  7],
       [ 8,  9, 10, 11]])
```
The point is that `arr[:1, 2:]`, which used to read `array([[2, 3]])`, was overwritten and now reads `array([[8, 9]])`, even though these elements were not part of the source and target slices for the copy. The reason is of course that they lie between the non-contiguous sections of memory that hold these slices, and `copy_to_host` just copies all the data between the first and last element.

Is this the expected behavior?

If not, would it be a good idea to add the same contiguity check to `copy_to_host` that is used in `copy_to_device`, by means of `sentry_contiguous`? It would be a trivial addition to #3552 in terms of business logic, but many array indexing tests would have to be rethought and rewritten.
user: danielwe
labels: CUDA: CUDA related issue/PR
bug - incorrect behavior: Bugs: incorrect behavior
issue_3548: state: open
title: Performance regression from 0.38 to 0.41
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

-->

I am experiencing a performance regression after updating numba from version `0.38.1` to version `0.41.0`.
This simple function that expect two 3-element lists of `float` that are unit vector (sum to 1) as arguments is running in 2.57 microseconds with version `0.38.1` on my machine (timed with timeit and  `a = [2/9, 3/9, 4/9]; b = [3/9, 5/9, 1/9]`). CHanging nothing except updated numba to `0.41`, the same function times at 12 microseconds. The function is given below.

I call this function millions of times in a pipeline, passing it different values. I profiled the code for both versions of numba and can observe a clear difference. In the most recent version a call to `typeof` is triggered and takes most of the processing time. I attached the profiling files and visualization screenshots.

The function:
```
from math import sqrt
from numba import njit

@njit(cache=True)
def get_angle_unitvec_approx(a, b):
    """
    source:
    https://web.archive.org/web/20161223122122/http://http.developer.nvidia.com:80/Cg/acos.html
    Computes angle between two 3d vectors in radians, Function optimized for acos computation
    :param a: 3-element list representing a unit vector
    :param b: 3-element list representing a unit vector
    :return: angle in rad
    """
    x = a[0] * b[0] + a[1] * b[1] + a[2] * b[2]
    negate = x < 0  # True or False (1 or 0)
    x = abs(x)
    if x > 1:
        x = 1
    ret = -0.0187293
    ret *= x
    ret += 0.0742610
    ret *= x
    ret -= 0.2121144
    ret *= x
    ret += 1.5707288
    ret *= sqrt(1.0 - x)
    ret -= 2 * negate * ret
    return negate * 3.14159265358979 + ret
```

[profile-numba-0-41-on-2018-11-29_10_29_16.txt](https://github.com/numba/numba/files/2630043/profile-numba-0-41-on-2018-11-29_10_29_16.txt)
[profile-numba-0-38-on-2018-11-29_10_26_53.txt](https://github.com/numba/numba/files/2630044/profile-numba-0-38-on-2018-11-29_10_26_53.txt)
![vizu_0 41](https://user-images.githubusercontent.com/18263140/49237719-d065a380-f3cc-11e8-8543-440a1ff2abd6.PNG)
![vizu_0 38](https://user-images.githubusercontent.com/18263140/49237720-d065a380-f3cc-11e8-9183-d5bb9af568fe.PNG)



user: Eskapp
labels: performance - compile time: Performance issue occurring at compile time.
issue_3533: state: open
title: merging signatures and layout in guvectorized decorator
body: ## Feature request

You know better than me how cumbersome the decorator for guvectorized can be, i.e.:
```
@guvectorize([(float32[:,:], float32[:,:,:], float32[:,:])],  '(n,d), (k,n,d) -> (n,k)', target='parallel')
def cosine_similarity(D1, D2, C):
```

So I started to write it in a more intuitive way:

```
@guvectorize([(float32[:,:], float32[:,:,:], float32[:,:])],
                     '(n,d),        (k,n,d)   ->    (n,k)', target='parallel')
def cosine_similarity(D1, D2, C):
```

where the sizes are matched with the square brackets. A feature that would be very nice is to merge the `signatures` and `layout` parameters in a single parameters, something like this:

```
@guvectorize(["(float32[n,d], float32[k,n,d], float32[n,k])"], target='parallel')
def cosine_similarity(D1, D2, C):
```

The only difference is the style, but now it is way more readable. how hard it is to implement?
user: lpuglia
issue_3524: state: open
title: yield + for issue
body: ## Reporting a bug

- [+] I am using the latest released version of Numba '0.41.0dev0+474.ge74336755'
- [+] I have included below a minimal working reproducer

```
from numba import njit
import numpy as np
@njit
def f():
    a = iter(np.array([1,2,3]))
    for x in a:
        yield x
    for x in a:
        yield x
print(list(f()))
```
prints [1, 2, 3, 2, 3]
while
```
from numba import njit
import numpy as np
@njit
def f():
    a = iter(np.array([1,2,3]))
    for x in a:
        print(x)
    for x in a:
        print(x)
f()
```
prints 1 2 3 as expected.
user: axil
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_3515: state: open
title: array comprehension expects iterator to be range like
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

This fails typing
```python
from numba import njit
import numpy as np
@njit
def foo(a):
    return np.array([1 for i in np.nditer(a)])
foo(np.zeros((10,)))
```
with
```
Invalid use of Function(<intrinsic range_iter_len>) with argument(s) of type(s): (nditer(ndim=1, layout=C, inputs=(array(float64, 1d, C),)))
```
seems like the array comprehension code expects the iterator to be range like, if this transform is switched off the code runs fine. Another example is here: https://gitter.im/numba/numba?at=5bf1abf61ad4155d3ae50543
user: stuartarchibald
issue_3501: state: open
title: Caching fails for function created by `exec`
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).
- Detailed version info:
    - Python: 2.7.14 |Anaconda, Inc.| (default, Dec  7 2017, 17:05:42) [GCC 7.2.0]
    - Numba: 0.41.0dev0+176.gb6fcc8c.dirty

## Feature request
A function defined by `exec`-ing a string in `locals()` can be jit-compiled but cannot be cached. The heart of the exception raised appears to be:
```
RuntimeError: cannot cache function 'f': no locator available for file '<string>'
```

## Minimal reproducer
```python
def genfunc():
    func_str = """def f(x):
        return x**2
    """
    exec func_str in locals()
    return f

# works
f = genfunc()
f(2)

# works
nf_nocache = numba.njit(cache=False)(f)
nf_nocache(2)

# fails
nf_cache = numba.njit(cache=True)(f)
nf_cache(2)
```

## Full traceback
The exception text raised on the last call of the above gives the following traceback:
```
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-24-9beca422d7bc> in <module>()
     19 
     20 # fails
---> 21 nf_cache = numba.njit(cache=True)(f)
     22 nf_cache(2)

/home/justin/anaconda2/lib/python2.7/site-packages/numba/decorators.pyc in wrapper(func)
    189                           **dispatcher_args)
    190         if cache:
--> 191             disp.enable_caching()
    192         if sigs is not None:
    193             # Register the Dispatcher to the type inference mechanism,

/home/justin/anaconda2/lib/python2.7/site-packages/numba/dispatcher.pyc in enable_caching(self)
    564 
    565     def enable_caching(self):
--> 566         self._cache = FunctionCache(self.py_func)
    567 
    568     def __get__(self, obj, objtype=None):

/home/justin/anaconda2/lib/python2.7/site-packages/numba/caching.pyc in __init__(self, py_func)
    612     def __init__(self, py_func):
    613         self._name = repr(py_func)
--> 614         self._impl = self._impl_class(py_func)
    615         self._cache_path = self._impl.locator.get_cache_path()
    616         # This may be a bit strict but avoids us maintaining a magic number

/home/justin/anaconda2/lib/python2.7/site-packages/numba/caching.pyc in __init__(self, py_func)
    347         else:
    348             raise RuntimeError("cannot cache function %r: no locator available "
--> 349                                "for file %r" % (qualname, source_path))
    350         self._locator = locator
    351         # Use filename base name as module name to avoid conflict between

RuntimeError: cannot cache function 'f': no locator available for file '<string>'
```
user: jllanfranchi
labels: caching: Issue involving caching
issue_3494: state: open
title: Review usage of use_literal_type and ir.Const
body: See https://github.com/numba/numba/pull/3414#discussion_r233195357 and https://github.com/numba/numba/pull/3414/files#diff-e38d089fb4040665c50c206e57e281d9R656
user: sklam
issue_3492: state: open
title: in lowering, cast is not handling refct
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

All implementation and all usage of `cast` is not handling refct at all.  Future datatypes may require that.  We need to figure out a way to change it.

The issue is first noticed in https://github.com/numba/numba/pull/3414 when attempting to add a cast for LiteralStr->unicode_type with a NRT allocated buffer for the latter.  The problem is mitigated by using a module-level constant for the data buffer.
user: sklam
issue_3490: state: open
title: ARMv7l `np.trace` test failing
body: ## Reporting a bug
- [X] I am using the ~latest released~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).

The test `numba.tests.test_linalg.TestTrace.test_trace` is failing for complex inputs, <=NumPy 1.13 on armv7l, suspect it's the alignment issue fixed in NumPy 1.15 https://github.com/scipy/scipy/issues/8638#issuecomment-385394757 OR https://github.com/numba/numba/pull/2950.
user: stuartarchibald
labels: ISA: ARM: Issue related to ARM ISA
issue_3485: state: open
title: Implement mode “wrap” for numba.stencil
body: ## Feature request
Currently, even though [`numba.stencil`](https://numba.pydata.org/numba-doc/latest/user/stencil.html) is designed in a way that allows different “modes”, it only supports one:

> ### 1.11.4.2. mode
> The optional mode parameter controls how the border of the output array is handled. Currently, there is only one supported value, `"constant"`.
> 
> — https://numba.pydata.org/numba-doc/latest/user/stencil.html#mode

However, other options would certainly be useful. In my case, when dealing with differential equations with periodic boundary conditions, `numba.stencil` in its current form unfortunately can’t be used. If a mode `'wrap'` were implemented, where array accesses outside the valid range would be taken modulo the length of the relevant array dimension, `numba.stencil` could also handle periodic boundary conditions.

For completeness, perhaps it is worth to draw inspiration from `scipy.ndimage` (e. g. [`scipy.ndimage.laplace`](https://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.laplace.html), [`scipy.ndimage.convolve`](https://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.convolve.html)) for consistency (considering the identical naming and functionality of `cval`, perhaps this is already on the radar?):

> **`'reflect'` (d c b a | a b c d | d c b a)** 
> The input is extended by reflecting about the edge of the last pixel.
> 
> **`'constant'` (k k k k | a b c d | k k k k)** 
> The input is extended by filling all values beyond the edge with the same constant value, defined by the cval parameter.
> 
> **`'nearest'` (a a a a | a b c d | d d d d)** 
> The input is extended by replicating the last pixel.
> 
> **`'mirror'` (d c b | a b c d | c b a)** 
> The input is extended by reflecting about the center of the last pixel.
> 
> **`'wrap'` (a b c d | a b c d | a b c d)**
> The input is extended by wrapping around to the opposite edge.
user: Socob
issue_3483: state: open
title: `cuda.to_device` ignore current context
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

When doing `cuda.to_device(a_dev_ary)` and `a_dev_ary` is a device array, `.to_device` just returns `a_dev_ary`.  When the currently active context is not the same as where `a_dev_ary` is allocated, user expects a copy from the source context to the current context.
user: sklam
issue_3482: state: open
title: Getting PTXAS info from cuda kernel
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

It is useful to expose the ptxas info log from compiled cuda kernel; i.e.
https://gist.github.com/sklam/0e750e0dea7571c68e94d99006ae8533
user: sklam
labels: CUDA: CUDA related issue/PR
issue_3475: state: open
title: Flushing STDOUT in nopython mode
body: ## Feature request

I put some `print()`s into my `nopython` mode code, so that I can tell how quickly it's progressing. However, I've found that it tends to run without printing and then print all the output at the end, presumably because STDOUT is not being flushed.

It seems that neither `print(flush=True)` nor `sys.stdout.flush()` is supported in `nopython` mode, so, assuming I am right about flushing being the issue, I would like to request an option to flush it.

(Note: I can't actually get this behaviour to happen in a minimal example, but it does happen in my real code. If I manage to construct an example where it happens, I'll post it here.)
user: nathanielvirgo
issue_3472: state: open
title: List comprehension in jit function will not trigger undefined variable errors
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [X] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

It looks like using a list comprehension inside a `jit` or `njit` function will compile correctly even if we're using some undefined variables.

```python
from numba import njit, jit


@jit  # same with njit
def f():

    [i for i in range(10)]  # get expected error if this is removed

    hey  # not defined, should fail
    how_is_it
    going
    
f()
```
user: NicolasHug
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_3471: state: open
title: Document NUMBA_CACHE_DIR 
body: Reference: https://github.com/numba/numba/issues/3470#issuecomment-435943781
user: sklam
labels: good first issue: A good issue for a first time contributor
caching: Issue involving caching
issue_3469: state: open
title: Scalars raise typing errors for ndenumerate, reshape, transpose, min, etc.
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Sorry if this was reported elsewhere or dismissed as something that numba will not support, but I tried searching and couldn't find anything general on this (only some related issues such as #846, #1825).

Basically, numpy will cast scalars to zero-dimensional arrays, while numba will throw a typing error for a few of its functions. Here are a few examples of how this bug manifests:

```python
@njit
def f():
    return list(np.ndenumerate(1))
f()
```

```python
@njit
def f():
    return np.reshape(1, (1,))
f()
```

```python
@njit
def f():
    return np.transpose(1)
f()
```

```python
@njit
def f():
    return np.min(1)
f()
```

```python
@njit
def f():
    return np.max(1)
f()
```

There are likely a few more instances (`sum`, `prod`, `argmin`, `argmax`, `median`), although I did check the list of supported methods somewhat thoroughly. Each case produces the same error:
```
Invalid usage of Function(<class '...'>) with parameters (int64)
```
and, in all cases, removing the `@njit` decorator gives a reasonable result, as does replacing the scalar with a 1-d array.

To motivate why this can matter, a user might call `np.clip(a, a_min=0, a_max=1)` to clip a scalar value for `a`. And a numba implementation of `np.clip` (#3468) might use `np.ndenumerate(a)` which would then run into this corner case. It seems unusual to handle this case within the `np.clip` implementation. But more to the point this is inconsistent with numpy, when I presume one of the goals is for existing `numpy` code to work with `numba` off-the-shelf.
user: arvoelke
issue_3464: state: open
title: Isolated and unloadable execution engine of jit code
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

@saulshanabrook , @pearu

After further discussion on this topic with @seibert, I think it's possible to create an isolated and unloadable execution engine of jit code to limit memory consumption and for better cleanup.  Right now, a numba jitted function already contains all the LLVM-IR for standalone execution.  It's technically possible to copy that IR into another LLVM Execution Engine for execution.  We don't need to create a function-type for the resulting function as it cannot be reused into another jit function.  So, we avoid the problem that the function-type is referencing the emitted code memory forever.

In a more concrete description:

* Allow a numba Dispatcher object to export a loadable LLVM-IR in another numba-enabled environment.  ("numba-enabled" means numba runtime services are available; i.e. python-to-numba dispatcher, memory management)
* Provide a wrapper for a new and isolated ExecutionEngine to run the numba emitted LLVM-IR.
* Freeing the ExecutionEngine will free all memory due to the jitted-function.





user: sklam
issue_3458: state: open
title: Add documentation FAQ entry about `.nv` cache directory
body: Based on this post:

https://groups.google.com/a/continuum.io/d/msg/numba-users/DcWYd7IR5HE/MtzPSIzcAQAJ

It sounds like there are situations where PTX that has been JIT compiled by the CUDA driver has been cached to `$HOME/.nv` (on Linux anyway) and can cause linker problems with Numba.  We should add an entry about this to the FAQ, and possibly even detect this error and linux to the FAQ.

For more information about the CUDA JIT cache (not to be confused with the caching Numba does on the CPU), see this NVIDIA blog post:

https://devblogs.nvidia.com/cuda-pro-tip-understand-fat-binaries-jit-caching/
user: seibert
labels: CUDA: CUDA related issue/PR
issue_3456: state: open
title: Support `numpy.tile`
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Add support for `numpy.tile`
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_3451: state: open
title: Nested Jitclass Generator Memory Leak
body: There seems to be a memory leak caused when using njit compiled generators from njit compiled functions, when the generator is used to iterate through some Jitclass based linked list (which contain a different JitClass).

It's a bit specific/complicated written out like that, but it's basically just a generator to iterate through the contents of a linked list.


```
import numba as nb
import numpy as np
from collections import OrderedDict
import threading
import matplotlib.pyplot as plt
from psutil import Process
import time


node1_type = nb.deferred_type()
node1_spec = OrderedDict()
node1_spec["par1"] = nb.int32
node1_spec["next"] = nb.optional(node1_type)

@nb.jitclass(node1_spec)
class Node1:
    def __init__(self, par1, next):
        self.par1 = par1
        self.next = next
node1_type.define(Node1.class_type.instance_type)


node2_type = nb.deferred_type()
node2_spec = OrderedDict()
node2_spec["node1_holder"] = Node1.class_type.instance_type
node2_spec["next"] = nb.optional(node2_type)

@nb.jitclass(node2_spec)
class Node2:
    def __init__(self, node1_holder, next):
        self.node1_holder = node1_holder
        self.next = next
node2_type.define(Node2.class_type.instance_type)


@nb.njit
def node2_iterator(node2):
    while not node2 is None:
        yield node2.node1_holder
        node2 = node2.next

@nb.njit
def using_iterator(node2):
    for cur_node in node2_iterator(node2):
        cur_node.par1 += 1

def tester(num_nodes=1000, num_iterations=100, num_times=100):
    for i in range(num_times):
        prev_holder = None
        for j in range(num_nodes):
            prev_holder = Node2(Node1(j, None), prev_holder)

        for j in range(num_iterations):
            using_iterator(prev_holder)



if __name__ == "__main__":
    th = threading.Thread(target=tester)
    th.start()
    threads = Process().threads()
    print(threads)
    thread_proc = Process(threads[1].id)
    rss_stamps = []
    period = 0.05
    while (th.is_alive()):
        time.sleep(period)
        try:
            rss = thread_proc.memory_info().rss
        except BaseException:
            # timing delay, proc may be dead
            rss = 0.
        rss_stamps.append(rss)

    th.join()
    mb = 1 << 20
    rss_raw = np.array(rss_stamps) / float(mb)
    time = np.arange(rss_raw.size) * period
    plt.plot(time, rss_raw, '.')
    plt.grid()
    plt.xlabel('time(s)')
    plt.ylabel('RSS(Mb)')
    plt.show()
```


If the simple generator were to not be used and the linked list iterated over directly each time, the problem seems to go away entirely.  The following code used instead of the above version works without having this memory leak:
```
@nb.njit
def using_iterator(node2):
    while not node2 is None:
        node2.node1_holder.par1 += 1
        node2 = node2.next
```

This is easily worked around, but I still thought it should be mentioned.


I'm using Numba 0.40.0 on Ubuntu 16.04 LTS.
user: SamRagusa
labels: bug - memory leak: Memory leak
issue_3443: state: open
title: Inject traceback in cuda raised exception
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

From comment: https://github.com/numba/numba/pull/3419/files/864653259bdcddf62f6d3c8f270099e99fbb8457#diff-8ec5e1e22375684281bc2eb2e58cddd3

And related to feature added in https://github.com/numba/numba/pull/3325

We can inject traceback info to pin-point to the source location for the raise site.  Likely require exposing `numba_do_raise` from the `_helperlib.c`.

user: sklam
labels: CUDA: CUDA related issue/PR
issue_3441: state: open
title: funcsigs/inspect signature support (PEP 362 function signature object)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request: PEP 362 function signatures for numba.jit decorated functions.

It would be nice and trivial to add support for the signature function in funcsigs/inspect for numba jitted functions.

Right now, the function fails (at least in funcsigs) with the following error:
ValueError: callable CPUDispatcher(<function test at 0x1043019b0>) is not supported by signature

However, this could be easily solved by setting the __signature__ attribute of the generated CPUDispatcher to the signature of the decorated function.

To illustrate a bit:
```python

In [1]: import numba

In [2]: import funcsigs

In [3]: def test(foo, bar):
   ...:     pass
   ...:

In [4]: test_numba = numba.jit(test)

In [5]: funcsigs.signature(test)
Out[5]: <funcsigs.Signature at 0x113139f10>

In [6]: print(funcsigs.signature(test))
(foo, bar)

In [7]: print(funcsigs.signature(test_numba))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-7-f05a3ef2552f> in <module>()
----> 1 print(funcsigs.signature(test_numba))

/Users/ovillellas/miniconda3/envs/hexrd-develop/lib/python2.7/site-packages/funcsigs/__init__.pyc in signature(obj)
    185         raise ValueError(msg)
    186
--> 187     raise ValueError('callable {0!r} is not supported by signature'.format(obj))
    188
    189

ValueError: callable CPUDispatcher(<function test at 0x1043019b0>) is not supported by signature

In [8]: test_numba.__signature__=funcsigs.signature(test)

In [9]: print(funcsigs.signature(test_numba))
(foo, bar)

In [10]: numba.__version__
Out[10]: '0.40.0+0.gc04edc0.dirty'
```

This could also be applied to other decorators.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: ovillellas
issue_3438: state: open
title: Add (or document) environment variable to disable parallelism
body: ## Feature request

Right now, there is not a (documented) way to _disable_ Numba parallelism from environment variables. Setting `NUMBA_NUM_THREADS=1` still does something with the threading layer, and with the TBB threading layer this also results in a TBB shutdown error:

```
terminate called after throwing an instance of 'tbb::missing_wait'
  what():  wait() was not called on the structured_task_group
```

I see 3 reasonable solutions:

- Add a new `NUMBA_DISABLE_PARALLEL` environment variable that is the equivalent of ignoring `parallel=True`
- Add a `none` option for `NUMBA_THREADING_LAYER` that disables threading entirely.
- Disable threading / parallelism when the thread count is 1 (I don't personally like this option, as it prevents testing the difference between no-parallel code and parallel code with 1 thread in testing scalability)
user: mdekstrand
issue_3431: state: open
title: @vectorize+sig targets cpu/parallel need to catch invalid types earlier
body: The handling of code that is invalid under `nopython` mode in the case of a `@vectorize` decorated function body needs improvement in the case where the signature is declared upfront and states it is valid. It seems like the parallel target actually accepts the compilation result with a return type of `pyobject` but rejects it based on signature mismatch, whereas the cpu target complains about coercion whereas it ought to really note the invalid type.

Contrast:
```python
from numba import vectorize

@vectorize(['float32(float32)'], target='cpu')
def foo(x):
    return object()

foo(11.)
```
which does:
```
  File "testfoo.py", line 8, in <module>
    foo(11.)
TypeError: ufunc 'foo' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''
```
with the parallel target:
```python
from numba import vectorize

@vectorize(['float32(float32)'], target='parallel')
def foo(x):
    return object()

foo(11.)
```
which does:
```
  File "testfoo.py", line 4, in <module>
    @vectorize(['float32(float32)'], target='parallel')
  File "<path>/numba/npyufunc/decorators.py", line 123, in wrap
    return vec.build_ufunc()
  File "<path>/numba/npyufunc/ufuncbuilder.py", line 234, in build_ufunc
    dtypenums, ptr, env = self.build(cres, sig)
  File "<path>/numba/npyufunc/parallel.py", line 159, in build
    dtypenums.append(np.dtype(signature.return_type.name).num)
TypeError: data type "pyobject" not understood
```


user: stuartarchibald
issue_3430: state: open
title: Improve error messages for illegal dynamic memory usage on CUDA
body: For code like:
```python
from numba import vectorize
import numba
import numpy as np

@vectorize(['float32(float32)'], target='cuda')
def foo(x):
    temp = numba.cuda.device_array(10, dtype=np.float32)
    return x

foo(11.)
```
it'd be good to try and spot that a user is attempting to dynamically allocate memory in a kernel and report this during typing and direct to appropriate documentation. At present this is what happens:
```
numba.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Unknown attribute 'device_array' of type Module(<module 'numba.cuda' from '<path>/numba/cuda/__init__.py'>)

File "testfoo.py", line 8:
def foo(x):
    temp = numba.cuda.device_array(10, dtype=np.float32)
    ^

[1] During: typing of get attribute at testfoo.py (8)

File "testfoo.py", line 8:
def foo(x):
    temp = numba.cuda.device_array(10, dtype=np.float32)
```
user: stuartarchibald
labels: CUDA: CUDA related issue/PR
issue_3426: state: open
title: np.random.multinomial throws ValueError: binomial(): p outside of [0, 1]
body: Suppose I have a vector of probabilities that add up to 1.  Sometimes, I have found that using `np.random.multinomial` throws an error.  For example,
```
A = np.array([0.     , 0.91954, 0.01867, 0.     , 0.     , 0.01745, 0.04434,
              0.     , 0.     , 0.     , 0.     , 0.     ])
@jit(nopython=True)
def samp_multi(x):
    return np.random.multinomial(1, x)

for _ in range(100):
    samp_multi(A)
```
leads to the following error:

```
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-794-f6a667d67d4f> in <module>()
      1 for _ in range(100):
----> 2     samp_multi(A)

//anaconda/envs/py35/lib/python3.5/site-packages/numba/targets/randomimpl.py in binomial_impl()
    812             raise ValueError("binomial(): n <= 0")
    813         if not (0.0 <= p <= 1.0):
--> 814             raise ValueError("binomial(): p outside of [0, 1]")
    815         if p == 0.0:
    816             return 0

ValueError: binomial(): p outside of [0, 1]
```
Not sure why this is happening; if anyone can point me to the right direction, that would be great!  Thanks!
user: al5250
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_3421: state: open
title: [Discussion][Umbrella] Parallel backend tasks
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->
Here are potential tasks concerning parallel backends, please add more as you find new ideas or issues

## Vectorization and parallelism
- [ ] Make @guvectorize and @vectorize being able to parallelize and SIMD-vectorize on the same 1D arguments
- [ ] Move partitioning logic from PA to the threading layers. 
- [ ] Move reduction logic to threading layers if seen beneficial

## OpenMP layer
- [ ] separate C extension names of  omppool compiled for specific OpenMP vendors
- [ ] test loading of omppool in a forked process in order to detect if it causes any issues and whether it can be enabled
- [ ] detect conflicting openmp runtimes being loaded in the same process
- [ ] Reenable OpenMP threading backend in wheel builds #3400

## TBB layer
- [ ] Reduce gap in performance with OpenMP using affinity in collaboration with global settings functionality provided by tbb4py [future extension] or when requested through env vars or `numba` entry point
- [ ] Use TBB's [blocked_rangeNd](https://www.threadingbuildingblocks.org/docs/help/reference/appendices/preview_features/blocked_rangeNd_cls.html) or implement alternative aligned_rangeNd for Ndim defined in run-time 

@stuartarchibald 
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: anton-malakhov
labels: threading: Issue involving the threading layers
issue_3418: state: open
title: cfunc cannot be pickled
body: Tested on numba 0.40.0. Trying to pickle a cfunc function:

```python
import numpy as np
import numba

@numba.cfunc("float64(float64)")
def integrand(t):
    return np.exp(-t) / t**2

import pickle
pickle.dumps(integrand)
```
raises a PickleError:
```
PicklingError: Can't pickle <function integrand at 0x000000000CD981E0>: it's not the same object as __main__.integrand
```

The motivation is as follows.  I am using a cfunc for numerical integration with scipy.integrate.quad.  I have a large number of integrations to run. Python's ``multiprocessing`` library requires to pickle the integrand, which is not possible with a cfunc.
user: nbud
issue_3417: state: open
title: Make it possible to annotate method from a jitclass
body: Apparently at the moment it is not possible to annotate the methods of a jitclass so as to pass local types or the `parallel=True` flag for instance.

```python
>>> from numba import jitclass, njit, int8
>>> @jitclass(spec=[('a', int8)])
... class A:
...     def __init__(self, a):
...         self.a = a
... 
...     @jit(locals={'b': int8})
...     def compute_stuff(self):
...         b = 127
...         return self.a > b
...     
Traceback (most recent call last):
  File "<ipython-input-20-48fd07897bd7>", line 1, in <module>
    @jitclass(spec=[('a', int8)])
  File "/opt/venvs/py37/lib/python3.7/site-packages/numba/jitclass/decorators.py", line 27, in wrap
    return register_class_type(cls, spec, types.ClassType, ClassBuilder)
  File "/opt/venvs/py37/lib/python3.7/site-packages/numba/jitclass/base.py", line 192, in register_class_type
    raise TypeError(msg.format(members))
TypeError: class members are not yet supported: compute_stuff
```

This is observed with numba 0.40.1.
user: ogrisel
issue_3409: state: open
title: missing numpy cuda math functions, e.g. matmul
body: I have a kernel runing with guvectorize on 'cpu' and 'cuda'
Since there is no matmul support, I have to implement this outside of the kernel as a jitted function decorated depending if it is 'cpu' or 'cuda' used.
This swould be a relative "easy" way to generate functions like matmul, transpose. I do not how to add patches, but I could write the functions example.
Not sure if this is related to Docs 6 & 8 but it wold be usefull to have those functions and additional ones when using 'cuda' and basically extend http://numba.pydata.org/numba-doc/latest/cuda/cudapysupported.html#built-in-functions
user: cristipurdel
labels: CUDA: CUDA related issue/PR
issue_3398: state: open
title: Code library not linked in lowering. Missing inline opportunity.
body: Throughout lowering, there are many invocation that may be uses code in another code-library but are not linking the dependency.  This is leading to missed inline opportunity and potentially other issues in caching or AoT.

Example of code that needs updating:
https://github.com/numba/numba/blob/3618091896cb54c6b8d442c290cfe5f9480f6e89/numba/lowering.py#L860-L865

Should look like:
https://github.com/numba/numba/blob/3618091896cb54c6b8d442c290cfe5f9480f6e89/numba/lowering.py#L834-L838


user: sklam
labels: caching: Issue involving caching
performance - run time: Performance issue occurring at run time.
issue_3391: state: open
title: Some tests are taking disproportionate amounts of time to run
body: ## Reporting a bug

- [X] I am using the ~latest released~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).

Worst offenders:
```
277.98s call     numba/tests/test_linalg.py::TestBasics::test_outer
202.07s call     numba/tests/test_np_functions.py::TestNPFunctions::test_correlate
157.84s call     numba/tests/test_npdatetime.py::TestDatetimeArithmeticNoPython::test_comparisons
150.36s call     numba/tests/test_npdatetime.py::TestDatetimeArithmetic::test_comparisons
126.24s call     numba/tests/test_linalg.py::TestBasics::test_kron
125.05s call     numba/tests/test_np_functions.py::TestNPFunctions::test_convolve
112.58s call     numba/tests/test_np_functions.py::TestNPFunctions::test_vander_basic
72.75s call     numba/tests/test_threadsafety.py::TestThreadSafety::test_concurrent_vectorize
69.15s call     numba/tests/test_threadsafety.py::TestThreadSafety::test_concurrent_guvectorize
66.47s call     numba/tests/test_np_functions.py::TestNPFunctions::test_searchsorted
49.43s call     numba/tests/test_numberctor.py::TestArrayNumberCtor::test_2d
46.19s call     numba/tests/test_linalg.py::TestLinalgLstsq::test_linalg_lstsq
43.16s call     numba/tests/test_linalg.py::TestLinalgNorm::test_linalg_norm
41.80s call     numba/tests/test_numberctor.py::TestArrayNumberCtor::test_1d
40.77s call     numba/tests/npyufunc/test_vectorize_decor.py::TestParallelVectorizeDecor::test_4
39.42s call     numba/tests/test_stencils.py::TestStencil::test_stencil_call_const
38.61s call     numba/tests/test_threadsafety.py::TestThreadSafety::test_concurrent_vectorize_cache
37.57s call     numba/tests/test_threadsafety.py::TestThreadSafety::test_concurrent_jit
37.32s call     numba/tests/test_array_reductions.py::TestArrayReductions::test_nanpercentile_basic
35.25s call     numba/tests/test_linalg.py::TestLinalgSolve::test_linalg_solve
35.15s call     numba/tests/test_stencils.py::TestStencil::test_stencil2
33.46s call     numba/tests/test_threadsafety.py::TestThreadSafety::test_concurrent_mix_use
32.72s call     numba/tests/npyufunc/test_vectorize_decor.py::TestCPUVectorizeJitted::test_4
30.45s call     numba/tests/test_stencils.py::TestStencil::test_stencil_call
29.69s call     numba/tests/test_polynomial.py::TestPoly1D::test_roots
28.40s call     numba/tests/test_ufuncs.py::TestUFuncCompilationThreadSafety::test_lock
27.46s call     numba/tests/npyufunc/test_vectorize_decor.py::TestCPUVectorizeDecor::test_4
26.96s call     numba/tests/test_stencils.py::TestStencil::test_stencil1
26.68s call     numba/tests/test_stencils.py::TestStencil::test_stencil_multiple_inputs
26.35s call     numba/tests/test_npdatetime.py::TestDatetimeArithmetic::test_add_sub_timedelta
26.09s call     numba/tests/test_npdatetime.py::TestDatetimeArithmeticNoPython::test_add_sub_timedelta
25.35s call     numba/tests/test_fancy_indexing.py::TestFancyIndexing::test_setitem_tuple_and_ellipsis
25.12s call     numba/tests/test_linalg.py::TestLinalgCond::test_linalg_cond
23.25s call     numba/tests/test_np_functions.py::TestNPFunctions::test_digitize
23.21s call     numba/tests/test_array_manipulation.py::TestArrayManipulation::test_fill_diagonal_basic
22.84s call     numba/tests/test_fancy_indexing.py::TestFancyIndexing::test_getitem_tuple_and_ellipsis
22.14s call     numba/tests/test_numberctor.py::TestScalarNumberCtor::test_numba_types
21.98s call     numba/tests/test_np_functions.py::TestNPFunctions::test_tril_basic
21.95s call     numba/tests/test_numberctor.py::TestScalarNumberCtor::test_numpy_types
21.00s call     numba/tests/test_fancy_indexing.py::TestFancyIndexing::test_setitem_tuple
```
user: stuartarchibald
labels: performance: performance related issue
performance - compile time: Performance issue occurring at compile time.
performance - run time: Performance issue occurring at run time.
issue_3379: state: open
title: Allow user to customize CUDA IPC offset
body: Related issue to https://github.com/numba/numba/issues/3247

Example of affected code region:
https://github.com/numba/numba/blob/3618091896cb54c6b8d442c290cfe5f9480f6e89/numba/cuda/cudadrv/driver.py#L780-L794

For code that uses a memory pool, it is possible to supply a single IPC handle to the base address of the pool memory and use offset to denote different region of the pool.  Allowing user to customize the offset is needed in such cases.
user: sklam
labels: CUDA: CUDA related issue/PR
issue_3378: state: open
title: Objmode crashes sometimes
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest ~~released~~ master version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

A function that has `objmode` inside it crashes sometimes in HPAT. I haven't been able to create a small reproducer yet, but the backtrace from gdb is below. Any ideas?


```Program received signal SIGSEGV, Segmentation fault.
0x000055555568cfd4 in PyList_GetItem ()
(gdb) bt
#0  0x000055555568cfd4 in PyList_GetItem ()
#1  0x00007ffff7e5308a in hpat::csv_ext::csv_reader_py$249(pyobject) ()
#2  0x00007ffff7e53b95 in cpython::hpat::csv_ext::csv_reader_py$249(pyobject) ()
#3  0x0000555555662b94 in _PyCFunction_FastCallDict ()
#4  0x0000555555662faf in _PyObject_FastCallDict ()
#5  0x00005555556812ed in PyObject_CallFunctionObjArgs ()
#6  0x00007ffff7e51135 in hpat::csv_ext::csv_reader_py$2410(StringType) ()
#7  0x00007ffff7e4b0b8 in __main__::TestIO::test_csv_parallel1::$3clocals$3e::test_impl$241 ()
#8  0x00007ffff7e4b5e6 in cpython::__main__::TestIO::test_csv_parallel1::$3clocals$3e::test_impl$241 ()
#9  0x00007fffd1c66584 in call_cfunc () from /home/etotoni/pse-hpc/python/numba/numba/_dispatcher.cpython-36m-x86_64-linux-gnu.so
#10 0x00007fffd1c669c9 in compile_and_invoke () from /home/etotoni/pse-hpc/python/numba/numba/_dispatcher.cpython-36m-x86_64-linux-gnu.so
#11 0x00007fffd1c66b3f in Dispatcher_call () from /home/etotoni/pse-hpc/python/numba/numba/_dispatcher.cpython-36m-x86_64-linux-gnu.so
```
user: ehsantn
labels: objectmode: object mode related issue
issue_3377: state: open
title: Built-in types float assigment in decorators
body: 
## Feature request



It would be nice to have an option in the decorators guvectorize, vectorize, ... to convert all floats from within a kernel to a certain type: I would prefer float32 to be default since the speed versus float64 is considerable when looking at the new GeForce 20 series, and maybe get 2x the speed by using float16 



user: cristipurdel
labels: CUDA: CUDA related issue/PR
issue_3364: state: open
title: Error formatting text width is not padded to CPython/readline's 80chars
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

The output from Numba error rewriting should be padded to 80 chars as per the Python traceback formatting. An example of this not working:

```
$ python pointlesslongfilenametooverflowtermwidthsothatitisatleast80charslongthisnameis81.py|&cowsay -W80                       
 _________________________________________________________________________________                                              
/ Traceback (most recent call last):                                              \                                             
|                                                                                 |                                             
| File                                                                            |                                             
| "pointlesslongfilenametooverflowtermwidthsothatitisatleast80charslongthisnameis |                                             
| 81.py", line 13, in <module>                                                    |                                             
|                                                                                 |                                             
| print(test(rec[0]))                                                             |                                             
|                                                                                 |                                             
| File "< path                             >numba/numba/dispatcher.py", line 348, |                                             
| in _compile_for_args                                                            |                                             
|                                                                                 |                                             
| error_rewrite(e, 'typing')                                                      |                                             
|                                                                                 |                                             
| File "< path                             >numba/numba/dispatcher.py", line 313, |                                             
| in error_rewrite                                                                |                                             
|                                                                                 |                                             
| raise e                                                                         |                                             
|                                                                                 |                                             
| File "< path                             >numba/numba/dispatcher.py", line 324, |                                             
| in _compile_for_args                                                            |                                             
|                                                                                 |                                             
| return self.compile(tuple(argtypes))                                            |                                             
|                                                                                 |                                             
| File "< path                             >numba/numba/compiler_lock.py", line   |                                             
| 32, in _acquire_compile_lock                                                    |
|                                                                                 |
| return func(*args, **kwargs)                                                    |
|                                                                                 |
| File "< path                             >numba/numba/dispatcher.py", line 655, |
| in compile                                                                      |
|                                                                                 |
| cres = self._compiler.compile(args, return_type)                                |
|                                                                                 |
| File "< path                             >numba/numba/dispatcher.py", line 82,  |
| in compile                                                                      |
|                                                                                 |
| pipeline_class=self.pipeline_class)                                             |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 904,   |
| in compile_extra                                                                |
|                                                                                 |
| return pipeline.compile_extra(func)                                             |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 367,   |
| in compile_extra                                                                |
|                                                                                 |
| return self._compile_bytecode()                                                 |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 835,   |
| in _compile_bytecode                                                            |
|                                                                                 |
| return self._compile_core()                                                     |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 822,   |
| in _compile_core                                                                |
|                                                                                 |
| res = pm.run(self.status)                                                       |
|                                                                                 |
| File "< path                             >numba/numba/compiler_lock.py", line   |
| 32, in _acquire_compile_lock                                                    |
|                                                                                 |
| return func(*args, **kwargs)                                                    |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 253,   |
| in run                                                                          |
|                                                                                 |
| raise patched_exception                                                         |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 244,   |
| in run                                                                          |
|                                                                                 |
| stage()                                                                         |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 477,   |
| in stage_nopython_frontend                                                      |
|                                                                                 |
| self.locals)                                                                    |
|                                                                                 |
| File "< path                             >numba/numba/compiler.py", line 1006,  |
| in type_inference_stage                                                         |
|                                                                                 |
| infer.propagate()                                                               |
|                                                                                 |
| File "< path                             >numba/numba/typeinfer.py", line 860,  |
| in propagate                                                                    |
|                                                                                 |
| raise errors[0] numba.errors.TypingError: Failed in nopython mode pipeline      |
| (step: nopython frontend) failed to unpack Record([('index',  |
| '<i8'), ('a', '<f8'), ('b', '|b1')])  File                             |
| "pointlesslongfilenametooverflowtermwidthsothatitisatleast80charslongthisnameis |
| 81.py", line 10: def test(record):  i, a, b = record  |
| ^  [1] During: typing of exhaust iter at      |
| pointlesslongfilenametooverflowtermwidthsothatitisatleast80charslongthisnameis8 |
| 1.py (10)  File                                                    |
| "pointlesslongfilenametooverflowtermwidthsothatitisatleast80charslongthisnameis |
| 81.py", line 10: def test(record):  i, a, b = record  |
\ ^                                                              /
 ---------------------------------------------------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
```
note the somewhat messy appearance once out of CPython traceback and into Numba error message helpers.



user: stuartarchibald
issue_3361: state: open
title: Fix warning from compiling C++ with a C compiler and invalid flags
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

Here:
https://github.com/numba/numba/blob/master/numba/pycc/platform.py#L52-L53
the distutils customized C compiler tries to compile some C++ (denoted by file suffix) with a flag that is invalid for C++ source. Fix it!

user: stuartarchibald
issue_3359: state: open
title: Unpacking of record fails in nopython mode
body: Example:
```python
import pandas as pd
from numba import njit, jit

records = pd.DataFrame(data={"a": [1], "b": [True]}).to_records()

@njit
def test(record):
  index, a, b = record
  return a

test(records[0])
```

Error:
```
failed to unpack Record([('index', '<i8'), ('a', '<i8'), ('b', '|b1')])

File "scratch_5.py", line 9:
def test(record):
  index, a, b = record
  ^
```

The same code runs just fine in the regular jit mode. Numba version: 0.40

**Edit:** It's actually worse than I first thought. I am not able to retrieve values at all. The following fails as well:

```python
@njit
def test(record):
  return record[1]
```
user: ghost
issue_3354: state: open
title: Support list as index type
body: As title. Example:

```
In [14]: def foo(A):
    ...:         return A[:, [2]]
    ...: 

In [15]: x=np.arange(20).reshape(4,5)

In [16]: foo(x)
Out[16]: 
array([[ 2],
       [ 7],
       [12],
       [17]])
```

user: stuartarchibald
issue_3353: state: open
title: Implement `.reshape` to work on non-contiguous inputs
body: As title.
user: stuartarchibald
issue_3349: state: open
title: Document the container types
body: https://numba.pydata.org/numba-doc/dev/reference/types.html doesn't have the container types documented. Now `numba.objmode` is implemented and adheres to the context manager protocol, it's feasible that users would want to define types that leave an `objmode` block that are more complex than those covered by the current docs (which I think are largely in relation to type signatures for `{g,}ufuncs` ans so relatively primitive).
user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_3336: state: open
title: Enable automatic parallel execution in pre-compiled code
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

Follow up from [this stack overflow querestion](https://stackoverflow.com/questions/52471590/use-multithreading-in-numba) it seems that the `pycc` compiler is not able to recognize the method `numba.prange` and execute the code as it was a standard `range` method.

It will be great to have `pycc` able to recvognize `numba.prange` so to be able to execute  computations in parallel from a pre-compiled `numba` code.

A reproducible example: 

* **File:**  `numba_ray_tracing.py`

```python
from numba import jit, njit
from numba.pycc import CC
import numba
cc = CC('nbspatial')

import numpy as np

@cc.export('array_tracing', 'b1[:](f8[:,:], f8[:,:])')
@njit(parallel=True)
def array_tracing(xy, poly):
    D = np.empty(len(xy), dtype=numba.boolean)
    n = len(poly)
    for i in numba.prange(1, len(D) - 1):
        inside = False
        p2x = 0.0
        p2y = 0.0
        xints = 0.0
        p1x,p1y = poly[0]
        x = xy[i][0]
        y = xy[i][1]
        for i in range(n+1):
            p2x,p2y = poly[i % n]
            if y > min(p1y,p2y):
                if y <= max(p1y,p2y):
                    if x <= max(p1x,p2x):
                        if p1y != p2y:
                            xints = (y-p1y)*(p2x-p1x)/(p2y-p1y)+p1x
                        if p1x == p2x or x <= xints:
                            inside = not inside
            p1x,p1y = p2x,p2y
        D[i] = inside
    return D

if __name__ == "__main__":
    cc.compile()
```
* **Compile:** `python3.7 numba_ray_tracing.py`

* **Test**

```python
import nbspatial
import numpy as np
# regular polygon for testing
lenpoly = 10000
polygon = np.array([[np.sin(x)+0.5,np.cos(x)+0.5] for x in np.linspace(0,2*np.pi,lenpoly)[:-1]])

# random points set of points to test 
N = 1000000
points = np.array([np.random.random(N), np.random.random(N)]).reshape(N,2)
```
```python
%%time
nbspatial.array_tracing(points, polygon)
```
```
CPU times: user 1min 31s, sys: 512 ms, total: 1min 32s
Wall time: 1min 31s
```

The code above doesn't run in parallel. The same code runs in parallel if used in an interactive python session.

[Example code](https://gist.github.com/epifanio/47340242f5be2de2c50577bf82c37143)
user: epifanio
labels: AOT: ahead of time compilation issue
caching: Issue involving caching
Effort - long: Long size effort needed
issue_3332: state: open
title: Nested jit annotations
body: I have code with a structure like the example below:

```python
@numba.jit()
def test():
  state = 0

  @numba.jit(nopython=True)
  def sub(param):
    nonlocal state
    state += param

  for i in range(100):
    param = i # Assume this line is nopython incompatible code
    sub(param)

  print(state)
```

Because of the nonlocal `state` variable, the `test` function has to be jitted. Otherwise, I would just remove the first annotation because what really matters is the `sub` function. Therefore, I wanted to to enable the `nopython` mode for it, which unfortunately fails with an error:

```
  @numba.jit(nopython=True)
  ^
[1] During: lowering "$0.11 = make_function(name=$const0.10, code=<code object fast_sub at 0x0000028ABF11E6F0, file ".../scratches/scratch.py", line 89>, closure=$0.8, defaults=None)" at .../scratches/scratch.py (89)
-------------------------------------------------------------------------------
```

In the real code, there are lots of state variables. If there is no better solution, I will probably just use a list which I can pass around to share the state. Nested `numba.jit` annotations would be much more convenient though. What do you think?
user: ghost
labels: objectmode: object mode related issue
issue_3328: state: open
title: Avoid unnecessary compilation in type inference
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Dependent functions are compiled eagerly during type inference. But this compilation could be unnecessary since functions can be optimized out in transformations later.

user: ehsantn
labels: performance - compile time: Performance issue occurring at compile time.
issue_3319: state: open
title: Improve documentation to show how to call cffi functions taking struct arguments
body: Dear numba team,

I am trying to figure out how to call cffi functions that take struct arguments. The documentation about it: https://numba.pydata.org/numba-doc/dev/reference/pysupported.html
is mentioning: 
-- snip start --
Additional type mappings for the conversion from a buffer to the appropriate C type may be registered with Numba. This may include struct types, though it is only permitted to call functions that accept pointers to structs - passing a struct by value is unsupported. For registering a mapping, use:
numba.cffi_support.register_type(cffi_type, numba_type)
-- snip end --
I am trying to figure out how to use cffi_support.register_type for an own struct. The only "example" I've found is "./numba/tests/cffi_usecases.py", but this example calls register_type with "complex128" as the argument for numba_type, which exists already as part of the numba source code.

How do I use numba.cffi_support.register_type for an own type, e.g. 
-- snip start --
typedef struct {
  int n;
  double *values;
} dt;
-- snip end --
As value for the cffi_type I use "ffi.typeof('struct dt')". What do I use for numba_type? And how do I later use it in a jited numba function, e.g. I try the following, which does not work:
-- snip start --
@jit(nopython=True, parallel=True)
def tic(x,y,B=9, c=5):
    dt = ffi.new("dt *")
    dt.n = N
    dt.values = ffi.cast("double *", x.ctypes.data)
    r = dummytics(dt)
    return r / len(x)
-- snip end --

Thanks a lot!
Christian
user: cs224
issue_3305: state: open
title: jitclass method not inlined
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

From mailing-list discussion at https://groups.google.com/a/continuum.io/d/msgid/numba-users/bd1f6d06-8a71-43a1-8c60-8260f32742fc%40continuum.io?utm_medium=email&utm_source=footer

Jitclass methods are missing inter-procedural optimization (IPO) because their LLVM libraries are not being merged.  Methods are not included in IPO and can result in 2x speed difference as shown in the notebook below:

See details in notebook https://gist.github.com/sklam/8920c81707494f3f657488c24ffd9294


user: sklam
labels: performance - run time: Performance issue occurring at run time.
issue_3301: state: open
title: Unbox does not check array type mismatch
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

https://github.com/numba/numba/pull/3166 revealed problems with Array unboxer that it doesn't check the type in the ndarray pyobject against the expected numba type.  The PR also added a temporary fix for the case when the expected and actual itemsizes mismatch.  The proper fix will be more involved.

TODOs: https://github.com/numba/numba/blob/a08595bbbae583b21f174e8f5cf4c77a3a32553f/numba/targets/boxing.py#L386-L403

Affected code: https://github.com/numba/numba/pull/3166/commits/a08595bbbae583b21f174e8f5cf4c77a3a32553f
user: sklam
issue_3290: state: open
title: Catch assertions in the pipeline and translate into bug report requests
body: 
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request
Following up on https://github.com/numba/numba/issues/3289, failing `assert`s are not caught can leave users with an `AssertionError` that simply states which pipeline and where in the pipeline the failure occurred. This should really be rewritten to add the bug report message.
<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: stuartarchibald
issue_3284: state: open
title: JIT to a WebAssembly target
body: ## Feature request

Imagine writing an image transformation in python code and jitting it to output to WebAssembly for use in a browser.  This will allow python viz tools to push computations to the browser to reduce latency.

State of the tech:

* LLVM has webassembly backend.  Since numba emits LLVM IR, emitting webassembly is not hard.
* Numba (re)implements a lot of the NumPy API internally.  Any used NumPy functions will be encoded in webassembly.  Thus, allowing us to inject (almost) seamless NumPy support into the browser.
user: sklam
issue_3283: state: open
title: Problems with support_literals and the Const type
body: From discussion in the Numba core dev meeting on "Problems with support_literals and the Const type"

Problems:
 * Lowering backend mishandle Const type likely caused by other arguments that are not expecting a Const

Blocking:
 * np.dtype(str) and other str usage

Suggested Solutions:
 1. autoconversion of Const into bare Type
     * Siu: try this by next meeting
2. `support_literals` for particular argument by name or position
3. QualType or metadata; remove Const type
user: stuartarchibald
issue_3282: state: open
title: Pass thru pyobjects
body: ## Feature request

Allow python objects to be passed around inside nopython mode.  Key points:

* no operation are performed on passthru objects.  Inc/Decref are performed at the python<->nopython boundaries.  
* passthru objects must be wrapped by a numba NRT box.  NRT must acquire a python reference on the pyobject.  This allow pyobject to be captured in nopython land, where NRT is solely responsible for the refcount on passthru objects.
* passthru object can be unwrapped and operated on by objectmode context (see https://github.com/numba/numba/pull/3166).

user: sklam
issue_3277: state: open
title: autojit crashed unexpectedly 
body: The function source of iPython produces a plot with a random superposition of harmonics

<img width="948" alt="screen shot 2018-08-28 at 23 12 43" src="https://user-images.githubusercontent.com/6969076/44751233-e8046600-ab17-11e8-948a-dcc3f2d7a107.png">

However when @autojitted, it produces an error message and prompts me to report it. 

<img width="759" alt="screen shot 2018-08-28 at 23 15 10" src="https://user-images.githubusercontent.com/6969076/44751370-4893a300-ab18-11e8-9616-777cab24da3f.png">

Cheers

user: jamasole
issue_3267: state: open
title: Automatic detection of changes to globals at call time to trigger recompilation
body: In Python 3.6, dictionaries are versioned with an integer key that changes every time they are updated.  This should allow a Numba-compiled function (CPU, CUDA, etc) to quickly detect if global values referenced in the function may have changed since it was last called.  In those situations, the in-memory function cache should be cleared, causing the function to be compiled again with the new global values.  The current Numba behavior of freezing globals (and values from closures) is counter-intuitive for cases where the globals are not constants.  See this [FAQ entry](https://numba.pydata.org/numba-doc/dev/user/faq.html#numba-doesn-t-seem-to-care-when-i-modify-a-global-variable) and reported issues like #3265.

Unfortunately, solving one problem raises some different, hard to solve problems:

1. Even with dictionary versioning, the implementation is still a little tricky when you consider nested packages.  If a function refers to `foo.bar.baz`, then we have to check the versions of `globals()`, `foo.__dict__`, and `bar.__dict__` to make sure nothing further up the change was swapped out since the last call.

2. Because the version is on the whole globals() dictionary, scripts which constantly change global values *not* used by Numba-compiled functions will unnecessarily recompile those functions over and over again.  Depending on how often the globals dictionary is changing, constant recompilation could completely kill any performance gains.  This might also create issues in Jupyter, if execution of later cells also triggers global dictionary version changes.

3. Python versions less than 3.6 do not have support for dictionary versions, and there really is no practical workaround on those platforms since global values do not have to be hashable in general.  If we add opportunistic  support for global change detection, then we make Numba behave differently between Python 3.5 and 3.6.  Even after the Python 2.7 sunset in 2019, this problem doesn't go away.

4. If we solve the first two issues by making this behavior explicitly opt-in (with a flag on the `@jit` decorator) then we technically solve the issue, but not in practice since the users who are tripped up by the current global behavior are also likely to be unaware of any optional flag to generate the Python behavior they expect.

It is possible that opt-in detection of global changes is the only solution available to us, but I would want to understand the implications for Jupyter before proceeding.
user: seibert
labels: caching: Issue involving caching
issue_3262: state: open
title: Memory leak when exception occurs in np.linalg.svd
body: The below example leaks memory in stable Numba. I was unable to try with master. My experiments point to `nditer` being the culprit.

```python
import numba as nb
import numpy as np
import numba.runtime as nrt

@nb.njit
def svd(A):
    U, s, V = np.linalg.svd(A)

a = np.eye(3) + np.inf
while True:
    try:
        svd(a)
    except:
        pass
    st = nrt.rtsys.get_allocation_stats()
    print(st.alloc - st.free, end='\r', flush=True)
```
user: lericson
issue_3254: state: open
title: Feature request: making it easier to profile nested jitted functions / methods
body: When writing `@jitclass` with nested method calls or nested `@jit` function calls, the traditional cProfiler can only trace the calls to the first dispatch. The nested calls are not traced.

I understand that tracing nested calls would typically add too much overhead to keep the profiling useful.

This is why I would rather use a sampling profiler for the generated native code. Such profilers include the [google performance tools](https://github.com/gperftools/gperftools) (possibly via the [yep](https://github.com/fabianp/yep) python module) or the [Linux system profiler](https://perf.wiki.kernel.org/index.php/Tutorial) via the `perf top -p pid` or `perf record python myscript.py` commands.

However when those profilers fail to produce informative reports for numba programs as apparently numba (or llvm/llvmlite) does not propagate the python function names (or python filename + line number) as introspectable symbol metadata in the generated native code. For instance here the output of the `perf report` command on a numba run:

```
Samples: 773  of event 'cycles:pp', Event count (approx.): 2879077002852150
Overhead  Command  Shared Object                               Symbol
   4,40%  python   perf-6162.map                               [.] 0x00007feb532fb141
   4,38%  python   perf-6162.map                               [.] 0x00007feb53195104
   3,39%  python   perf-6162.map                               [.] 0x00007feb5319510d
   2,99%  python   perf-6162.map                               [.] 0x00007feb53300065
   2,72%  python   perf-6162.map                               [.] 0x00007feb532fb160
   2,70%  python   perf-6162.map                               [.] 0x00007feb53195112
   2,65%  python   perf-6162.map                               [.] 0x00007feb532fb10c
   2,23%  python   perf-6162.map                               [.] 0x00007feb5319514c
   2,18%  python   perf-6162.map                               [.] 0x00007feb532fb13c
   2,07%  python   perf-6162.map                               [.] 0x00007feb532fb100
   2,05%  python   perf-6162.map                               [.] 0x00007feb53195161
   2,02%  python   perf-6162.map                               [.] 0x00007feb53195136
```

I tried to read through the numba / llvmlite documentation to see if there was a way to configure numba to provide `perf` with those symbols but I could not find any.

Note that improving the documentation on how to profile numba code has already been reported by @jni in the meta #2888 issue (Tracker for Numba usability improvements.) but I thought it was worth having a more specific discussion for sampling based profiling of nested numba jit function calls.
user: ogrisel
issue_3250: state: open
title: Implement f-string support
body: This program:
```
import numba

@numba.jit(nopython=False)
def test( a: int ):
    b = a + 1
    print( f'b:{b}' )
    return b

b = test( 1 )
print( f'b:{b}' )
```

Throws this exception:

```
(py36) [marcino@localhost numbatest]$ python test.py 
Traceback (most recent call last):
  File "test.py", line 9, in <module>
    b = test( 1 )
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dispatcher.py", line 368, in _compile_for_args
    raise e
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dispatcher.py", line 325, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dispatcher.py", line 653, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dispatcher.py", line 83, in compile
    pipeline_class=self.pipeline_class)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 873, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 367, in compile_extra
    return self._compile_bytecode()
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 804, in _compile_bytecode
    return self._compile_core()
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 791, in _compile_core
    res = pm.run(self.status)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 253, in run
    raise patched_exception
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 245, in run
    stage()
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 381, in stage_analyze_bytecode
    func_ir = translate_stage(self.func_id, self.bc)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/compiler.py", line 937, in translate_stage
    return interp.interpret(bytecode)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/interpreter.py", line 98, in interpret
    self.dfa.run()
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dataflow.py", line 28, in run
    self.infos[blk.offset] = self.run_on_block(blk)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dataflow.py", line 78, in run_on_block
    self.dispatch(info, inst)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dataflow.py", line 88, in dispatch
    fn(info, inst)
  File "/home/marcino/py36/lib/python3.6/site-packages/numba/dataflow.py", line 93, in handle_unknown_opcode
    self.bytecode.func_id.filename))
NotImplementedError: Failed at object (analyzing bytecode)
Use of unknown opcode FORMAT_VALUE at line 6 of test.py
```

user: marcino239
issue_3249: state: open
title: Sync numpy random generator with numba random state
body: ## Feature request

I got a code for which I could not have deterministic test output due
to some np.random calls in a numba function. Reading the test_random.py
file I found maybe a way to address this issue using a decorator.
The idea is to get from a RandomState instance or the global np random
the state of numpy generator, set it to numba and then on exit taking
the numba state and set it back to numpy. The code looks like this.

```
# Author : Alex Gramfort, <alexandre.gramfort@inria.fr>

import numpy as np
from numba import njit, _helperlib


def check_random_state(seed):
    """Turn seed into a np.random.RandomState instance.

    If seed is None, return the RandomState singleton used by np.random.
    If seed is an int, return a new RandomState instance seeded with seed.
    If seed is already a RandomState instance, return it.
    Otherwise raise ValueError.
    """
    if seed is None or seed is np.random:
        return np.random.mtrand._rand
    if isinstance(seed, (int, np.integer)):
        return np.random.RandomState(seed)
    if isinstance(seed, np.random.RandomState):
        return seed
    raise ValueError('%r cannot be used to seed a numpy.random.RandomState'
                     ' instance' % seed)


def _copy_np_state(r, ptr):
    """
    Copy state of Numpy random *r* to Numba state *ptr*.
    """
    ints, index = r.get_state()[1:3]
    _helperlib.rnd_set_state(ptr, (index, [int(x) for x in ints]))
    return ints, index


def _copyback_np_state(r, ptr):
    """
    Copy state of of Numba state *ptr* to Numpy random *r*
    """
    index, ints = _helperlib.rnd_get_state(ptr)
    r.set_state(('MT19937', ints, index, 0, 0.0))


def get_np_state_ptr():
    return _helperlib.rnd_get_np_state_ptr()


class use_numba_random(object):
    """Decorator that gets the current of numpy random, then
    sets it to numba and then puts the new state of numba
    to numpy to decoration the function of not does not
    affect the output."""
    def __init__(self, random_state=None):
        self.random_state = random_state

    def __call__(self, func):
        def new_func(*args, **kwargs):
            r = check_random_state(self.random_state)
            ptr = get_np_state_ptr()
            _copy_np_state(r, ptr)
            out = func(*args, **kwargs)
            _copyback_np_state(r, ptr)
            return out
        return new_func


def test_no_decorator():
    """Test that shows the problem when not using a decorator."""
    np.random.seed(0)
    r1_ok, r2_ok = np.random.rand(), np.random.rand()

    # Define a numba function using np.random
    @njit()
    def generate_random():
        return np.random.rand()

    np.random.seed(0)
    r1 = generate_random()
    r2 = np.random.rand()
    assert r1 != r1_ok
    assert r2 == r1_ok  # Numba does not increment the state of np.random
    assert r2 != r2_ok


def test_global_random():
    """Test using a global numpy random state."""
    np.random.seed(0)
    r = check_random_state(None)
    r1_ok, r2_ok = r.rand(), r.rand()

    np.random.seed(0)
    r = check_random_state(None)

    # Define a numba function decorated to sync it's seed
    # with a random state or current np.random
    @use_numba_random(r)
    @njit()
    def generate_random():
        return np.random.rand()

    r1 = generate_random()
    r2 = r.rand()
    assert r1 == r1_ok
    assert r2 == r2_ok


def test_random_state():
    """Test using a numpy RandomState."""
    r = check_random_state(42)
    r1_ok, r2_ok = r.rand(), r.rand()

    r = check_random_state(42)

    # Define a numba function decorated to sync it's seed
    # with a random state or current np.random
    @use_numba_random(r)
    @njit()
    def generate_random():
        return np.random.rand()

    r1 = generate_random()
    r2 = r.rand()
    assert r1 == r1_ok
    assert r2 == r2_ok


if __name__ == '__main__':
    test_no_decorator()
    test_global_random()
    test_random_state()
```

what are you thoughts on this? could it inspire passing to jit of njit decorators a random_state parameter to keep np.random and numba states in sync. This would allow to get the same outputs if the njit / jit decorator is used or not.

this code solved my problem but maybe it can help others...
user: agramfort
issue_3231: state: open
title: consider caching for array-expr lowering
body: Array-expr are common and their lowering can expand into large loop-nest, which can consume significant amount of compilation time (10-15% in profiling https://github.com/numba/numba/blob/c18f54ca7bb521f1a5dc338785111ca77b189244/numba/tests/test_array_exprs.py).  We should consider caching the array-expr.

https://github.com/numba/numba/blob/c18f54ca7bb521f1a5dc338785111ca77b189244/numba/npyufunc/array_exprs.py#L330

https://github.com/numba/numba/blob/c18f54ca7bb521f1a5dc338785111ca77b189244/numba/targets/npyimpl.py#L297




user: sklam
issue_3223: state: open
title: Importing time is taking too long
body: I have tested multiple versions on conda environment and python 3.6:

```
0.30.1
Estimating running time...
246 ms ± 6.44 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.31.0
Estimating running time...
253 ms ± 5.73 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.32.0
Estimating running time...
254 ms ± 6.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.33.0
Estimating running time...
264 ms ± 6.95 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.34.0
Estimating running time...
256 ms ± 6.62 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.35.0
Estimating running time...
269 ms ± 8.8 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.36.1
Estimating running time...
266 ms ± 8.85 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.36.1
Estimating running time...
264 ms ± 3.56 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.36.2
Estimating running time...
302 ms ± 5.89 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.37.0
Estimating running time...
312 ms ± 7.63 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.38.0
Estimating running time...

309 ms ± 5.28 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.38.1
Estimating running time...
368 ms ± 43.3 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

0.39.0
Estimating running time...
339 ms ± 13.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
```

Plot: https://ipfs.io/ipfs/QmZqG5aU8VKSuteEdmLCKkfJLWUK1n55mCyAFRhBHiYzNa
Timing tool: https://pypi.org/project/shell-timeit/

If doable, it would be amazing to import `numba` in under 200 ms.
user: horta
issue_3210: state: open
title: Improve serialization of AutoJitCUDAKernel
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Need to add serialization to existing definitions inside `AutoJitCUDAKernel` https://github.com/numba/numba/blob/master/numba/cuda/compiler.py#L837-L847
The `CUDAKernel` is keeping the PTX.
user: sklam
labels: CUDA: CUDA related issue/PR
issue_3207: state: open
title: Pass c_char or c_char_p to ctypes function in numba
body: I just realize that numba now does not support ctypes function with argument c_char or c_char_p. It will show an error that this type is not supported.

However, one of the c function I was using requires the first argument to be a single string, "N". Is there a way to get around this limitation and use this C function in jit function? 
user: goduck777
issue_3205: state: open
title: Performance case study
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I'm looking to migrate some code from Cython to numba. The cython generated code ~2x faster. I'm  hopeful that this is small enough to make for a good case study.

```python
import numpy as np
import numba

x = np.random.uniform(size=(10_000, 20))
n_clusters = 4

labels = np.random.randint(0, n_clusters, size=x.shape[0], dtype=np.int32)
centers = x[:n_clusters]
distances = np.random.uniform(size=10_000)
```

Here's the Cython version

```cython
import numpy as np
cimport cython
cimport numpy as np
from cython cimport floating
ctypedef np.float64_t DOUBLE
ctypedef np.int32_t INT


@cython.boundscheck(False)
@cython.wraparound(False)
@cython.cdivision(True)
def cy_centers_dense(np.ndarray[floating, ndim=2] X,
                     np.ndarray[INT, ndim=1] labels,
                     int n_clusters,
                     np.ndarray[floating, ndim=1] distances):
    cdef int n_samples, n_features
    cdef int i, j, c
    cdef np.ndarray[floating, ndim=2] centers

    n_samples = X.shape[0]
    n_features = X.shape[1]
    centers = np.zeros((n_clusters, n_features), dtype=np.float64)

    with nogil:
        for i in range(n_samples):
            for j in range(n_features):
                centers[labels[i], j] += X[i, j]

    return centers
```

and the numba version

```python
@numba.njit(nogil=True, fastmath=True)
def nb_centers_dense(X,
                     labels,
                     n_clusters,
                     distances):
    n_samples = X.shape[0]
    n_features = X.shape[1]
    centers = np.zeros((n_clusters, n_features), dtype=np.float64)

    for i in range(n_samples):
        for j in range(n_features):
            centers[labels[i], j] += X[i, j]

    return centers
```

```python
# they match
a = cy_centers_dense(x, labels, n_clusters, distances)
b = nb_centers_dense(x, labels, n_clusters, distances)

np.testing.assert_almost_equal(a, b)
```

timings

```
%timeit nb_centers_dense(x, labels, n_clusters, distances)
236 µs ± 3.65 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

```
%timeit cy_centers_dense(x, labels, n_clusters, distances)
131 µs ± 4.77 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```
user: TomAugspurger
labels: performance: performance related issue
issue_3200: state: open
title: NVIDIA cub support
body: ## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

tl;dr I'd like to use NVIDIA cub primitive's in a jitted CUDA function, but am not sure how to achieve this.

[NVIDIA cub](https://nvlabs.github.io/cub/) contains many useful Warp/Block and Device wide-primitives (sorts/segmented algorithms/reductions) for CUDA GPU programming. Additionally, the contained primitives are optimised and maintained for different architectures, reducing the maintenance overhead of a user.

I see that cub's device-wide radix sort is wrapped in [pyculib_sorting](https://github.com/numba/pyculib_sorting). While it's possible to wrap templated device-wide function calls, I wondered if there was a reasonable way to support the block and warp-wide algorithms, which are defined by templating Trait/Policy classes?

As I understand numba, it only supports the CUDA python specification, so supporting templated C++  code in a python style does not seem obvious to me. However, I don't fully understand numba's internal typing mechanism, so it isn't clear to me whether its easy to extend the CUDA python spec, or via some extension in a user library.



user: sjperkins
labels: CUDA: CUDA related issue/PR
issue_3195: state: open
title: Problems with support_literals and the Const type
body: The ability to propagate constness info into the typer and the lowering is added in https://github.com/numba/numba/pull/2482/commits/dfe41e6d7a444cef4c74767c21f959ac3f2e9ddc and later enhanced to be less hacky in https://github.com/numba/numba/pull/2503 by introducing the `support_literals` option in the typing template.  However, the handling of the `Const` type is still not coherent with the handling of other types, causing issue as observed in https://github.com/numba/numba/pull/3162#issuecomment-409429680.  We need to come up with a better way to propagate this constant info through the compiler pipeline.
user: sklam
issue_3184: state: open
title: Equivalent to functools.partial or caching compiled closures
body: ## Feature request
Hi! It'd be nice to have support for "cached" compiled closures. Currently, every function returned from a closure is a different Python object so it isn't usually cached, or compiled once per run. Instead, it's compiled every time a new closure is generated.

For example, consider the simple case of a parameterized differential equation. Solving the equation is easy, we can simply use a closure to generate the compiled function, capturing all variables but `t` and `y`, and then use a Ctypes pointer to pass it to SciPy.

But now consider that we want to solve the same equation hundreds of times with different parameters. In this case, the Numba compilation takes up most of the time for a simple-enough differential equation, and in some cases this is even slower than simply using pure Python.

This can be handled in one of two ways,

1. Provide a way to create a Numba-compiled `functools.partial`. This should be a lot faster than compiling the entire function, and may even be some pre-compiled or cached function doing some magic with the stack before passing the variables on.
2. Cache closures/determine if something is the same in a closure, and just capture the right variables. This would be more complex as some logic might need to be written in order to compare code, or check static-ness of the code, etc.

I personally prefer the `functools.partial` solution.
user: hameerabbasi
labels: caching: Issue involving caching
issue_3182: state: open
title: numpy structured arrays are not working with numpy arrays as elements in nopython mode.
body: _Actually not sure is this a bug or feature request._

Using numpy arrays as elements of structured arrays is not working in `jit(nopython=True)` functions.
```python
@jit(nopython=True)
def func(s):
    p = 0
    for i in range(s.shape[0]):
        p += s[i][1][:s[i][0]].sum()
    return p

func(np.array([(20, 10)]*100, dtype='i4,(100)i4'))
```
As i understand there is no actual passing numpy array by reference and this example is something like passing 100x101 element array.

user: rantrave-git
issue_3175: state: open
title: Support scalars in `np.sum`
body: This does not work because scalars in `np.sum()` are not supported.

```python
from numba import njit
import numpy as np

@njit
def foo(x):
    return np.sum(x)

foo(10)
```

user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_3170: state: open
title: Typing of np.empty_like is not extensible
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Typing of `np.empty_like` (and similar functions) assumes that input is scalar if it is not an array [here](https://github.com/numba/numba/blob/master/numba/typing/npydecl.py#L524), without error checking. This prevents extending support for other array_like types (e.g. list, series). Any ideas how to check for supported scalars?
user: ehsantn
issue_3163: state: open
title: @jit for generic jitclasses
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
This is a suggestion for generic jitclasses that can hold data of different types, based on constructor parameters (alternative to #3020). Example below. Since constructor is a jitted function, this sort of type specialization seems doable.

```python
@jit
class Foo(object):
    def __init__(self, a, b):
        self.a = a
        self.b = b

@jit
def f():
  Foo(1, 2)  # a and b will be integers
  Foo(1.0, 2.0)  # a and b will be floats
```
user: ehsantn
issue_3155: state: open
title: parfors hoist set item fail
body: On the build farm, the latest builds of master 5215237 have failures for:
```
test_parfor_hoist_setitem (numba.tests.test_parfors.TestParfors)
```
guessing that #3089 is the root cause. Fails so far have appeared on w64 and power8. The error message is like:
```
======================================================================
FAIL: test_parfor_hoist_setitem (numba.tests.test_parfors.TestParfors)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<path>numba/tests/test_parfors.py", line 1133, in test_parfor_hoist_setitem
    self.check(test_impl, out)
  File "<path>numba/tests/test_parfors.py", line 462, in check
    self.check_parfors_vs_others(pyfunc, cfunc, cpfunc, *args, **kwargs)
  File "<path>numba/tests/test_parfors.py", line 144, in check_parfors_vs_others
    np.testing.assert_almost_equal(parfor_output, py_expected, **kwargs)
  File "<path>numpy/testing/nose_tools/utils.py", line 581, in assert_almost_equal
    raise AssertionError(_build_err_msg())
AssertionError: 
Arrays are not almost equal to 7 decimals
 ACTUAL: 256.0
 DESIRED: 1024.0
```
sometimes ACTUAL is, 128 or 512, too.

CC @DrTodd13 
user: stuartarchibald
issue_3143: state: open
title: np.empty support list type in argument
body: ```python
import numpy as np
import numba as nb

tupleShape = nb.njit(lambda N: np.zeros((N,N)))
listShape = nb.njit(lambda N: np.zeros([N,N]))

tupleShape(10)  # fine
listShape(10)  # TypingError: Failed at nopython (nopython frontend)
               # Invalid usage of Function(<built-in function zeros>) with parameters (list(int64))
               #  * parameterized
               # In definition 0:
               #     All templates rejected
               # [1] During: resolving callee type: Function(<built-in function zeros>)
               # [2] During: typing of call at <ipython-input-3-94d204f55617> (5)
```

I know it should be a small issue, anyone comes across it can resolve by simply altering his code a little bit. But for those used to MATLAB, the small issue is just annoying.
user: ZeppLu
issue_3140: state: open
title: Jupyter integration.  Output compiler log, diagnostic info, etc.. 
body: There's a open PR in Jupyter, https://github.com/jupyter/jupyter_client/issues/376, that adds support for transient data.  In its description, example transient data includes:

> 1. Status/Progress information. For calculations that take a long time to execute, the kernel might want to send some progress information to the frontend.
> 2. Debug information. A kernel might want to output more verbose information under certain debug mode. The information can be long and are not meant to be saved with the notebook.
> 3. Side effect of calculation. In addition to regular result, a kernel might want to output some information about the result. As an extreme example, after the execution of a=1 that does not produce any real output, the kernel might want to display the value of a as a side effect of the calculation.

Numba can print compilation progress, inspection, diagnostic info, etc..


user: sklam
issue_3138: state: open
title:  Access the global variable defined in other modules
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--



-->

The JIT function can access the global variables defined in the current module, and functions defined in other modules. However, when trying to access global variables defined in other modules using module_name.variable_name, there is a compiling error.

'NoneType' object has no attribute 'module'
user: goduck777
issue_3130: state: open
title: Getting Thread IDs in prange
body: ## Feature request
When using prange it would be nice to be able to access the Thread_IDs. 

Some problems are most trivially solver by assigning a generator to each thread, ex. in the case of random number generators. By being able to assign a generator per thread, there is no worry about thread safety. 
Ofc. being able to do this has a minimum requirement of being able to access thread IDs, why I think this would be a nice feature.


user: erikkjellgren
issue_3123: state: open
title: np.nditer erroneously works on 0 size arrays
body: Reproducer:
```python
import numpy as np
from numba import njit

def foo(arry):
    it = np.nditer(arry)
    for view in it:
        v = view.item()
    return v


print(njit(foo)(np.array([])))
print(foo(np.array([])))
```
the jitted function returns `0.0`, the non-jitted function raises from NumPy internals.
user: stuartarchibald
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_3120: state: open
title: ndarray.flat does not support setitem
body: Following on from https://github.com/numba/numba/issues/3117, `setitem` on `flat` does not work.

```python
from numba import njit
import numpy as np
@njit
def flat(X, d):
    N = X.shape[0]
    X.flat[:N**2:N+1] = d

d = 10
X = np.ones((5, 5))
flat(X, d)
```
gives:
```
$ python foo2.py 
Traceback (most recent call last):
  File "<path>/numba/errors.py", line 595, in new_error_context
    yield
  File "<path>/numba/lowering.py", line 254, in lower_block
    self.lower_inst(inst)
  File "<path>/numba/lowering.py", line 358, in lower_inst
    return self.lower_setitem(inst.target, inst.index, inst.value, signature)
  File "<path>/numba/lowering.py", line 416, in lower_setitem
    impl = self.context.get_function('setitem', signature)
  File "<path>/numba/targets/base.py", line 537, in get_function
    return self.get_function(fn, sig, _firstcall=False)
  File "<path>/numba/targets/base.py", line 539, in get_function
    raise NotImplementedError("No definition for lowering %s%s" % (key, sig))
NotImplementedError: No definition for lowering setitem(array.flat(array(float64, 2d, C)), slice<a:b:c>, array.flat(array(float64, 2d, C))) -> none

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "foo2.py", line 10, in <module>
    flat(X, d)
  File "<path>/numba/dispatcher.py", line 368, in _compile_for_args
    raise e
  File "<path>/numba/dispatcher.py", line 325, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "<path>/numba/dispatcher.py", line 653, in compile
    cres = self._compiler.compile(args, return_type)
  File "<path>/numba/dispatcher.py", line 83, in compile
    pipeline_class=self.pipeline_class)
  File "<path>/numba/compiler.py", line 881, in compile_extra
    return pipeline.compile_extra(func)
  File "<path>/numba/compiler.py", line 368, in compile_extra
    return self._compile_bytecode()
  File "<path>/numba/compiler.py", line 812, in _compile_bytecode
    return self._compile_core()
  File "<path>/numba/compiler.py", line 799, in _compile_core
    res = pm.run(self.status)
  File "<path>/numba/compiler.py", line 254, in run
    raise patched_exception
  File "<path>/numba/compiler.py", line 246, in run
    stage()
  File "<path>/numba/compiler.py", line 679, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "<path>/numba/compiler.py", line 629, in _backend
    lowered = lowerfn()
  File "<path>/numba/compiler.py", line 616, in backend_nopython_mode
    self.flags)
  File "<path>/numba/compiler.py", line 1000, in native_lowering_stage
    lower.lower()
  File "<path>/numba/lowering.py", line 173, in lower
    self.lower_normal_function(self.fndesc)
  File "<path>/numba/lowering.py", line 214, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "<path>/numba/lowering.py", line 239, in lower_function_body
    self.lower_block(block)
  File "<path>/numba/lowering.py", line 254, in lower_block
    self.lower_inst(inst)
  File "<env>/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "<path>/numba/errors.py", line 603, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "<path>/numba/six.py", line 658, in reraise
    raise value.with_traceback(tb)
  File "<path>/numba/errors.py", line 595, in new_error_context
    yield
  File "<path>/numba/lowering.py", line 254, in lower_block
    self.lower_inst(inst)
  File "<path>/numba/lowering.py", line 358, in lower_inst
    return self.lower_setitem(inst.target, inst.index, inst.value, signature)
  File "<path>/numba/lowering.py", line 416, in lower_setitem
    impl = self.context.get_function('setitem', signature)
  File "<path>/numba/targets/base.py", line 537, in get_function
    return self.get_function(fn, sig, _firstcall=False)
  File "<path>/numba/targets/base.py", line 539, in get_function
    raise NotImplementedError("No definition for lowering %s%s" % (key, sig))
numba.errors.LoweringError: Failed at nopython (nopython mode backend)
No definition for lowering setitem(array.flat(array(float64, 2d, C)), slice<a:b:c>, array.flat(array(float64, 2d, C))) -> none

File "foo2.py", line 6:
def flat(X, d):
    <source elided>
    N = X.shape[0]
    X.flat[:N**2:N+1] = d
```

user: stuartarchibald
labels: bug - ice: Bugs: internal compiler error
issue_3115: state: open
title: np.broadcast support
body: The np.broadcast function looks at the inputs and produces an object (namedtuple really) that has attributes giving the shape, size, and some iterators.

https://docs.scipy.org/doc/numpy/reference/generated/numpy.broadcast.html

Also used are the broadcast_* functions.

(This was a request from SciPy 2018)

user: seibert
issue_3112: state: open
title: Replicate NumPy scalar operations across unsigned dtypes
body: Consider

``` python
import numpy as np
import numba


def f():
    h = np.uint32(2166136261)
    return h * h


@numba.njit()
def f_numba():
    h = np.uint32(2166136261)
    return h * h


@numba.njit()
def f_numba_workaround():
    h = np.uint32(2166136261)
    return np.uint32(h * h)


print(f())
print(f_numba())
print(f_numba_workaround())
```

In all 3 functions, `h * h` should be of type `np.uint32` and an overflow should occur. However this does not happen in the _standard_ numba JIT compiled version of the function. Instead the following output is observed:

``` bash
~ python test_numba.py
test_numba.py: RuntimeWarning: overflow encountered in uint_scalars  
1850947993
4692146301219060121
1850947993
```
user: leezu
issue_3110: state: open
title: Select `@vectorize` and `@guvectorize` target at call time, not decoration time
body: It is inconvenient to have to create differently named ufuncs just to support different targets (like `cpu`, `parallel`, etc).  It would be nice to be able to set the `target` as a kwarg in the ufunc call, rather than only in the `@vectorize` decorator.

Solving this issue, unfortunately, is likely blocked on fully disentangling the ufunc machinery from NumPy's dispatcher, which would interfere with this in some cases now.

user: seibert
issue_3105: state: open
title: NUMBA_DUMP_ Environment Variables not Respected
body: Using 0.39.0, some of the environment variables for dumping LLVM information are without effect in the CUDA backend. Namely `NUMBA_DUMP_ANNOTATION`, `NUMBA_DUMP_ASSEMBLY`, `NUMBA_DUMP_LLVM`, and `NUMBA_DUMP_OPTIMIZED`.

Using the [`cuda_memory/pinned.py`](https://github.com/ContinuumIO/numbapro-examples/blob/master/cuda_memory/pinned.py) example:
```bash
$ for e in BYTECODE CFG IR ANNOTATION ASSEMBLY LLVM FUNC_OPT OPTIMIZED; do echo $e; eval "NUMBA_DUMP_$e"=1 numba pinned.py | grep -v regular | grep -v pinned | wc -l; done
BYTECODE
24
CFG
22
IR
182
ANNOTATION
0
ASSEMBLY
0
LLVM
0
FUNC_OPT
376
OPTIMIZED
0
```

Browsing the Numba source code, I see that these exact environment variables are used in [numba_entry.py:L255-257](https://github.com/numba/numba/blob/0.39.0/numba/numba_entry.py#L255-L257) and set to their command-lines alternatives. To me, this sound like a bug. IMHO they should only be set to their command-line counterparts if the counterparts themselves are defined – and even then this behaviour should be noted somewhere.

@stuartarchibald points out that this is probably an issue of the CUDA backend (https://github.com/numba/numba/issues/887#issuecomment-404823949).
user: AndiH
labels: CUDA: CUDA related issue/PR
issue_3102: state: open
title: Faster Mersenne Twister implementation?
body: Given the popularity of Numba for Monte Carlo, we might want to consider using a faster MT implementation than NumPy, since we have to put an implementation into Numba anyway.

Julia uses this: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/#dSFMT

Which seems to give much improved performance over NumPy:  http://numpy-discussion.10968.n7.nabble.com/speed-of-random-number-generator-compared-to-Julia-td44136.html

There is also this project:  https://github.com/bashtage/randomgen
user: seibert
issue_3099: state: open
title: error converting array of floats to integers
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

## Reporting a bug

Trying to convert an array of floats to an array of integers with numpy.int32(x) or numba.int32(x) givse a NotImplementedError. I would like to use the array of integers to index another array. numpy.asarray(np.int32) works fine but it does not seem computationally efficient. 

Python 3.6
numba version: 0.38.0
numpy version: 1.14.3

```python
x = np.array([1.,2.,3.], dtype=np.float32)
@numba.jit(nopython=True)
def testType(x):   
    x = np.int32(x)
    return x
x = testType(x)
```
<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->
```python-traceback
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/targets/base.py in cast(self, builder, val, fromty, toty)
    642         try:
--> 643             impl = self._casts.find((fromty, toty))
    644             return impl(self, builder, fromty, toty, val)

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/targets/base.py in find(self, sig)
     47         if out is None:
---> 48             out = self._find(sig)
     49             self._cache[sig] = out

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/targets/base.py in _find(self, sig)
     56         else:
---> 57             raise NotImplementedError(self, sig)
     58 

NotImplementedError: (<numba.targets.base.OverloadSelector object at 0x7fdcce757630>, (array(float32, 1d, C), int32))

During handling of the above exception, another exception occurred:

NotImplementedError                       Traceback (most recent call last)
~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    490     try:
--> 491         yield
    492     except NumbaError as e:

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_block(self, block)
    215                                    loc=self.loc, errcls_=defaulterrcls):
--> 216                 self.lower_inst(inst)
    217 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_inst(self, inst)
    264             ty = self.typeof(inst.target.name)
--> 265             val = self.lower_assign(ty, inst)
    266             self.storevar(val, inst.target.name)

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    410         elif isinstance(value, ir.Expr):
--> 411             return self.lower_expr(ty, value)
    412 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_expr(self, resty, expr)
    742         elif expr.op == 'call':
--> 743             res = self.lower_call(resty, expr)
    744             return res

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_call(self, resty, expr)
    708 
--> 709             res = impl(self.builder, argvals)
    710 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/targets/base.py in __call__(self, builder, args)
   1042     def __call__(self, builder, args):
-> 1043         return self._imp(self._context, builder, self._sig, args)
   1044 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/targets/builtins.py in number_constructor(context, builder, sig, args)
    252         [valty] = sig.args
--> 253         return context.cast(builder, val, valty, sig.return_type)
    254 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/targets/base.py in cast(self, builder, val, fromty, toty)
    646             raise NotImplementedError(
--> 647                 "Cannot cast %s to %s: %s" % (fromty, toty, val))
    648 

NotImplementedError: Cannot cast array(float32, 1d, C) to int32: %".28" = load {i8*, i8*, i64, i64, float*, [1 x i64], [1 x i64]}, {i8*, i8*, i64, i64, float*, [1 x i64], [1 x i64]}* %"x"

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-2-1f7ce03171dd> in <module>()
      6     return x
      7 
----> 8 x = testType(x)
      9 print(x)
     10 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    358                     e.patch_message(''.join(e.args) + help_msg)
    359             # ignore the FULL_TRACEBACKS config, this needs reporting!
--> 360             raise e
    361 
    362     def inspect_llvm(self, signature=None):

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    309                 argtypes.append(self.typeof_pyval(a))
    310         try:
--> 311             return self.compile(tuple(argtypes))
    312         except errors.TypingError as e:
    313             # Intercept typing error that may be due to an argument

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, sig)
    616 
    617                 self._cache_misses[sig] += 1
--> 618                 cres = self._compiler.compile(args, return_type)
    619                 self.add_overload(cres)
    620                 self._cache.save_overload(sig, cres)

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     81                                       args=args, return_type=return_type,
     82                                       flags=flags, locals=self.locals,
---> 83                                       pipeline_class=self.pipeline_class)
     84         # Check typing error if object mode is used
     85         if cres.typing_error is not None and not flags.enable_pyobject:

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library, pipeline_class)
    869     pipeline = pipeline_class(typingctx, targetctx, library,
    870                               args, return_type, flags, locals)
--> 871     return pipeline.compile_extra(func)
    872 
    873 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in compile_extra(self, func)
    363         self.lifted = ()
    364         self.lifted_from = None
--> 365         return self._compile_bytecode()
    366 
    367     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in _compile_bytecode(self)
    800         """
    801         assert self.func_ir is None
--> 802         return self._compile_core()
    803 
    804     def _compile_ir(self):

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in _compile_core(self)
    787         self.define_pipelines(pm)
    788         pm.finalize()
--> 789         res = pm.run(self.status)
    790         if res is not None:
    791             # Early pipeline completion

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in run(self, status)
    249                     # No more fallback pipelines?
    250                     if is_final_pipeline:
--> 251                         raise patched_exception
    252                     # Go to next fallback pipeline
    253                     else:

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in run(self, status)
    241                 try:
    242                     event(stage_name)
--> 243                     stage()
    244                 except _EarlyPipelineCompletion as e:
    245                     return e.result

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in stage_nopython_backend(self)
    674         """
    675         lowerfn = self.backend_nopython_mode
--> 676         self._backend(lowerfn, objectmode=False)
    677 
    678     def stage_compile_interp_mode(self):

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    624             self.library.enable_object_caching()
    625 
--> 626         lowered = lowerfn()
    627         signature = typing.signature(self.return_type, *self.args)
    628         self.cr = compile_result(

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in backend_nopython_mode(self)
    611                 self.return_type,
    612                 self.calltypes,
--> 613                 self.flags)
    614 
    615     def _backend(self, lowerfn, objectmode):

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags)
    988 
    989     lower = lowering.Lower(targetctx, library, fndesc, interp)
--> 990     lower.lower()
    991     if not flags.no_cpython_wrapper:
    992         lower.create_cpython_wrapper(flags.release_gil)

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower(self)
    133         if self.generator_info is None:
    134             self.genlower = None
--> 135             self.lower_normal_function(self.fndesc)
    136         else:
    137             self.genlower = self.GeneratorLower(self)

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    174         # Init argument values
    175         self.extract_function_arguments()
--> 176         entry_block_tail = self.lower_function_body()
    177 
    178         # Close tail of entry block

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_function_body(self)
    199             bb = self.blkmap[offset]
    200             self.builder.position_at_end(bb)
--> 201             self.lower_block(block)
    202 
    203         self.post_lower()

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/lowering.py in lower_block(self, block)
    214             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    215                                    loc=self.loc, errcls_=defaulterrcls):
--> 216                 self.lower_inst(inst)
    217 
    218     def create_cpython_wrapper(self, release_gil=False):

~/anaconda2/envs/ipy36/lib/python3.6/contextlib.py in __exit__(self, type, value, traceback)
     97                 value = type()
     98             try:
---> 99                 self.gen.throw(type, value, traceback)
    100             except StopIteration as exc:
    101                 # Suppress StopIteration *unless* it's the same exception that

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    497         from numba import config
    498         tb = sys.exc_info()[2] if config.FULL_TRACEBACKS else None
--> 499         six.reraise(type(newerr), newerr, tb)
    500 
    501 

~/anaconda2/envs/ipy36/lib/python3.6/site-packages/numba/six.py in reraise(tp, value, tb)
    657         if value.__traceback__ is not tb:
    658             raise value.with_traceback(tb)
--> 659         raise value
    660 
    661 else:

LoweringError: Failed at nopython (nopython mode backend)
Cannot cast array(float32, 1d, C) to int32: %".28" = load {i8*, i8*, i64, i64, float*, [1 x i64], [1 x i64]}, {i8*, i8*, i64, i64, float*, [1 x i64], [1 x i64]}* %"x"

File "<ipython-input-2-1f7ce03171dd>", line 5:
def testType(x):   
    x = np.int32(x)
    ^
[1] During: lowering "$0.4 = call $0.2(x, func=$0.2, args=[Var(x, <ipython-input-2-1f7ce03171dd> (5))], kws=(), vararg=None)" at <ipython-input-2-1f7ce03171dd> (5)
-------------------------------------------------------------------------------
This should not have happened, a problem has occurred in Numba's internals.


user: oscarportoles
issue_3092: state: open
title: ParallelAccelerator without threads
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
ParallelAccerator provides several sequential optimizations but we only advertise it as a multi-threading option (parallel=True). Should we add a new option such as `Optimize=True` that only performs optimizations without threading?

In this case, AOT and caching can be supported more easily also, since there is no need for gufuncs.
user: ehsantn
labels: AOT: ahead of time compilation issue
caching: Issue involving caching
issue_3087: state: open
title: unable to use parallel for bytearray inputs
body: ## Reporting a bug

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

when you do
```python

import numba as nb
@nb.njit(parallel=True)
def sum(arr):
    x = 0
    for i in nb.prange(len(arr)):
        x += arr[i]
    return x

sum(bytearray('ABCD'))
```

in numba 0.38.1, the following error results:
```
LoweringError: Failed at nopython (nopython mode backend)
No definition for lowering bytearray(uint8, 1d, C).shape
```

`parallel=False` does work.
user: s22chan
issue_3081: state: open
title: Segfault in NRT from use of generator
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [X] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

[Reported on gitter](https://gitter.im/numba/numba?at=5b3cfe1f60c38707835d9c20) by @igorghi:
```python
import numba
import numpy as np
 
@numba.njit
def comb_2_gen_numba_test(arr, n_batch):
    n = arr.shape[0]
    batch = np.zeros((n_batch,2),dtype=np.int32)
    c=0
    for i in range(n-1):
        for k in range(i+1,n):
            batch[c,0] = arr[i]
            batch[c,1] = arr[k]
            c+=1  
            if c%n_batch == 0:
                c=0
                yield batch
               
               
a = comb_2_gen_numba_test(np.arange(4),2)
 
for elem in a:
    print(elem)
```
this segfaults. Doing `gdb -ex r -ex bt --args python gi6.py` gives:
```
Program received signal SIGABRT, Aborted.
0x00007ffff7828277 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
#0  0x00007ffff7828277 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff7829968 in __GI_abort () at abort.c:90
#2  0x00007ffff786ad37 in __libc_message (do_abort=do_abort@entry=2, 
    fmt=fmt@entry=0x7ffff797cd58 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196
#3  0x00007ffff7873499 in malloc_printerr (ar_ptr=0x7ffff7bb8760 <main_arena>, ptr=<optimized out>, 
    str=0x7ffff797ce18 "double free or corruption (fasttop)", action=3) at malloc.c:5025
#4  _int_free (av=0x7ffff7bb8760 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3847
#5  0x00007fffdecc6fbe in NRT_MemInfo_call_dtor ()
   from <numba_path>/numba/runtime/_nrt_python.cpython-36m-x86_64-linux-gnu.so
#6  0x00007fffdecc58bd in MemInfo_dealloc ()
   from <numba_path>/numba/runtime/_nrt_python.cpython-36m-x86_64-linux-gnu.so
#7  0x00007fffeabfb919 in array_dealloc ()
   from <env_path>/lib/python3.6/site-packages/numpy/core/multiarray.cpython-36m-x86_64-linux-gnu.so
#8  0x00005555556f26f8 in call_function ()
#9  0x0000555555714cba in _PyEval_EvalFrameDefault ()
#10 0x00005555556ed459 in PyEval_EvalCodeEx ()
#11 0x00005555556ee1ec in PyEval_EvalCode ()
#12 0x00005555557689a4 in run_mod ()
#13 0x0000555555768da1 in PyRun_FileExFlags ()
#14 0x0000555555768fa4 in PyRun_SimpleFileExFlags ()
#15 0x000055555576ca9e in Py_Main ()
#16 0x00005555556344be in main ()

```
user: stuartarchibald
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_3071: state: open
title: Performance issue with lists of arrays?
body: Hello,
it's great to have lists of numpy arrays now supported in Numba!

I experimented a bit and found that Numba is slower than Numpy for short lists of large arrays but
faster than Numpy for long lists of small arrays. The timings are on a Xeon E5 with Numba 0.39RC1 installed with Conda for python 2.7:

```
srvx1{~leo/python}165 %python arraylist2.py
short list of large arrays:
Result n=50: 147563.124
Numpy Time: 0.740
Result n=50: 147563.124
Numba Time: 2.120

long list of small arrays:
Result n=500000: 14.441
Numpy Time: 7.186
Result n =500000: 14.441
Numba Time: 1.570
```

What is the reason for Numba being slower than Numpy in the first example? My use case is more like the first example. 

The reproducer, which is really just for testing:

```python
# -*- coding: utf-8 -*-
"""
Created on Thu Jun 28 18:45:46 2018

@author: Leo
"""

import numpy
from numba import *
import time


def uselist(al):
    lens=numpy.empty(len(al))
    for i in range(len(al)):
        al[i][:,:]*=i
        lens[i]=al[i].shape[1]
        
    return numpy.std(lens)

def genlist(lens):
    al=[]
    for i in range(lens.shape[0]):
        al.append(numpy.zeros((16,lens[i]))+1.0)
    
    return uselist(al)

@njit
def nuselist(al):
    lens=numpy.empty(len(al))
    for i in range(len(al)):
        al[i][:,:]*=i
        lens[i]=al[i].shape[1]
        
    return numpy.std(lens)

@njit
def ngenlist(lens):
    al=[]
    for i in range(lens.shape[0]):
        al.append(numpy.zeros((16,lens[i]))+1.0)
    
    return nuselist(al)


print ('short list of large arrays:')

n=50
m=500000
lens=numpy.random.randint(m,size=n)
al=ngenlist(lens)

for it in range(1):
    t=time.time()
    print('Result n={}: {:5.3f}'.format(n, genlist(lens)))
    print('Numpy Time: {:5.3f}'.format(time.time()-t))

for it in range(1):
    t=time.time()
    print('Result n={}: {:5.3f}'.format(n, ngenlist(lens)))
    print('Numba Time: {:5.3f}'.format(time.time()-t))

print("")
print ('long list of small arrays:')

n=500000
m=50
lens=numpy.random.randint(m,size=n)

for it in range(1):
    t=time.time()
    print('Result n={}: {:5.3f}'.format(n,genlist(lens)))
    print('Numpy Time: {:5.3f}'.format(time.time()-t))

for it in range(1):
    t=time.time()
    print('Result n ={}: {:5.3f}'.format(n,ngenlist(lens)))
    print('Numba Time: {:5.3f}'.format(time.time()-t))


```
user: leohaim
labels: performance - run time: Performance issue occurring at run time.
issue_3070: state: open
title: np.median doesn't support read-only arrays
body: np.median implementation in Numba doesn't support read-only arrays, while non-jitted version does. When I launch the snippet below

```python
import numpy as np
from numba import jit

@jit(nopython=True)
def median(arr):
    return np.median(arr)

x = np.random.random(100)
x.setflags(write=False)

median(x)
```

 I got an error
```
TypeError: Cannot modify value of type readonly array(float64, 1d, C)
```

My setup:
- Python 3.5.2 (Anaconda)
- numba==0.38.1
- numpy==1.14.2
user: EmptySamurai
issue_3068: state: open
title: Document  that using plain np.float (and maybe others) is not supported yet.
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!



-->
I ran into this weird error when trying to use np.empty in a function definition compiled with numba, and turning on nopython=True to make sure optimized typing is in effect. It's weird because numba claims to support np.empty with the first two arguments, and I am only using the first two arguments (correctly I think?), so I don't know why it's not typing correctly.

    @jit(nopython=True)
    def empty():
        return np.empty(5, np.float)

After defining the above function in an ipython notebook,

    empty()

Gives the following error message:

    ---------------------------------------------------------------------------
    TypingError                               Traceback (most recent call last)
    <ipython-input-88-927345c8757f> in <module>()
    ----> 1 empty()
    
    ~/.../lib/python3.5/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
        342                 raise e
        343             else:
    --> 344                 reraise(type(e), e, None)
        345         except errors.UnsupportedError as e:
        346             # Something unsupported is present in the user code, add help info
    
    ~/.../lib/python3.5/site-packages/numba/six.py in reraise(tp, value, tb)
        656             value = tp()
        657         if value.__traceback__ is not tb:
    --> 658             raise value.with_traceback(tb)
        659         raise value
        660 
    TypingError: Failed at nopython (nopython frontend)
    Invalid usage of Function(<built-in function empty>) with parameters (int64, Function(<class 'float'>))
     * parameterized
    In definition 0:
        All templates rejected
    [1] During: resolving callee type: Function(<built-in function empty>)
    [2] During: typing of call at <ipython-input-87-8c7e8fa4c6eb> (3)
    
    
    File "<ipython-input-87-8c7e8fa4c6eb>", line 3:
    def empty():
        return np.empty(5, np.float)
        ^
    
    This is not usually a problem with Numba itself but instead often caused by
    the use of unsupported features or an issue in resolving types.
    
    To see Python/NumPy features supported by the latest release of Numba visit:
    http://numba.pydata.org/numba-doc/dev/reference/pysupported.html
    and
    http://numba.pydata.org/numba-doc/dev/reference/numpysupported.html
    
    For more information about typing errors and how to debug them visit:
    http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile
    
    If you think your code should work with Numba, please report the error message
    and traceback, along with a minimal reproducer at:
    https://github.com/numba/numba/issues/new

user: frstyang
issue_3061: state: open
title: Generator iterator fails from within NPM function if created outside the NPM function
body: ## Feature request (but possibly a bug?)

Note: I'm using numba 0.38.0 in Python 2.7.12

Creating the generator iterator from a generator within the nopython function, then calling it within that function, works:
```python
@njit
def gen():
    for _ in range(10):
        yield np.random.rand(5)

@njit
def callit():
    g = gen()
    return next(g)

callit() # succeeds
```

But creating the generator iterator from the generator _outside_ the nopython function that calls it fails:
```python
@njit
def gen():
    for _ in range(10):
        yield np.random.rand(5)

g = gen()

@njit
def callit():
    return next(g)

callit() # fails
```
With error message:
```
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-68-05f5a5c324b2> in <module>()
     10     return next(g)
     11 
---> 12 callit()

/home/justin/anaconda2/lib/python2.7/site-packages/numba/dispatcher.pyc in _compile_for_args(self, *args, **kws)
    342                 raise e
    343             else:
--> 344                 reraise(type(e), e, None)
    345         except errors.UnsupportedError as e:
    346             # Something unsupported is present in the user code, add help info

/home/justin/anaconda2/lib/python2.7/site-packages/numba/six.pyc in reraise(tp, value, tb)

TypingError: Failed at nopython (nopython frontend)
Untyped global name 'g': cannot determine Numba type of <type '_dynfunc._Generator'>

File "<ipython-input-68-05f5a5c324b2>", line 10:
def callit():
    return next(g)
    ^
```

this use case would be helpful for being able to do costly (CPU and/or memory) initialization within the function using arguments that are difficult for numba to handle, and I think it makes the code quite clean.

My specific use case is that I want to initialize a fixed number of nopython-mode generators where the user can provide these to my function (note that each generator requires different arguments for its initialization, so their arguments have to be handled outside of nopython code). These generators are then handed to my nopython function that just calls `next(gen0)`, `next(gen1)`, etc.

The best alternative I see would be to use a factory function to define a nopython mode function after the initialization is performed in "regular" Python that then bakes-in the (potentially large) results of the initialization at the time it is compiled. While this works, it would be nice to be able to achieve this the more "straightforward" way.
user: jllanfranchi
issue_3043: state: open
title: jitclass cffi pointer
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Similar to how cfunc.cffi generates function pointers for use with cffi
It would be very useful for jitclasses to be transformable to/from cffi void* pointers
This would be especially useful for cffi libraries that take callback func and a void* userdata
The userdata could be a jitclass, offering structured data for free in both the interpreter and "c" context

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

user: wrongbad
issue_3036: state: open
title: Cannot reference njit static methods from no-python code.
body: ## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [*] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [*] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

```
class X1(object):

    @staticmethod
    @numba.njit
    def f():
        return X1.g()  # Not allowed, even though referencing a simple numba function.

    @staticmethod
    @numba.njit
    def g():
        return 99


@numba.njit
def a():
    return X1.g()

print X1.g() # OK
print a() # Fail
print X1.f() # Fail
```

Although it can be determined that 'X1.g' is a reference to numba function that numba *could* deal with in no-python mode, it doesn't seem that it currently works.

Not sure if this is a bug, or a request for a new feature. Currently, I have to move these static functions into the global namespace to work around it.

I would think this is (almost) already possible since its already possible to reference globals (literals) by name in numba functions. The difference here is referencing a global class, and the reference to X1 is known to be a class reference by the time the function is compiled.

Feasibly, numba could rewrite:
```
<class reference> <'.'> <method_name> ==>  function_ref("#classname_method_name") 
```
... or more generally (or something of general that allows nested (but statically resolvable references). For example:  X1.attribute_of_type_class.OtherInnerClass.g_numba_function is statically resolvable reference when it appears in numba dectorated function. 


user: stuz5000
issue_3030: state: open
title: Support builtins in @overload
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
High-level extension APIs such as `@overload` should support builtin operators (e.g. `setitem`, `in`). Feature parity with low-level extension APIs in general is desirable.
user: ehsantn
issue_3020: state: open
title: Support for generics.
body: ## Feature request

Currently, I don't think its possible to have a template jitclass. For example, in the 

  https://github.com/numba/numba/blob/master/examples/stack.py

... the Stack class can only be instantiated to a single element type (in the example, an int).

It would be nice to be able to re-use the stack class for multiple element types:

Something like this:

```
  IntStackClass = Stack(elemtype=int) # A template class is function (type params ...)->class
  IntStackClass = Stack.instantiate(elemtype=int)
  IntStackClass = numba.instantiate_types(StackTemplate, elemtype=int )
  ...
  IntStackClass().push(1)
```

We can already do this by wrapping the creation of the stack class in a function who's parameter is elemtype. However, this isn't particularly nice since:

 - it makes the Stack class undocumented when its defined within a function
 - is rather inefficient since we're creating a Stack class object over and over for each call and additional memoization is required to prevent this,

Perhaps:
```
  @jitclass_template(
      template_type=("elemtype"),
      spec=( ("head": deferred_type()),
                  ("size": numba.intp),
  )
  class Stack(object)
      def __init__():
          self.head = None
          self.size=0

     def push():   
          if self.head is None:
                 self.head = LinkedNode(Stack.elemtype)()  # Template instantiation reduce to LinkedNode#<elemtype>()

          ...

```

user: stuz5000
issue_3018: state: open
title: Recursive calls raise errors with @jitclass (but not @jit)
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [*] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG). **numba-0.38.1**

- [*] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

```
@numba.jit
def x(i):
    if i>0:
        x(i-1)

@numba.jitclass(())
class C(object):
    def __init__(self):
        pass

    def x(self, i):
        if i>0:
            self.x(i-1)
x(6) # OK
C().x(6)  # Fail
```

Since recursive calls work for @jit functions, I'd think they'd work for @jitclass methods. Instead they raise:

```  InternalError: Failed at nopython (nopython frontend)
  compiler re-entrant to the same function signature
```

user: stuz5000
issue_3014: state: open
title: Mishandling of boolean representation in external function
body: 
## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [ ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

The `.call_external_function` https://github.com/numba/numba/blob/f9089c2dc5c70a31fd5539ec2696810e79198c14/numba/targets/base.py#L699-L703 should convert the return-value from the function back to local-value representation using https://github.com/numba/numba/blob/f9089c2dc5c70a31fd5539ec2696810e79198c14/numba/targets/base.py#L597-L601.


user: sklam
issue_3013: state: open
title: Set "in" Operator Produces Wrong Output
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [ ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

The output of `in` operator for sets is wrong if the checked value's type is different than element types. I'm using the latest master.

```python
In [7]: @numba.njit
   ...: def f():
   ...:     a = set((1,3))
   ...:     return 1.1 in a
   ...: 

In [8]: f()
Out[8]: True
```
user: ehsantn
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_3010: state: open
title: Refactor optional type returning into part of callconv
body: https://github.com/numba/numba/pull/3009 fixes an issue of optional type handling in recursive call but it reveals a need for refactoring to move the optional type handling into the call-convention code instead.
user: sklam
issue_3003: state: open
title: Reduce CUDA launch overhead
body: As noted on the Numba mailing list, the overhead for launching a CUDA kernel is rather high.   Some benchmarking of different size add kernels indicates that:

Numba launch overhead: 200 us
CuPy launch overhead: 25 us

(Test system is Intel(R) Core(TM) i7-4820K CPU @ 3.70GHz, Ubuntu 16.04, CUDA 9.0, Numba 0.39dev)

We should profile the kernel launch process to see where the time is going.
user: seibert
labels: CUDA: CUDA related issue/PR
performance - run time: Performance issue occurring at run time.
issue_2996: state: open
title: Consider adding polly to LLVM builds
body: As title. URL: https://polly.llvm.org/
user: stuartarchibald
labels: llvm: LLVM related issues
issue_2995: state: open
title: Support passing in LowLevelCallable as argument to jitted function
body: With the recent support for passing in numba jitted functions as arguments (https://github.com/numba/numba/pull/2801), it would also be nice to also support passing in [`scipy.LowLevelCallable`](https://docs.scipy.org/doc/scipy/reference/generated/scipy.LowLevelCallable.html) objects. These have become common in the scipy ecosystem, and would be useful for downstream projects considering numba adoption.
user: jcrist
issue_2994: state: open
title: Support for PEP 3102 Keyword-only arguments in nopython-mode in nested functions
body: Keyword only arguments, as introduced in [PEP 3102](https://www.python.org/dev/peps/pep-3102/) does not seem to be fully supported in nopython mode.
Imho keyword-only arguments are a really nice feature to reduce the error-probability, especially when there are multiple persons working on the code.
A short example:
```
@nb.njit
def kwoarg(*, a, b, c):
    return a + b / c

@nb.njit
def wrap_kwoarg(e, f, g):
    return na(a=e, b=f, g=c)  # not working
    # return na(e, f, g)  # this is also not working
```
While `kwoarg` can be called with keyword-only arguments like `kwoarg(b=7., c=2., a=5.2)` AND also with positional arguments like `kwoarg(5.2, 7., 2.)` (which shouldn't be working anyways), you can't nest `kwoarg` in another njit-function.
Calling `wrap_kwoarg` it does neither matter how the arguments are passed on to `kwoarg`, nor if `wrap_kwoarg` is defined as a keyword-only argument function itself.
Is there any plan to support this feature in the near future? From looking at other keyword related issues like [#1154](https://github.com/numba/numba/issues/1154) this seems to be a quite complicated task...

edit:
I just stumbled upon [2916](https://github.com/numba/numba/issues/2916). I guess the underlying problem is the same?
user: JoElfner
issue_2991: state: open
title: numba.vectorize does not preserve function attributes
body: MWE:

```python
from numba import vectorize

def foo(x):
    return x + x ** 2

foo.bar = 'baz'

foo_vec = vectorize(foo)

print(foo_vec.name)
>>> AttributeError: 'DUFunc' object has no attribute 'name'
```

`jit` does preserve attributes, so this bug is specific to vectorize.  The attribute could be accessed through `.__wrapped__`,
```python
print(foo_vec.__wrapped__.bar
>>> 'baz'
```
user: brandondube
issue_2988: state: open
title: Support For CPU Atomics
body: ## Feature request

It would be great if there were a way to use atomic operations from within numba. Currently atomic operations are only supported when generating cuda or HSA code.

I'm currently experimenting with using numba to write callbacks that are provided to a C++ concurrency library. In this context, atomics are useful in that they can reduce the amount of synchronization required (or to write the locks that are actually being used). You can technically use atomic operations now if you hide them inside a function pointer exported from C++, but the performance impacts of doing so aren't clear to me. At first glance, preventing inlining seems like a high price to pay for every atomic operation.

With regards to what would be the most useful, weak memory consistency is by far the most common thing that shows up in the applications I'm looking at right now, but what's needed is application specific in general. Other consistencies could potentially be useful to me for being able to acquire/release existing locks without having to route everything through an externally compiled function, but that's more of a secondary concern at the moment.
user: insertinterestingnamehere
issue_2987: state: open
title: cuda.mapped_array slices don't have a gpu_data attribute
body: ## Reporting a bug

- [x ] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x ] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

### Minimal repro

```python
import numba.cuda as cuda
@cuda.jit
def output_one(x):
    x[0] = 1

arr = cuda.mapped_array(2)
output_one(arr[:1])
```
causes

```python
numba/cuda/cudadrv/devicearray.py", line 154, in device_ctypes_pointer
    if self.gpu_data is None:
AttributeError: 'MappedNDArray' object has no attribute 'gpu_data'
```

Working with the full array works as expected.

As an addendum, split also fails, but due to a missing stream attribute. Manually setting the stream argument in the split call will lower utilization for some reason.
user: s22chan
labels: CUDA: CUDA related issue/PR
issue_2982: state: open
title: How best to parallelize numba.stencil operations
body: In https://numba.pydata.org/numba-doc/dev/user/stencil.html#numba-stencil it says the following:

>  Thus, the stencil decorator allows clearer, more concise code and in conjunction with the parallel jit option enables higher performance through parallelization of the stencil execution.

However, my naive attempt to use the `parallel=True` keyword with `numba.stencil` has failed:

```python
In [1]: import numba

In [2]: @numba.stencil(parallel=True)
   ...: def f(x):
   ...:     return (x[-1, -1] + x[-1, 0] + x[-1, 1] + x[0, -1] + x[0, 0] + x[0, 1] + x[1, -1] + x[1, 0] + x[1, 1]) 
   ...: / 9
   ...: 
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-2-9fe53b83f8a0> in <module>()
----> 1 @numba.stencil(parallel=True)
      2 def f(x):
      3     return (x[-1, -1] + x[-1, 0] + x[-1, 1] + x[0, -1] + x[0, 0] + x[0, 1] + x[1, -1] + x[1, 0] + x[1, 1]) / 9

~/Software/anaconda/lib/python3.6/site-packages/numba/stencil.py in stencil(func_or_mode, **options)
    722     for option in options:
    723         if option not in ["cval", "standard_indexing", "neighborhood"]:
--> 724             raise ValueError("Unknown stencil option " + option)
    725 
    726     wrapper = _stencil(mode, options)

ValueError: Unknown stencil option parallel
```

What is the right way to parallelize stencil operations?  If I've missed documentation on this I apologize.
user: mrocklin
issue_2981: state: open
title: Numba.stencil lacks a docstring
body: The numba.stencil function seems quite useful.  I was a bit curious about how best to use it and so, as per usual, I went first to the docstring, which unfortunately doesn't exist:

```python
In [1]: import numba

In [2]: numba.stencil?
Signature: numba.stencil(func_or_mode='constant', **options)
Docstring: <no docstring>
File:      ~/Software/anaconda/lib/python3.6/site-packages/numba/stencil.py
Type:      function
```

I see that there is some nice documentation online.  Perhaps some concise subset of it could make its way into the docstring for interactive use?
user: mrocklin
issue_2979: state: open
title: Support duck arrays in numba gufuncs
body: There might be some room for improvement in handling numpy-like arrays in numba-generated gufuncs

I was quite happy to see this work well:

```python
In [1]: from numba import vectorize, float64
   ...: 
   ...: @vectorize([float64(float64, float64)])
   ...: def f(x, y):
   ...:     return x + y
   ...: 

In [2]: import dask.array as da

In [3]: x = da.arange(10, chunks=(5,))

In [4]: f(x, x)  # hooray!
Out[4]: dask.array<f, shape=(10,), dtype=float64, chunksize=(5,)>
```

Unfortunately this didn't fare as well.  Am I using vectorize incorrectly or is this a feature request?

```python
In [5]: @vectorize
   ...: def f(x, y):
   ...:     return x + y
   ...: 

In [6]: f(x, x)  # oh no!
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-6-4438cca8adef> in <module>()
----> 1 f(x, x)  # oh no!

~/Software/anaconda/lib/python3.6/site-packages/numba/npyufunc/dufunc.py in _compile_for_args(self, *args, **kws)
    162                 argtys.append(numpy_support.map_arrayscalar_type(arg))
    163             else:
--> 164                 argty = typeof(arg)
    165                 if isinstance(argty, types.Array):
    166                     argty = argty.dtype

~/Software/anaconda/lib/python3.6/site-packages/numba/typing/typeof.py in typeof(val, purpose)
     29     if ty is None:
     30         msg = "cannot determine Numba type of %r" % (type(val),)
---> 31         raise ValueError(msg)
     32     return ty
     33 

ValueError: cannot determine Numba type of <class 'dask.array.core.Array'>
```

user: mrocklin
issue_2975: state: open
title: Planning for end of NVVM text IR support
body: For the past few CUDA releases, NVVM has supported IR input either in LLVM 3.4 text IR format or LLVM [later version] bitcode IR format.  As of CUDA 9.2, the bitcode IR format is based on LLVM 5.0.  Numba so far has been able to rely on llvmlite's pure-Python IR builder implementation to generate text IR for both CPU and GPU targets and then apply some regular expression transforms to convert from the current LLVM IR version (6.0 at this point) to version 3.4 for NVVM.

There have been warnings in the last few CUDA releases that the text IR option (which has not been update for some time) is deprecated and will be dropped in a future CUDA release. See [nvvmAddModuleToProgram](https://docs.nvidia.com/cuda/libnvvm-api/group__compilation.html#group__compilation_1g0c22d2b9be033c165bc37b16f3ed75c6), for an example.

This issue is to discuss how to deal with this inevitable deprecation.

---

The main constraints on our solution are:
* Generating bitcode of the required format directly from the llvmlite builder API is likely a non-starter.
* In general, it is unlikely that the LLVM we use for CPU targets (which we now update fairly frequently) will align with the version of LLVM bitcode accepted by NVVM (which updates on a much more lagged schedule).
* I don't think it is possible to get LLVM to generate bitcode in the format accepted by an older LLVM.  (For example 6.0 -> 5.0.)  However, if I am mistaken, then this becomes a lot easier.

Given all of the above, I suspect  the solution we will end up with is packaging just the bitcode writer from LLVM 5.0 so we can call it to convert LLVM 5.0 compatible text IR to bitcode before passing it to NVVM.

Is there an easier approach?
user: seibert
labels: CUDA: CUDA related issue/PR
issue_2974: state: open
title: Autogenerate sphinx autodoc docs on Master
body: ## Feature request

Numba needs better code documentation and I feel a good way to motivate contributions is to maintain current Sphinx docs that are accessible via the website.
Travis-CI supports autogeneration of the docs: https://github.com/Syntaf/travis-sphinx
user: innovate-invent
labels: discussion: An issue requiring discussion
issue_2971: state: open
title: Recursive function with optional types
body: Using python 3.6 and numba 0.39.0dev0+18.g2757c83 from the numba channel.

I was attempting to see if I could adapt the python code in the following benchmark to use numba:

https://github.com/frol/completely-unscientific-benchmarks/tree/master/python

Starting with just the first piece, I ran into an issue. The code below:

```python
from collections import OrderedDict
import random

import numba as nb


node_type = nb.deferred_type()
opt_node_type = nb.optional(node_type)
node_spec = OrderedDict([('x', nb.int32), ('y', nb.int32), ('left', opt_node_type), ('right', opt_node_type)])


@nb.jitclass(node_spec)
class Node:

    def __init__(self, x):
        self.x = x
        self.y = random.randint(0, 2**31)
        self.left = None
        self.right = None


node_type.define(Node.class_type.instance_type)


@nb.jit((opt_node_type, opt_node_type), nopython=True)
def merge(lower, greater):
    if lower is None:
        return greater

    if greater is None:
        return lower

    if lower.y < greater.y:
        tmpl = merge(lower.right, greater)
        lower.right = tmpl
        return lower
    else:
        tmpg = merge(lower, greater.left)
        greater.left = tmpg
        return greater

```

produces the following error:

```python-traceback
Traceback (most recent call last):
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/errors.py", line 491, in new_error_context
    yield
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/lowering.py", line 216, in lower_block
    self.lower_inst(inst)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/lowering.py", line 266, in lower_inst
    self.storevar(val, inst.target.name)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/lowering.py", line 950, in storevar
    raise AssertionError(msg)
AssertionError: Storing %"deferred.4393458824.value" to ptr of {%"deferred.4393458824.value", i1} ('$52.5'). FE type ?DeferredType#4393458824

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test1.py", line 25, in <module>
    @nb.jit((opt_node_type, opt_node_type), nopython=True)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/decorators.py", line 198, in wrapper
    disp.compile(sig)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/dispatcher.py", line 618, in compile
    cres = self._compiler.compile(args, return_type)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/dispatcher.py", line 83, in compile
    pipeline_class=self.pipeline_class)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 871, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 365, in compile_extra
    return self._compile_bytecode()
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 802, in _compile_bytecode
    return self._compile_core()
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 789, in _compile_core
    res = pm.run(self.status)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 251, in run
    raise patched_exception
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 243, in run
    stage()
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 676, in stage_nopython_backend
    self._backend(lowerfn, objectmode=False)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 626, in _backend
    lowered = lowerfn()
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 613, in backend_nopython_mode
    self.flags)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/compiler.py", line 990, in native_lowering_stage
    lower.lower()
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/lowering.py", line 135, in lower
    self.lower_normal_function(self.fndesc)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/lowering.py", line 176, in lower_normal_function
    entry_block_tail = self.lower_function_body()
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/lowering.py", line 201, in lower_function_body
    self.lower_block(block)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/lowering.py", line 216, in lower_block
    self.lower_inst(inst)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/errors.py", line 499, in new_error_context
    six.reraise(type(newerr), newerr, tb)
  File "/Users/zzz/anaconda/envs/treap/lib/python3.6/site-packages/numba/six.py", line 659, in reraise
    raise value
numba.errors.LoweringError: Failed at nopython (nopython mode backend)
Storing %"deferred.4393458824.value" to ptr of {%"deferred.4393458824.value", i1} ('$52.5'). FE type ?DeferredType#4393458824

File "test1.py", line 34:
def merge(lower, greater):
    <source elided>
    if lower.y < greater.y:
        tmpl = merge(lower.right, greater)
        ^
[1] During: lowering "$52.5 = call $52.1($52.3, greater, func=$52.1, args=[Var($52.3, test1.py (34)), Var(greater, test1.py (27))], kws=(), vararg=None)" at test1.py (34)
```

I'm wondering if I'm running into some limitation of using optional types with recursive functions or if I'm doing something incorrect, or if I've possibly found a bug. 



user: synapticarbors
issue_2964: state: open
title: @{gu,}vectorize docs should mention promotion/dispatch behaviours.
body: Following on from https://github.com/numba/numba/issues/2934, https://numba.pydata.org/numba-doc/dev/user/vectorize.html ought to mention NumPy type promotion/dispatch behaviours.

user: stuartarchibald
issue_2956: state: open
title: Passing a jitted function reference to a jitted function makes cache=True fail
body: ## Reporting a bug

- [x] I am using the latest released version of Numba (0.38) (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).


If one passes a reference to a njitted function into another njitted function which has caching enabled,
caching fails when attempting to pickle a `weakref`. In the example below, `fn` is assigned to one of two njitted functions and passed through to njitted function `_adder` which has `cache=True` in it's decorator..

```python
from __future__ import print_function

import numpy as np
import numba

@numba.jit(nogil=True, cache=True)
def combine_1(x, y):
    return x + y

@numba.jit(nogil=True, cache=True)
def combine_2(x, y):
    return x - y


@numba.njit(nogil=True, cache=True)
def _adder(arr1, arr2, fn):
    acc = 0.0
    for x, y in zip(arr1, arr2):
        acc += fn(x, y)

    return acc

def adder(arr1, arr2):
    if arr1.size < 10:
        fn = combine_1
    else:
        fn = combine_2

    return _adder(arr1, arr2, fn)

print(adder(np.arange(5), np.arange(5)))
```

This produces the following error:

```python-traceback
Traceback (most recent call last):
  File "test_jit_cache_fail.py", line 31, in <module>
    print(adder(np.arange(5), np.arange(5)))
  File "test_jit_cache_fail.py", line 29, in adder
    return _adder(arr1, arr2, fn)
  File "/home/sperkins/venv/afr/local/lib/python2.7/site-packages/numba/dispatcher.py", line 360, in _compile_for_args
    raise e
cPickle.PicklingError: Can't pickle <type 'weakref'>: attribute lookup __builtin__.weakref failed
```
user: sjperkins
labels: caching: Issue involving caching
issue_2952: state: open
title: Function accepting njitted functions as arguments is slow
body: - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I was trying numba 0.38 and the new support for jitted functions as arguments with this code snippet:

```
# coding: utf-8
from scipy.optimize import newton
from numba import njit
@njit
def func(x):
    return x**3 - 1
@njit
def fprime(x):
    return 3 * x**2
@njit
def njit_newton(func, x0, fprime):
    for _ in range(50):
        fder = fprime(x0)
        fval = func(x0)
        newton_step = fval / fder
        x = x0 - newton_step
        if abs(x - x0) < 1.48e-8:
            return x
        x0 = x
            
get_ipython().run_line_magic('timeit', 'newton(func.py_func, 1.5, fprime=fprime.py_func)')
get_ipython().run_line_magic('timeit', 'newton(func, 1.5, fprime=fprime)')
get_ipython().run_line_magic('timeit', 'njit_newton.py_func(func, 1.5, fprime=fprime)')
get_ipython().run_line_magic('timeit', 'njit_newton(func, 1.5, fprime=fprime)')
```

And I found surprising that `njit_newton` is the slowest of all, while `njit_newton.py_func` is the fastest:

```
$ ipython test_perf.py 
4.76 µs ± 8.52 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
4.14 µs ± 30.8 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
3.58 µs ± 26 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
20 µs ± 85.3 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
```

cc @nikita-astronaut

(Inspiration: https://github.com/scipy/scipy/blob/607a21e07dad234f8e63fcf03b7994137a3ccd5b/scipy/optimize/zeros.py#L164-L182)
user: astrojuanlu
issue_2949: state: open
title: Value-based Specialization and Dispatch
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->
Numba specializes functions based on their argument types. However, sometimes specializing based on argument values (or other conditions) is required.

In the basic argument specialization case, let's assume a simple function:
```python
@jit
def f(A, B):
    ...
```
If `f` is called with `f(2,10)` for the first time, a compiler pass should be able to declare that `B==10` is specialized, and the function should be recompiled if this condition is not true in any future calls to `f`. I think this is the most common case.

The next level would be enabling specialization based on any condition in the function. For example:
```python
def f(...):
    ...
    check_and_recompile(cond)
    ...
```
A compiler pass should be able to insert a function that checks a condition and forces recompilation and re-execution. Compiling and executing the rest of the function might be required if there were side effects before this point in the function. I still need to think more about this case since the use case is still not fully clear yet.
user: ehsantn
labels: discussion: An issue requiring discussion
issue_2942: state: open
title: Fix linkage nature (declspec(dllexport)) of some test functions
body: The comment in the PR hopefully explains it all (maybe it explains too much and those details should be moved to the commit message instead?).

Need to see how this works out on Linux and macOS too as I only tried it on Windows so far.
user: mingwandroid
labels: 4 - Waiting on reviewer: Waiting for reviewer to respond to author
good second issue: A good issue for second time contributors
issue_2936: state: open
title: guvectorize automatic signatures
body: Writing guvectorize signatures is cumbersome and user-unfriendly, particularly in the vast majority of the cases where all input and output dtypes are homogeneous. Also, somebody may write a library that only works in float64 because he could not be bothered catering for all possible data types, ship it, and needlessly slow down people who only need float32. Even worse, he could introduce a typing error in only one dtype and then forget to test it explicitly in his unit tests.

The _right_ way would be to automatically infer dtypes like @jit does. But I suspect if that isn't happening yet is that it's not a trivial change?

The _easy_ way requires two things, and it's intern-friendly :smile: :

1. define a special dtype, "number", which automatically expands to all possible dtypes with the only caveats that all inputs and outputs with dtype number will be cast to the same dtype.
2. make signatures optional, and if signatures is missing, build it from layout using dtype number. 

For example this:
```
@guvectorize("(ij),(i)->(j)")
```
would automatically expand to:
```
@guvectorize(["number[:,:], number[:], number[:]"], "(ij),(i)->(j)")
```
which would automatically expand to:
```
@guvectorize([
    "float32[:,:], float32[:], float32[:]",
    "float64[:,:], float64[:], float64[:]",
    "int8[:,:], int8[:], int8[:]",
    ...
], "(ij),(i)->(j)")
```

The drawback would be that it would slow down things at module load time if you don't set ``cache=True``.


An alternative syntax, which would be immediately recognizable to C++ people, would be to use a Python string template:
```
@guvectorize(["{T}[:,:], {T}[:], {T}[:]"], "(ij),(i)->(j)")
```


Related: #2317 
user: crusaderky
labels: discussion: An issue requiring discussion
issue_2933: state: open
title: ctypes Structure support
body: This is in reference to #133 
I am opening a new issue for this as the previous one is quite old.
It seems that support for ctypes structs and structs in general was dropped in recent revisions.
Is there a reason for this?
user: innovate-invent
issue_2931: state: open
title: Improve error message for untyped list or yet-to-decide type variables
body: ## Enhancement

https://github.com/numba/numba/pull/2928 makes untyped-list-usage error slightly more informative but we can do even better if the typing constraints are triggered iff the inputs to the contraint is already typed.  That would better localize the location where the error first occur.


File chk_untyped_list.py:
```python
from numba import njit
import numpy as np

@njit
def foo(x):
    a = np.array([])
    return a.astype(np.int32)


foo(1)
```

The above produces the following error with the 
```
Undecided type $0.6 := <undecided>
[1] During: resolving caller type: $0.6
[2] During: typing of call at chk_untyped_list.py (7)


File "chk_untyped_list.py", line 7:
def foo(x):
    <source elided>
    a = np.array([])
    return a.astype(np.int32)
    ^
```

The error is pointing to the type resolution of the caller (`a.astype`) but the origin is that `a` is not typed.

user: sklam
issue_2922: state: open
title: Inaccurate complex tanh implementation
body: Numba complex tanh implementation returns nans for large real values, probably due to some intermediate under/overflow.

The following code fails:
```
import numpy as np
import numba

@numba.jit
def numba_tanh(x):
    return np.tanh(x)

points = [-700+1j, 700+1j]

for x in points:
    expected = np.tanh(x)
    got = numba_tanh(x)
    np.testing.assert_allclose(got, expected)
```
(tested on Numba 0.37.0, didn't test on 0.38.0 since llvmlite 0.23 failed to work out of the box on fedora 28)

Replacing `np.tanh` with `cmath.tanh` in `numba_tanh` does work however.
user: pv
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_2919: state: open
title: NaN test yields wrong result with fastmath=True
body: With the latest numba (0.38, icc_rt installed) on a Xeon E5-2697 server with CentOS 6.9

I get a wrong result for a NaN test when using fastmath. 

I have written a reproducer below:

from numba import *
import numpy

@njit()
def testnan(x):
    print (numpy.isnan(x[0]),x[0])
    return numpy.isnan(x[0])

@njit(fastmath=True)
def testnanfast(x):
    print (numpy.isnan(x[0]),x[0])
    return numpy.isnan(x[0])

x=numpy.empty(2)
x.fill(numpy.nan)

a=testnan(x)
b=testnanfast(x)
print (a,b)

On my machine this yields:

(True, nan)

(False, nan)

(True, False)


user: leohaim
issue_2916: state: open
title: Feature request: support **kwargs in CALL_FUNCTION_EX
body: Platform: Windows 7 x64
Python: Anaconda Python 3.6
Numba version: 0.37.0

This came up a couple of times in #2328 and other issues.   Given the popularity of the **kwargs construction, there's a lot of code which can't currently use numba without (in some cases significant) rewrites, which kind of defeats the purpose of using the decorator (as opposed to, say, writing Cython).
Are there plans to support **kwargs in the future, or reasons why it isn't compatible with the project?
user: jengelman
issue_2913: state: open
title: Test refactoring
body: Currently, the tests for Numba are quite messy. The test code is quite WET, and looks to be written almost entirely in an ad hoc fashion. A lot of testing code looks similar.

Examples are:
- Testing for multiple functions, i.e. methods on arrays and corresponding function calls
- Repeated tests on multiple inputs
- Testing for correct errors
- Testing with memory leaks
- Compilation and calculation patterns

Since test code appears to be entirely ad hoc, none of these patterns seem to be present in an abstract, reusable form.

There are some confusing points as well:
- When we compile using `njit`, compile explicitly, `compile_isolated`?
- How are tests organized? Not quite clear what functionality tests go where.
- Abstraction level. Some tests compile "in-function", others have inner functions called `run` and the like.

I'd like to (somewhat) formalize all of these points, including relevant documentation (nothing too complex).

Additionally, I'd like to look into using [Hypothesis](https://hypothesis.works). There's a bunch of tests being done on mock data, Hypothesis can help with finding edge cases. It has support for generating numpy arrays, and PyPy uses it in some tests, so that seems encouraging.
____

I spent some time trawling through test code already. There's a lot of functionality in Numba and, consequently, a lot of tests, so it doesn't seem viable to refactor the entire test suite in one go (not to mention issues with ensuring consistency). Numpy function support seems to be a nice decent chunk to start with, and then if that is successful, expand towards the other parts of the codebase.

That sound like a plan?
user: Rik-de-Kort
labels: discussion: An issue requiring discussion
issue_2906: state: open
title: Unliftable loops should not be lifted as object mode loops.
body: ## Reporting a bug

 - [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
 - [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

If one compiles code that has liftable loop(s) in object mode but said liftable loop cannot compile in no python mode it currently gets compiled in object mode too. This leads to a pessimal result in that the object mode compiled loop requires all the dispatch mechanics to be called and execute as a function. Ideally there should be a method of aborting compilation of this object mode loop in the object mode compilation case which just yields leaves the loop as-is in the original object mode function.

Example:
```python
from numba import jit
import numpy as np


@jit
def foo(i):
    a = object() # pointless object to force object mode

    # liftable loop
    acc1 = 0
    for x in range(i):
        acc1 += x

    # unliftable loop (np.fft unsupported)
    acc2 = 0
    z = np.zeros((2, 2))
    for x in range(i):
        z[0, 0] = i
        acc2 += np.fft.fft(z)[0, 0]

    # should return: an object, 45, 100+0j
    return a, acc1, acc2

print(foo(10))

lifted = foo.overloads[foo.signatures[0]].lifted

for x in lifted:
    print(x)
    print("line %s" %x.get_source_location())
    print("npm sigs:", x.nopython_signatures)
    print("")

```
gives:
```
$ python looplift_problem.py 
(<object object at 0x7f6200572090>, 45, (100+0j))
LiftedLoop(<function foo at 0x7f621b28cea0>)
line 11
npm sigs: [(int64, int64) -> tuple(int64 x 2)]

LiftedLoop(<function foo at 0x7f621b28cea0>)
line 17
npm sigs: []
```

user: stuartarchibald
labels: objectmode: object mode related issue
performance - run time: Performance issue occurring at run time.
issue_2904: state: open
title: GIL issues with cfunc calling numpy code
body: I have an issue that I think is related to #1998. I'm creating cfuncs which I call from c++ code that releases the gil before it runs. Sometimes the cfuncs have code using numpy arrays, when that happens my program crashes. 

Is there a way for me to:
1. Detect that a function to be compiled uses numpy or anything that might require the gil to be in a specific state? Specifically in my code I have custom type and I use overload_method to add a 'to_array' method to it. So, in my case I just need a way to be notified when calling numba.cfunc(..)(my_func) that a call to 'to_array' was used.
2.  When I get the indication from 1. I would like to wrap the function in a context-manager-like acquire/release gil, similarly to how the parallel ufunc issue was solved [here](https://github.com/numba/numba/pull/1999/files#diff-ec5b6bd5010b2b32f80834aad542033c).
user: dscole
issue_2899: state: open
title: Improve Performance Tips for ParallelAccelerator
body: <!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

If there is no issue present please jump to a section below and delete the
irrelevant one depending on whether you are:

 * Making a feature request.
 * Reporting a bug.

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

The performance tips for `parallel` mode [here](http://numba.pydata.org/numba-doc/dev/user/performance-tips.html#parallel-true) do not mention fusion and vectorization advantages.

I actually suspect that much of the performance improvement in `ident_np` example comes from fusion and not threading. Vectorization is potentially improve as well since the array access indices are transformed to unsigned; I don't know how much it matters though.
user: ehsantn
issue_2861: state: open
title: Turn off MKL threading when used in parfor context.
body: If there is a MKL call in a parfor loop body, there can be an oversubscription problem.  Investigate whether we can insert some code to turn off MKL threading just around the parfor context.
user: DrTodd13
issue_2855: state: open
title: float32 sum accuracy is low
body: I'm using `float32` arrays in image processing examples. I tried a checksum just for validation but looks like `sum()` of `float32` values loses accuracy.

```python
@numba.njit
def f(A):
    B = A / np.float32(255.0)
    return B.sum()

n = 10**6
A = np.ones(n, np.uint8)
print(f(A))
```
python: 3921.56
numba: 3909.23
user: ehsantn
labels: bug - numerically incorrect: Bugs: numerical behaviour is incorrect
issue_2854: state: open
title: ParallelAccelerator variable assignment in parfor not reflected
body: The output of this program is `[0. 0. 0.]` but it should be `[1. 1. 1.]`.

```python
import numpy as np
from numba import prange, njit

@njit(parallel=True)
def test_impl(n):
    X = np.ones((n, 3))
    y = np.zeros(3)
    for i in prange(n):
        y = X[i,:]
    return y

n = 211
print(test_impl(n))
```
user: ehsantn
issue_2834: state: open
title: Disable FMA from @cuda.jit() decorator?
body: I need to disable FMA for my parallel kernel. The FMA-enabled float64 results are too different from the equivalent CPU float64 results for my use case. I couldn't find information on where this option is exposed at the application level in the numba docs, but I added a line to 'numba/cuda/cudadrv/nvvm.py' to always disable it: 

```python
            other_options = (
            'ftz',
            'prec_sqrt',
            'prec_div',
            'fma',
        )

        for k in other_options:
            if k in options:
                v = int(bool(options.pop(k)))
                opts.append('-%s=%d' % (k.replace('_', '-'), v))

        # If there are any option left
        if options:
            optstr = ', '.join(map(repr, options.keys()))
            raise NvvmError("unsupported option {0}".format(optstr))

        # compile
        opts.append('-fma=0') # <====== Added this line
```
After adding this line and running my code again, the floating point results are the same for the CPU and GPU outputs.

If there is not already an application-level place to set this compile-time option, I'd like it added to the @cuda.jit() decorator:

```python
      @cuda.jit(fma=False)
      def my_cool_kernel(input, output):
           # Do things with stuff
```
If there already is a user-facing hook for this, I'd love to avoid hacky garbage coding! 
user: jdjennin
labels: CUDA: CUDA related issue/PR
issue_2823: state: open
title: Interop with C struct
body: Perhaps with cffi/ctypes struct.
user: sklam
issue_2820: state: open
title: Allow setting error model in `vectorize`
body: The ufuncs in NumPy check for floating point exceptions by default, and this convention is followed in Numba; the floating point error model is set here:

https://github.com/numba/numba/blob/master/numba/targets/npyimpl.py#L420

which calls `force_error_model`:

https://github.com/numba/numba/blob/master/numba/targets/imputils.py#L411

and sets that to `NumpyErrorModel`:

https://github.com/numba/numba/blob/master/numba/targets/callconv.py#L492

On the other hand ufuncs in `scipy.special` ignore floating point exceptions by default; see

https://github.com/scipy/scipy/blob/master/scipy/special/_generate_pyx.py#L53

This means that a function ported from `scipy.special` to Numba raises a bunch of floating point exceptions by default. Would it be reasonable to add something like an `error_model` keyword argument to the `vectorize` decorator that allows controlling the error model used?
user: person142
issue_2815: state: open
title: `vectorize` doesn't work with `njit` when jitting is disabled
body: The following code:

```python
import numba
from numba import njit, vectorize


@njit('float64(float64)')
def foo(x):
    return x


@vectorize(['float64(float64)'], nopython=True)
def foobar(x):
    return foo(x)


if __name__ == '__main__':
    print(foobar(1.0))
```

runs with jitting enabled:

```
$ python nojit.py
1.0
```

But it doesn't work with jitting disabled:

```
Traceback (most recent call last):
  File "nojit.py", line 10, in <module>
    @vectorize(['float64(float64)'], nopython=True)
  File "/Users/Josh/Projects/numba-dev/numba/numba/npyufunc/decorators.py", line 120, in wrap
    vec.add(sig)
  File "/Users/Josh/Projects/numba-dev/numba/numba/npyufunc/dufunc.py", line 140, in add
    return self._compile_for_argtys(args, return_type)
  File "/Users/Josh/Projects/numba-dev/numba/numba/npyufunc/dufunc.py", line 186, in _compile_for_argtys
    self._dispatcher, self.targetoptions, sig)
  File "/Users/Josh/Projects/numba-dev/numba/numba/npyufunc/ufuncbuilder.py", line 129, in _compile_element_wise_function
    cres = nb_func.compile(sig, **targetoptions)
  File "/Users/Josh/Projects/numba-dev/numba/numba/npyufunc/ufuncbuilder.py", line 78, in compile
    return self._compile_core(sig, flags, locals)
  File "/Users/Josh/Projects/numba-dev/numba/numba/npyufunc/ufuncbuilder.py", line 113, in _compile_core
    flags=flags, locals=locals)
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 780, in compile_extra
    return pipeline.compile_extra(func)
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 363, in compile_extra
    return self._compile_bytecode()
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 739, in _compile_bytecode
    return self._compile_core()
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 726, in _compile_core
    res = pm.run(self.status)
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 249, in run
    raise patched_exception
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 241, in run
    stage()
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 455, in stage_nopython_frontend
    self.locals)
  File "/Users/Josh/Projects/numba-dev/numba/numba/compiler.py", line 881, in type_inference_stage
    infer.build_constraint()
  File "/Users/Josh/Projects/numba-dev/numba/numba/typeinfer.py", line 802, in build_constraint
    self.constrain_statement(inst)
  File "/Users/Josh/Projects/numba-dev/numba/numba/typeinfer.py", line 969, in constrain_statement
    self.typeof_assign(inst)
  File "/Users/Josh/Projects/numba-dev/numba/numba/typeinfer.py", line 1031, in typeof_assign
    self.typeof_global(inst, inst.target, value)
  File "/Users/Josh/Projects/numba-dev/numba/numba/typeinfer.py", line 1127, in typeof_global
    typ = self.resolve_value_type(inst, gvar.value)
  File "/Users/Josh/Projects/numba-dev/numba/numba/typeinfer.py", line 1050, in resolve_value_type
    raise TypingError(msg, loc=inst.loc)
numba.errors.TypingError: Failed at nopython (nopython frontend)
Untyped global name 'foo': cannot determine Numba type of <class 'function'>
File "nojit.py", line 12
```
user: person142
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2811: state: open
title: Exception support in prange body
body: prange doesn't support exceptions in body since the loop can have multiple exits (check done [here](https://github.com/numba/numba/blob/master/numba/parfor.py#L810)). However, at least the exception case can be handled I think. Is there a problem with threads raising exceptions?

```python
import numpy as np
from numba import njit, prange

@njit(parallel=True)
def f(X, N):
    acc = 0
    for i in prange(N):
        assert X[i] == 1
        acc += X[i]
    return acc

N = 9
X = np.ones(N)
print(f(X, N))
```
user: ehsantn
issue_2810: state: open
title: nopython array creation in C code
body: C wrappers of packages often need to return arrays. Currently, they can't allocate arrays so they should return a data pointer to copy data after the call. A C routine for array allocation in nopython mode can avoid this extra copy.
user: ehsantn
issue_2806: state: open
title: numpy.array() not handling an array type
body: I'm trying to make a `jitclass` that can take either a list or an array as an argument, to then convert to an array with `numpy.array()`. However, it seems like the `numpy.array()` method doesn't handle array types properly. Here's a minimal (failing) example of this problem.

```python
@numba.jit((numba.float64[:],), nopython = True)
def test(v):
    a = np.array(v)
    return a 
```

Here's what seems to be the relevant parts of the error message (I can post more if helpful), which occurs on simply defining the function above:
```
TypingError: Invalid usage of Function(<built-in function array>) with parameters (array(float64, 1d, A))
 * parameterized
In definition 0:
    TypingError: array(float64, 1d, A) not allowed in a homogenous sequence
[1] During: resolving callee type: Function(<built-in function array>)
[2] During: typing of call at <ipython-input-163-4b2e73a0638f> (3)

Failed at nopython (nopython frontend)
Invalid usage of Function(<built-in function array>) with parameters (array(float64, 1d, A))
 * parameterized
In definition 0:
    TypingError: array(float64, 1d, A) not allowed in a homogenous sequence
[1] During: resolving callee type: Function(<built-in function array>)
[2] During: typing of call at <ipython-input-163-4b2e73a0638f> (3)
```
user: zplizzi
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2799: state: open
title: ndarray.transpose() and and ndarray.T do not set data ownership correctly
body: As the title says.  Here's how to reproduce it:

```python
>>> def foo(a): return a.T
...
>>> expected = foo(np.ones(1))
>>> got = numba.njit(foo)(np.ones(1))
>>> expected.flags.owndata == got.flags.owndata
False
>>> y
array([1.])
>>> y.flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : True
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
>>> x
array([1.])
>>> y[0] = 8
>>> x
array([8.])
>>> y
array([8.])
```
user: agayev
issue_2797: state: open
title: @guvectorize not accepting new size variable (i.e. () -> (n)) in output argument
body: MnWE:
````python
from numba import guvectorize


@guvectorize("int64, int64[:]", "() -> (n)")
def result(x, res):
    for i in range(3):
        res[i] = x


if __name__ == "__main__":
    print(result(3))
````

Yields the following error:
````python
Traceback (most recent call last):
  File "C:/Users/User/Documents/numba_playground/guvectorize_test.py", line 4, in <module>
    @guvectorize("int64, int64[:]", "() -> (n)")
  File "C:\Users\User\Anaconda3\lib\site-packages\numba\npyufunc\decorators.py", line 177, in wrap
    guvec = GUVectorize(func, signature, **kws)
  File "C:\Users\User\Anaconda3\lib\site-packages\numba\npyufunc\decorators.py", line 50, in __new__
    targetoptions=kws)
  File "C:\Users\User\Anaconda3\lib\site-packages\numba\npyufunc\ufuncbuilder.py", line 278, in __init__
    self.sin, self.sout = parse_signature(signature)
  File "C:\Users\User\Anaconda3\lib\site-packages\numba\npyufunc\sigparse.py", line 63, in parse_signature
    raise NameError('undefined output symbols: %s' % ','.join(sorted(diff)))
NameError: undefined output symbols: n
````


Related to this discussion from 2016: https://groups.google.com/a/continuum.io/forum/#!topic/numba-users/tjkxRHj4x4k

Workaround there is to pass a dummy output array, like so:
````python
@guvectorize("int64, int64[:], int64[:]", "(), (n) -> (n)")
def result2(x, dum, res):
    for i in range(dum.shape[0]):
        res[i] = x
````
Do mind the argument type for dum here, you'll likely have to explicitly declare it with dtype int64.
user: Rik-de-Kort
issue_2795: state: open
title: API request for LLVM IR manipulation
body: Is it possible to provide an API so that user can easily make inline calls to a LLVM IR function compiled by third-party compiler (Clang, etc)? 
Currently, it is only achievable with lower_builtin. 
user: linzuzeng
labels: discussion: An issue requiring discussion
issue_2792: state: open
title: Add legend to HTML annotation tool.
body: Following on from https://github.com/numba/numba/issues/2788#issuecomment-370585222

> Add a legend to the different colors at the top or bottom of the generated HTML, potentially with an extended description that pops out on click.

Modification probably needs to go in here:
https://github.com/numba/numba/blob/master/numba/annotations/template.html
user: stuartarchibald
issue_2790: state: open
title: fill() method for DeviceNDArray
body: This would call a CUDA kernel that zeros out the contents of an array.  This is a pretty simple kernel.

(Don't forget to also add the method to the CUDA simulator version of DeviceNDArray!)

user: seibert
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_2784: state: open
title: InternalError when performing augmented assignment of a unsigned int multidimensional array if addressing the array by only one index
body: A string of errors is produced if you try the following code against the latest numba git. First a TypingError then while that is being raised an AttributeError occurs.

```python
@jit(nopython=True)
def foo():
    bar = np.ones((4,1), dtype=np.uint64)
    bar[0] += 1
```

The code above will raise errors for any of the unsigned integer types (uint8, uint16, uint32, uint64), but it doesn't happen for the signed integer types or for float type. You can get around the error in the above simplified code by replacing `bar[0] += 1` with either `bar[0,0] += 1` or `bar[0] = bar[0] + 1`. This is also a problem with the `-=` operator.

Here is the full traceback:
```python
Traceback (most recent call last):
  File "test-numba.py", line 9, in <module>
    foo()
  File ".../numba-git/lib/python3.6/site-packages/numba/dispatcher.py", line 330, in _compile_for_args
    raise e
  File ".../numba-git/lib/python3.6/site-packages/numba/dispatcher.py", line 307, in _compile_for_args
    return self.compile(tuple(argtypes))
  File ".../numba-git/lib/python3.6/site-packages/numba/dispatcher.py", line 579, in compile
    cres = self._compiler.compile(args, return_type)
  File ".../numba-git/lib/python3.6/site-packages/numba/dispatcher.py", line 80, in compile
    flags=flags, locals=self.locals)
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 779, in compile_extra
    return pipeline.compile_extra(func)
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 362, in compile_extra
    return self._compile_bytecode()
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 738, in _compile_bytecode
    return self._compile_core()
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 725, in _compile_core
    res = pm.run(self.status)
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 248, in run
    raise patched_exception
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 240, in run
    stage()
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 454, in stage_nopython_frontend
    self.locals)
  File ".../numba-git/lib/python3.6/site-packages/numba/compiler.py", line 881, in type_inference_stage
    infer.propagate()
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 846, in propagate
    raise errors[0]
numba.errors.TypingError: Failed at nopython (nopython frontend)
Internal error at <numba.typeinfer.IntrinsicCallConstraint object at 0x7fc8fa8205c0>:
--%<-----------------------------------------------------------------
Traceback (most recent call last):
  File ".../numba-git/lib/python3.6/site-packages/numba/errors.py", line 259, in new_error_context
    yield
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 503, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 441, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args, literals=literals)
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 1123, in resolve_call
    literals=literals)
  File ".../numba-git/lib/python3.6/site-packages/numba/typing/context.py", line 191, in resolve_function_type
    res = defn.apply(args, kws)
  File ".../numba-git/lib/python3.6/site-packages/numba/typing/templates.py", line 207, in apply
    sig = generic(args, kws)
  File ".../numba-git/lib/python3.6/site-packages/numba/typing/npydecl.py", line 236, in generic
    assert len(sig.args) == 3
AttributeError: 'NoneType' object has no attribute 'args'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 137, in propagate
    constraint(typeinfer)
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 503, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File ".../numba-git/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File ".../numba-git/lib/python3.6/site-packages/numba/errors.py", line 265, in new_error_context
    six.reraise(type(newerr), newerr, sys.exc_info()[2])
  File ".../numba-git/lib/python3.6/site-packages/numba/six.py", line 658, in reraise
    raise value.with_traceback(tb)
  File ".../numba-git/lib/python3.6/site-packages/numba/errors.py", line 259, in new_error_context
    yield
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 503, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 441, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args, literals=literals)
  File ".../numba-git/lib/python3.6/site-packages/numba/typeinfer.py", line 1123, in resolve_call
    literals=literals)
  File ".../numba-git/lib/python3.6/site-packages/numba/typing/context.py", line 191, in resolve_function_type
    res = defn.apply(args, kws)
  File ".../numba-git/lib/python3.6/site-packages/numba/typing/templates.py", line 207, in apply
    sig = generic(args, kws)
  File ".../numba-git/lib/python3.6/site-packages/numba/typing/npydecl.py", line 236, in generic
    assert len(sig.args) == 3
numba.errors.InternalError: 'NoneType' object has no attribute 'args'
[1] During: typing of intrinsic-call at test-numba.py (7)
--%<-----------------------------------------------------------------

File "test-numba.py", line 7
```
user: krrk
labels: bug - ice: Bugs: internal compiler error
issue_2782: state: open
title: Clean up Numba PRNG
body: NumPy and Python both have Mersenne Twister PRNG implementation, but they differ in (1) how they initialize the state and (2) generate random numbers.  Numba, while trying to support both implementations imitates the initialization from NumPy and random number generation from Python.  As a result, neither is easily supported.  

For example, the following code seeds the PRNG with value of 2 and generates a pair of random numbers, both in NumPy and Numba-compiled NumPy.  Ideally, both implementations should generate the same sequence of random numbers and the assertion at the bottom should succeed.  Also, for the Python counterpart of the same code, where we raplace np.random.seed() with random.seed(), and np.random.randint() with random.randrange(), the assertion should succeed.

```Python
from numba import jit
import numpy as np

seed = 2
max = 100

np.random.seed(seed)
a = [np.random.randint(max), np.random.randint(max)]

@jit(nopython=True)
def foo():
    np.random.seed(seed)
    return [np.random.randint(max), np.random.randint(max)]

b = foo()

assert a == b
```

However, currently, in both versions the assertion fails.  Since Numba imitiates initialization from NumPy and random number generation from Python, there are ugly hacks in numba/numba/test_random.py that first generate a Python PRNG state and then manually copies the state to Numba's internal state, after which Numba can generate the same sequence of random numbers as Python.

The following patch, changes the Numba's random number generation to match that of NumPy's.  As a result, with the following patch, the assertion in the above code succeds:

```Python
diff --git a/numba/targets/randomimpl.py b/numba/targets/randomimpl.py
index 150541e..99cd61d 100644
--- a/numba/targets/randomimpl.py
+++ b/numba/targets/randomimpl.py
@@ -148,7 +148,9 @@ def get_next_int(context, builder, state_ptr, nbits):
     def get_shifted_int(nbits):
         shift = builder.sub(c32, nbits)
         y = get_next_int32(context, builder, state_ptr)
-        return builder.lshr(y, builder.zext(shift, y.type))
+        mask = builder.not_(ir.Constant(y.type, 0))
+        mask = builder.lshr(mask, builder.zext(shift, y.type))
+        return builder.and_(y, mask)
```

Hence, with the following patch, Numba's PRNG follows NumPy's PRNG verbatim with one caveat: this does not handle the case of iflarge branch in get_next_int -- more research is needed to figure out how to make that branch also match NumPy's PRNG, although it should be trivial.

In conclusion, the cleanup work needs to have another PRNG implementation that keeps current number generation but modifies the initialization to match that of Python's.  With this work in place, Numba would have two different PRNG implementations that are identical to Python's and NumPy's.  Then the unit tests should be fixed to remove the ugly state-setting hacks and have straightforward test implementations similar to the above code snippets.

On another thought, given that most Numba users are compiling NumPy code, perhaps Numba can drop support for Python PRNG and just keep NumPy PRNG.
user: agayev
issue_2781: state: open
title: Lowering error with global default value for a parameter
body: ```python
A=[1., 2.]
@numba.njit
def f(f_values=A):
    return 0   
f()
```
results in something which is hard to interpret to me (below). At the same time 

```
f(A)
```
works fine, which suggests that this could be easily fixed.

```python
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/targets/base.py in get_constant_generic(self, builder, ty, val)
    453         try:
--> 454             impl = self._get_constants.find((ty,))
    455             return impl(self, builder, ty, val)

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/targets/base.py in find(self, sig)
     47         if out is None:
---> 48             out = self._find(sig)
     49             self._cache[sig] = out

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/targets/base.py in _find(self, sig)
     56         else:
---> 57             raise NotImplementedError(self, sig)
     58 

NotImplementedError: (<numba.targets.base.OverloadSelector object at 0x7ffa086aa320>, (reflected list(float64),))

During handling of the above exception, another exception occurred:

NotImplementedError                       Traceback (most recent call last)
~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    258     try:
--> 259         yield
    260     except NumbaError as e:

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_block(self, block)
    215                                    loc=self.loc, errcls_=defaulterrcls):
--> 216                 self.lower_inst(inst)
    217 

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_inst(self, inst)
    264             ty = self.typeof(inst.target.name)
--> 265             val = self.lower_assign(ty, inst)
    266             self.storevar(val, inst.target.name)

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    428                 const = self.context.get_constant_generic(self.builder, valty,
--> 429                                                           pyval)
    430                 # cast it to the variable type

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/targets/base.py in get_constant_generic(self, builder, ty, val)
    456         except NotImplementedError:
--> 457             raise NotImplementedError("cannot lower constant of type '%s'" % (ty,))
    458 

NotImplementedError: cannot lower constant of type 'reflected list(float64)'

During handling of the above exception, another exception occurred:

LoweringError                             Traceback (most recent call last)
<ipython-input-18-a5b8ed516f38> in <module>()
      4     return 0
      5 
----> 6 f()

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    305                 argtypes.append(self.typeof_pyval(a))
    306         try:
--> 307             return self.compile(tuple(argtypes))
    308         except errors.TypingError as e:
    309             # Intercept typing error that may be due to an argument

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, sig)
    577 
    578                 self._cache_misses[sig] += 1
--> 579                 cres = self._compiler.compile(args, return_type)
    580                 self.add_overload(cres)
    581                 self._cache.save_overload(sig, cres)

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     78                                       impl,
     79                                       args=args, return_type=return_type,
---> 80                                       flags=flags, locals=self.locals)
     81         # Check typing error if object mode is used
     82         if cres.typing_error is not None and not flags.enable_pyobject:

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library)
    777     pipeline = Pipeline(typingctx, targetctx, library,
    778                         args, return_type, flags, locals)
--> 779     return pipeline.compile_extra(func)
    780 
    781 

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in compile_extra(self, func)
    360         self.lifted = ()
    361         self.lifted_from = None
--> 362         return self._compile_bytecode()
    363 
    364     def compile_ir(self, func_ir, lifted=(), lifted_from=None):

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in _compile_bytecode(self)
    736         """
    737         assert self.func_ir is None
--> 738         return self._compile_core()
    739 
    740     def _compile_ir(self):

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in _compile_core(self)
    723 
    724         pm.finalize()
--> 725         res = pm.run(self.status)
    726         if res is not None:
    727             # Early pipeline completion

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in run(self, status)
    246                     # No more fallback pipelines?
    247                     if is_final_pipeline:
--> 248                         raise patched_exception
    249                     # Go to next fallback pipeline
    250                     else:

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in run(self, status)
    238                 try:
    239                     event(stage_name)
--> 240                     stage()
    241                 except _EarlyPipelineCompletion as e:
    242                     return e.result

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in stage_nopython_backend(self)
    656         """
    657         lowerfn = self.backend_nopython_mode
--> 658         self._backend(lowerfn, objectmode=False)
    659 
    660     def stage_compile_interp_mode(self):

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    611             self.library.enable_object_caching()
    612 
--> 613         lowered = lowerfn()
    614         signature = typing.signature(self.return_type, *self.args)
    615         self.cr = compile_result(typing_context=self.typingctx,

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in backend_nopython_mode(self)
    598                 self.return_type,
    599                 self.calltypes,
--> 600                 self.flags)
    601 
    602     def _backend(self, lowerfn, objectmode):

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/compiler.py in native_lowering_stage(targetctx, library, interp, typemap, restype, calltypes, flags)
    896 
    897     lower = lowering.Lower(targetctx, library, fndesc, interp)
--> 898     lower.lower()
    899     if not flags.no_cpython_wrapper:
    900         lower.create_cpython_wrapper(flags.release_gil)

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower(self)
    133         if self.generator_info is None:
    134             self.genlower = None
--> 135             self.lower_normal_function(self.fndesc)
    136         else:
    137             self.genlower = self.GeneratorLower(self)

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_normal_function(self, fndesc)
    174         # Init argument values
    175         self.extract_function_arguments()
--> 176         entry_block_tail = self.lower_function_body()
    177 
    178         # Close tail of entry block

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_function_body(self)
    199             bb = self.blkmap[offset]
    200             self.builder.position_at_end(bb)
--> 201             self.lower_block(block)
    202 
    203         self.post_lower()

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_block(self, block)
    214             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    215                                    loc=self.loc, errcls_=defaulterrcls):
--> 216                 self.lower_inst(inst)
    217 
    218     def create_cpython_wrapper(self, release_gil=False):

~/miniconda3/envs/emmy/lib/python3.6/contextlib.py in __exit__(self, type, value, traceback)
     97                 value = type()
     98             try:
---> 99                 self.gen.throw(type, value, traceback)
    100             except StopIteration as exc:
    101                 # Suppress StopIteration *unless* it's the same exception that

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    263     except Exception as e:
    264         newerr = errcls(e).add_context(_format_msg(fmt_, args, kwargs))
--> 265         six.reraise(type(newerr), newerr, sys.exc_info()[2])
    266 
    267 

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/six.py in reraise(tp, value, tb)
    656             value = tp()
    657         if value.__traceback__ is not tb:
--> 658             raise value.with_traceback(tb)
    659         raise value
    660 

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/errors.py in new_error_context(fmt_, *args, **kwargs)
    257 
    258     try:
--> 259         yield
    260     except NumbaError as e:
    261         e.add_context(_format_msg(fmt_, args, kwargs))

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_block(self, block)
    214             with new_error_context('lowering "{inst}" at {loc}', inst=inst,
    215                                    loc=self.loc, errcls_=defaulterrcls):
--> 216                 self.lower_inst(inst)
    217 
    218     def create_cpython_wrapper(self, release_gil=False):

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_inst(self, inst)
    263         if isinstance(inst, ir.Assign):
    264             ty = self.typeof(inst.target.name)
--> 265             val = self.lower_assign(ty, inst)
    266             self.storevar(val, inst.target.name)
    267 

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/lowering.py in lower_assign(self, ty, inst)
    427                 valty = self.context.typing_context.resolve_value_type(pyval)
    428                 const = self.context.get_constant_generic(self.builder, valty,
--> 429                                                           pyval)
    430                 # cast it to the variable type
    431                 res = self.context.cast(self.builder, const, valty, ty)

~/miniconda3/envs/emmy/lib/python3.6/site-packages/numba/targets/base.py in get_constant_generic(self, builder, ty, val)
    455             return impl(self, builder, ty, val)
    456         except NotImplementedError:
--> 457             raise NotImplementedError("cannot lower constant of type '%s'" % (ty,))
    458 
    459     def get_constant(self, ty, val):

LoweringError: Failed at nopython (nopython mode backend)
cannot lower constant of type 'reflected list(float64)'
File "<ipython-input-18-a5b8ed516f38>", line 4
[1] During: lowering "f_values = arg(0, name=f_values)" at <ipython-input-18-a5b8ed516f38> (4)
```
user: wjaskowski
issue_2774: state: open
title: reversed is not supported?
body: ```python
@numba.njit
def f():
    x = 0
    for i in reversed(range(0,10)):
        x += i
    return x
f()
```

ends with

```
TypingError: Failed at nopython (nopython frontend)
Untyped global name 'reversed': cannot determine Numba type of <class 'type'>
```

0.37, Python 3.6.4
user: wjaskowski
issue_2773: state: open
title: IntFlag converted to raw int inside njit function
body: Python 3.6 introduced enum.IntFlag as a nicer representation of bit flags. Numba already supports IntEnum and does not crash on IntFlag, however when passed as function argument it cast it to a simple integer causing the following to fail with a TypingError while it works for IntEnum. (This is on Windows 10 64 bit with Numba 0.36.2)

```python
import enum
from numba import njit


class MyFlag(enum.IntFlag):
    VALUE = 1


@njit
def f(flag):
    return flag & MyFlag.VALUE


print(f(MyFlag.VALUE))

```
Given some pointers, I am willing to fix this.

Follow the traceback:

```
Traceback (most recent call last):
  File "numba_bug_flag.py", line 14, in <module>
    f(MyFlag.VALUE)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\dispatcher.py", line 330, in _compile_for_args
    raise e
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\dispatcher.py", line 307, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\dispatcher.py", line 579, in compile
    cres = self._compiler.compile(args, return_type)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\dispatcher.py", line 80, in compile
    flags=flags, locals=self.locals)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 766, in compile_extra
    return pipeline.compile_extra(func)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 362, in compile_extra
    return self._compile_bytecode()
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 725, in _compile_bytecode
    return self._compile_core()
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 712, in _compile_core
    res = pm.run(self.status)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 248, in run
    raise patched_exception
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 240, in run
    stage()
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 454, in stage_nopython_frontend
    self.locals)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\compiler.py", line 868, in type_inference_stage
    infer.propagate()
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\typeinfer.py", line 844, in propagate
    raise errors[0]
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\typeinfer.py", line 137, in propagate
    constraint(typeinfer)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\typeinfer.py", line 501, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "D:\Coding\Languages\Python\envs\py36\lib\site-packages\numba\typeinfer.py", line 450, in resolve
    raise TypingError(msg, loc=self.loc)
numba.errors.TypingError: Failed at nopython (nopython frontend)
Invalid usage of & with parameters (int64, Enum<int64>(MyFlag))
Known signatures:
 * (bool, bool) -> bool
 * (int64, int64) -> int64
 * (int64, uint64) -> int64
 * (uint64, int64) -> int64
 * (uint64, uint64) -> uint64
 * parameterized
File "numba_bug_flag.py", line 11
[1] During: typing of intrinsic-call at numba_bug_flag.py (11)
```
user: MatthieuDartiailh
issue_2771: state: open
title: The tuple built-in is not supported in nopython mode
body: The `tuple([iterable])` python built-in function doesn't work in nopython mode. Is there any plan to support this in nopython mode?

This would be very helpful for some functions like `numpy.ndindex(*shape)` which in numba must be called with a tuple. In addition in nopython mode generating a tuple by tuple addition (concatenation) in a for loop does not work.

Minimal function for use of tuple:
```python
@jit(nopython=True)
def g():
    tuple()
```
Resulting error:
```python
Untyped global name 'tuple': cannot determine Numba type of <class 'type'>
```
Trying to generate a tuple using a for loop:
```python
@jit(nopython=True)
def foo():
    t = ()
    for i in range(-10, 11):
        t += (i,)
    return t
```
Resulting error:
```python
cannot unify () and (int64 x 1) for 't'
```

Also after reading through the documentation (section 2.6) I had expected that this would work. Here are the relevant parts of that documentation:

> 2.6. Supported Python features¶
> 
> Apart from the Language part below, which applies to both object mode and nopython mode, this page only lists the features supported in nopython mode.

> 2.6.2.3. tuple
> 
> The following operations are supported:
> 
>     tuple construction
>     tuple unpacking
>     comparison between tuples
>     iteration and indexing over homogenous tuples
>     addition (concatenation) between tuples
>     slicing tuples with a constant slice
> 


user: krrk
issue_2770: state: open
title: Function calls with an unpacked list to *args are not handled by numba
body: Calling a function that takes *args as its argument with a list causes a segmentation fault. This is documented as not supported by numba:

> Numba supports function calls using positional and named arguments, as well as arguments with default values and *args (note the argument for *args can only be a tuple, not a list). Explicit **kwargs are not supported.

but this should be handled by numba and throw a python error to alert the user of the lack of support. Here is some simplified code that can cause the segmentation fault.

```python
from numba import jit

@jit
def g(*args):
    return args

@jit
def f1():
    return g(*(1,2,3))

@jit
def f2():
    return g(*[1,2,3])

print(f1())
print(f2())
```

The first called to `f1` succeeds while the second call to `f2` segfaults:
```
$ python test.py
(1, 2, 3)
Segmentation fault (core dumped)
```

As a very new user to numba I expected that numba would provide an error message and not segfault. It took me a long time to realize that numba doesn't support calling functions of *args with a list and if I just convert it to a tuple first it works. This would be easier for new users to identify if a proper error is thrown.

For reference here is a gdb backtrace:

```gdb
Reading symbols from python...done.
(gdb) run test.py
Starting program: /home/kieran/anaconda3/bin/python test-numba2.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffef324700 (LWP 13268)]
[New Thread 0x7fffecb23700 (LWP 13269)]
[New Thread 0x7fffea322700 (LWP 13270)]
[New Thread 0x7fffe7b21700 (LWP 13271)]
[New Thread 0x7fffe7320700 (LWP 13272)]
[New Thread 0x7fffe4b1f700 (LWP 13273)]
[New Thread 0x7fffe231e700 (LWP 13274)]
[New Thread 0x7fffdfb1d700 (LWP 13275)]
[New Thread 0x7fffdf31c700 (LWP 13276)]
[New Thread 0x7fffdab1b700 (LWP 13277)]
[New Thread 0x7fffd631a700 (LWP 13278)]
[Thread 0x7fffdfb1d700 (LWP 13275) exited]
[Thread 0x7fffdab1b700 (LWP 13277) exited]
[Thread 0x7fffdf31c700 (LWP 13276) exited]
[Thread 0x7fffe231e700 (LWP 13274) exited]
[Thread 0x7fffe4b1f700 (LWP 13273) exited]
[Thread 0x7fffe7320700 (LWP 13272) exited]
[Thread 0x7fffe7b21700 (LWP 13271) exited]
[Thread 0x7fffea322700 (LWP 13270) exited]
[Thread 0x7fffecb23700 (LWP 13269) exited]
[Thread 0x7fffef324700 (LWP 13268) exited]
[Thread 0x7fffd631a700 (LWP 13278) exited]
(1, 2, 3)

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007fffec91bee8 in Dispatcher_call (self=0x7fffeec011b0, args=0x0, kws=0x0) at numba/_dispatcher.c:504
504     numba/_dispatcher.c: No such file or directory.
(gdb) bt
#0  0x00007fffec91bee8 in Dispatcher_call (self=0x7fffeec011b0, args=0x0, kws=0x0) at numba/_dispatcher.c:504
#1  0x00007ffff790e76a in PyObject_Call (func=0x7fffeec011b0, args=<optimized out>, kwargs=<optimized out>) at Objects/abstract.c:2261
#2  0x00007ffff7fa61b8 in __main__::f2$243 ()
#3  0x00007ffff7fa630d in cpython::__main__::f2$243 ()
#4  0x00007fffec91ba48 in call_cfunc (locals=0x0, kws=0x0, args=0x7ffff7faf048, cfunc=0x7fffe787bd38, self=0x7fffeec01b10)
    at numba/_dispatcher.c:343
#5  compile_and_invoke (self=self@entry=0x7fffeec01b10, args=args@entry=0x7ffff7faf048, kws=kws@entry=0x0, locals=locals@entry=0x0)
    at numba/_dispatcher.c:366
#6  0x00007fffec91bfbf in Dispatcher_call (self=self@entry=0x7fffeec01b10, args=args@entry=0x7ffff7faf048, kws=<optimized out>, kws@entry=0x0)
    at numba/_dispatcher.c:572
#7  0x00007ffff790e8cb in _PyObject_FastCallDict (func=0x7fffeec01b10, args=<optimized out>, nargs=<optimized out>, kwargs=0x0)
    at Objects/abstract.c:2331
#8  0x00007ffff7a00da8 in call_function (pp_stack=pp_stack@entry=0x7fffffffd460, oparg=oparg@entry=0, kwnames=kwnames@entry=0x0)
    at Python/ceval.c:4848
#9  0x00007ffff7a059e6 in _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3322
#10 0x00007ffff7a00c3e in _PyEval_EvalCodeWithName (_co=_co@entry=0x7ffff667a5d0, globals=globals@entry=0x7ffff7f4f438,
    locals=locals@entry=0x7ffff7f4f438, args=args@entry=0x0, argcount=argcount@entry=0, kwnames=kwnames@entry=0x0, kwargs=kwargs@entry=0x0,
    kwcount=kwcount@entry=0, kwstep=kwstep@entry=2, defs=defs@entry=0x0, defcount=defcount@entry=0, kwdefs=kwdefs@entry=0x0,
    closure=closure@entry=0x0, name=name@entry=0x0, qualname=qualname@entry=0x0) at Python/ceval.c:4153
#11 0x00007ffff7a0126d in PyEval_EvalCodeEx (_co=_co@entry=0x7ffff667a5d0, globals=globals@entry=0x7ffff7f4f438,
    locals=locals@entry=0x7ffff7f4f438, args=args@entry=0x0, argcount=argcount@entry=0, kws=kws@entry=0x0, kwcount=kwcount@entry=0,
    defs=defs@entry=0x0, defcount=defcount@entry=0, kwdefs=kwdefs@entry=0x0, closure=closure@entry=0x0) at Python/ceval.c:4174
#12 0x00007ffff7a012bb in PyEval_EvalCode (co=co@entry=0x7ffff667a5d0, globals=globals@entry=0x7ffff7f4f438, locals=locals@entry=0x7ffff7f4f438)
    at Python/ceval.c:730
#13 0x00007ffff7a3c132 in run_mod (arena=0x7ffff7f6a2a0, flags=0x7fffffffd770, locals=0x7ffff7f4f438, globals=0x7ffff7f4f438,
    filename=0x7ffff64219b0, mod=0x6446f8) at Python/pythonrun.c:1025
#14 PyRun_FileExFlags (fp=fp@entry=0x68e750, filename_str=filename_str@entry=0x7ffff66aba40 "test-numba2.py", start=start@entry=257,
    globals=globals@entry=0x7ffff7f4f438, locals=locals@entry=0x7ffff7f4f438, closeit=closeit@entry=1, flags=flags@entry=0x7fffffffd770)
    at Python/pythonrun.c:978
#15 0x00007ffff7a3c297 in PyRun_SimpleFileExFlags (fp=fp@entry=0x68e750, filename=<optimized out>, closeit=closeit@entry=1,
    flags=flags@entry=0x7fffffffd770) at Python/pythonrun.c:420
#16 0x00007ffff7a3c733 in PyRun_AnyFileExFlags (fp=fp@entry=0x68e750, filename=<optimized out>, closeit=closeit@entry=1,
    flags=flags@entry=0x7fffffffd770) at Python/pythonrun.c:81
#17 0x00007ffff7a5839d in run_file (p_cf=0x7fffffffd770, filename=0x6032c0 L"test-numba2.py", fp=0x68e750) at Modules/main.c:338
#18 Py_Main (argc=argc@entry=2, argv=argv@entry=0x602010) at Modules/main.c:809
#19 0x0000000000400bbc in main (argc=2, argv=<optimized out>) at ./Programs/python.c:69
```
user: krrk
issue_2769: state: open
title: compilation issue with infinite loop
body: Reported in https://gitter.im/numba/numba?at=5a9065978f1c77ef3a48269e
```python
from numba import njit                                                                                                          
                                                                                                                                
def foo(a, b):                                                                                                                  
    while True:                                                                                                                 
        pass                                                                                                                    
    return a + b                                                                                                                  
                                                                                                                                
njit(foo)(1,2) 
```
gives:
```
SystemError: CPUDispatcher(<function foo at 0x7f1cc73dcea0>) returned NULL without setting an error     
```
thanks for reporting @Rik-de-Kort 
user: stuartarchibald
issue_2763: state: open
title: Numba/llvmlite code generation docs and tutorials
body: Code generation in the lowering stage is very painful for new developers to learn, especially because the utility functions used work by side effect.

We need a lot of documentation and tutorial material to help new developers get up to speed.
user: ehsantn
issue_2757: state: open
title: Raise if an AOT compiled function is called with arguments that do not match the signature
body: Following on from https://github.com/numba/numba/issues/2755#issuecomment-366109388.
Running this script to compile a module `nbmod` with AOT function `func1`:
```python
from numba import njit
from numba.pycc import CC

cc = CC('nbmod')

@cc.export('func1',  'f8[:,:](f8[:,:])')
@njit
def func1(x):
    return x + 1.

if __name__ == "__main__":
    cc.compile()
```
and then running this script making use of the compiled module:
```python
import nbmod
import numpy as np

x = np.arange(12).reshape(4, 3)
print(nbmod.func1(x))
print(nbmod.func1(x.astype(np.float64)))
```
gives this:
```
[[ 1.  1.  1.]
 [ 1.  1.  1.]
 [ 1.  1.  1.]
 [ 1.  1.  1.]]
[[  1.   2.   3.]
 [  4.   5.   6.]
 [  7.   8.   9.]
 [ 10.  11.  12.]]
```
The first result is incorrect due to the wrong data type used in the input. The compiled function should raise an exception if the type of the arguments presented at run time do not match those declared when the function was compiled.
user: stuartarchibald
issue_2754: state: open
title: Support generated_jit for cuda target
body: Reported from ML: https://groups.google.com/a/continuum.io/forum/?utm_medium=email&utm_source=footer#!msg/numba-users/8rfMK8e1Nvg/i9yqaUNLBQAJ

Code sample:

```python
from numba import generated_jit, types, cuda
import numpy as np

# Create atomics for real and complex
def atomic_real( x, i, y):
    cuda.atomic.add(x, i, y)
def atomic_complex( x, i, y):
    cuda.atomic.add(x.real, i, y.real)
    cuda.atomic.add(x.imag, i, y.imag)

# Use generated_jit to point to these functions
@generated_jit(device=True)
def atomic(x, i, y):
    if isinstance(y, types.Float):
        return atomic_real
    elif isinstance(y, types.Complex):
        return atomic_complex

# Use the generated_jit function in a kernel
@cuda.jit
def add( x, y, N):
    i = cuda.grid(1)
    if i < N:
        atomic( x, i, y[i])

N = 1000
x = np.ones(N)
y = np.ones(N)
tpb = 32
bpg = int(N/32) + 1
add[tpb, bpg](x, y, N)
assert np.allclose(x, 2)
```


user: sklam
labels: CUDA: CUDA related issue/PR
issue_2753: state: open
title: Casting to int inside loop yields numpy array indexing error
body: Float indexing for numpy arrays is deprecated, and as such it's not supported by numba.
When initiating a variable as a float, and casting it to an integer, and the using it to index a numpy array, this works fine. However, when we cast it to integer *inside a loop*, numba will throw an error saying float indexing is not supported.

MWE without error:
```python
import numpy as np
from numba import njit

@njit()
def literally_can_(even):
    w = 0.0
    w = int(w)
    few = even[w]
    return 0

odd = np.array([0 for _ in range(1)], dtype="float64")
literally_can_(odd)
```

Adding a loop makes it throw an error:
```python
@njit()
def literally_cant_(even):
    w = 0.0
    for _ in range(1):
        w = int(w)

    few = even[w]
    return 0

odd = np.array([0 for _ in range(1)], dtype="float64")
literally_cant_(odd)
```

Error produced
```
Traceback (most recent call last):
  File "C:/Users/user/Documents/ManagedDC/test.py", line 25, in <module>
    print(literally_cant_(odd))
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\dispatcher.py", line 330, in _compile_for_args
    raise e
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\dispatcher.py", line 307, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\dispatcher.py", line 579, in compile
    cres = self._compiler.compile(args, return_type)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\dispatcher.py", line 80, in compile
    flags=flags, locals=self.locals)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 766, in compile_extra
    return pipeline.compile_extra(func)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 362, in compile_extra
    return self._compile_bytecode()
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 725, in _compile_bytecode
    return self._compile_core()
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 712, in _compile_core
    res = pm.run(self.status)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 248, in run
    raise patched_exception
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 240, in run
    stage()
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 454, in stage_nopython_frontend
    self.locals)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\compiler.py", line 868, in type_inference_stage
    infer.propagate()
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 844, in propagate
    raise errors[0]
numba.errors.TypingError: Failed at nopython (nopython frontend)
Internal error at <numba.typeinfer.IntrinsicCallConstraint object at 0x0000019D931991D0>:
--%<-----------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\errors.py", line 259, in new_error_context
    yield
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 501, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 441, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args, literals=literals)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 1113, in resolve_call
    literals=literals)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\context.py", line 189, in resolve_function_type
    res = defn.apply(args, kws)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\templates.py", line 207, in apply
    sig = generic(args, kws)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\arraydecl.py", line 165, in generic
    out = get_array_index_type(ary, idx)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\arraydecl.py", line 71, in get_array_index_type
    % (ty, idx))
TypeError: unsupported array index type float64 in [float64]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 137, in propagate
    constraint(typeinfer)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 501, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "C:\Users\user\Anaconda3\lib\contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\errors.py", line 265, in new_error_context
    six.reraise(type(newerr), newerr, sys.exc_info()[2])
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\six.py", line 658, in reraise
    raise value.with_traceback(tb)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\errors.py", line 259, in new_error_context
    yield
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 501, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 441, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args, literals=literals)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typeinfer.py", line 1113, in resolve_call
    literals=literals)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\context.py", line 189, in resolve_function_type
    res = defn.apply(args, kws)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\templates.py", line 207, in apply
    sig = generic(args, kws)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\arraydecl.py", line 165, in generic
    out = get_array_index_type(ary, idx)
  File "C:\Users\user\Anaconda3\lib\site-packages\numba\typing\arraydecl.py", line 71, in get_array_index_type
    % (ty, idx))
numba.errors.InternalError: unsupported array index type float64 in [float64]
[1] During: typing of intrinsic-call at C:/Users/user/Documents/ManagedDC/test.py (11)
--%<-----------------------------------------------------------------

File "test.py", line 11
```

user: Rik-de-Kort
labels: SSA: Problem due to SSA (or lack of)
issue_2751: state: open
title: Support for Numpy.ufunc.reduce
body: Would be welcome. For example for methods that are already supported, like `np.bitwise_or.reduce` 
user: tsoernes
issue_2736: state: open
title: Using numpy functions in @guvectorize-d block
body: If I issue:

    @guvectorize(['void(int32[:],int32[:],int32[:])'], '(n),()->(n)', nopython=True, target='cuda')
    def g(x,y,res):
        for i in range(x.shape[0]):
            res[i] = x[i] + y[0]
    
    res = np.zeros(4, dtype=np.int32)
    a = np.array([1, 2, 3, 4], dtype=np.int32)
    b = np.array([2], dtype=np.int32)
    g(a,b,res)
    print(res)

Everything runs fine, yielding `[3 4 5 6]` as expected. Supporting `target='cuda'` here was actually the point of issue https://github.com/numba/numba/issues/2579.

Now, say that I want to use a numpy function in my guvectorize-d code, as in the following (stupid) example:

    @guvectorize(['void(int32[:],int32[:],int32[:])'], '(n),()->(n)', nopython=True, target='cuda')
    def g(x,y,res):
        for i in range(x.shape[0]):
            res[i] = x[i] + y[0] + np.min(x)
    
    res = np.zeros(4, dtype=np.int32)
    a = np.array([1, 2, 3, 4], dtype=np.int32)
    b = np.array([2], dtype=np.int32)
    g(a,b,res)
    print(res)

And now I get: 

    Failed at nopython (nopython frontend)
    Unknown attribute 'min' of type Module(<module 'numpy' from '/usr/lib/python2.7/dist-packages/numpy/__init__.pyc'>)

Is this to be expected? I mean numpy primitives may not be used in GPU vectorized code? Noting that removing `target='cuda'`, the code snippet works.
user: pbruneau
labels: CUDA: CUDA related issue/PR
issue_2729: state: open
title: Default integer size in numpy and numba on Windows [continuation of #2643 issue]
body: I apologize for having provided an inadequate example in #2643. In fact, I meant the following, that when function is *jitted*  the type size for all locally created integer arrays is assumed to be 8 byte instead of 4 byte on Windows.

```python
import numpy as np
import numba as nb
arr = np.arange(10)
print("Initial: ", arr.dtype)

def npfun(arr):
    arr = arr + np.array([10])
    return arr

print("numpy  : ", npfun(arr).dtype)

@nb.njit
def jitfun(arr):
    arr = arr + np.array([10])
    return arr

print("njit   : ", jitfun(arr).dtype)

#----------------------------------

Initial:  int32
numpy  :  int32
njit   :  int64
```
So `numba` does not preserve the type size. While it is pretty easy to avoid this situation by providing `dtype = np.int32` (~~`dtype='i4'`~~ doesn't work either :-)) for all integer arrays. This behavior is not compliant with `numpy` on Windows and is rather annoying. FWIW, that in `numpy` the default size for `np.int_` was 8 bytes (where appropriate) and not compiler-dependent. Currently in `numpy` the size of `np.int_` is defined to be the same as C's `long` ... and in VS `long` is still 4 byte.

I understand that this  special case for `numba` will add additional costs for the maintenance. But it seems to me that this design choice (8 byte - default for `np.int_`) should be **at least** noted in the Docs (maybe some Windows related section?), because it affects the expectations of type checkers and also affects the needed signatures (`i8[:](i4[:])` instead of `i4[:](i4[:])` by default). 

This compilation will fail on Windows:

```
@nb.njit(['i4[:](i4[:])'])
def jitfun(arr):
    arr = arr + np.array([10])
    return arr
```

with:
```
...
TypingError: Failed at nopython (nopython frontend)
No conversion from array(int64, 1d, C) to array(int32, 1d, A) for '$0.9', defined at None
```

To overcome this you always need to append `dtype = np.int32` :

```
@nb.njit(['i4[:](i4[:])'])
def jitfun(arr):
    arr = arr + np.array([10], dtype=np.int32)
    return arr
```
This behavior to a certain extent  also affects the adoption of `numba` as a compliant compiler.

p.s.: I am rather unfamiliar with GitHub and don't know if comment on closed issue pings devs, so I start a new one. 
user: godaygo
issue_2721: state: open
title: keyword argument support for np.arange
body: From https://github.com/numba/numba/issues/2643#issuecomment-363472901

Need to implement the signature `np.arange([start], stop, [step], dtype=None)`
user: sklam
issue_2717: state: open
title: reproducible error with numpy import when profiling
body: Hello,
Consider the following code:

```python
@numba.jit()
def a():
    v = 3
    foo = {}
    arr = np.arange(v)
    np.random.shuffle(arr)
    return arr
```

If this is run as follows: `python -m profile -o foo.txt test.py` it throws the following exception:

```
Traceback (most recent call last):
  File "/home/tudor/anaconda3/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/tudor/anaconda3/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/tudor/anaconda3/lib/python3.6/profile.py", line 589, in <module>
    main()
  File "/home/tudor/anaconda3/lib/python3.6/profile.py", line 582, in main
    runctx(code, globs, None, options.outfile, options.sort)
  File "/home/tudor/anaconda3/lib/python3.6/profile.py", line 101, in runctx
    return _Utils(Profile).runctx(statement, globals, locals, filename, sort)
  File "/home/tudor/anaconda3/lib/python3.6/profile.py", line 64, in runctx
    prof.runctx(statement, globals, locals)
  File "/home/tudor/anaconda3/lib/python3.6/profile.py", line 424, in runctx
    exec(cmd, globals, locals)
  File "test.py", line 12, in <module>
    print(a())
NameError: global name 'np' is not defined
```

However if one removes the variable assignment to `foo` as follows:

```python
@numba.jit()
def a():
    v = 3
    arr = np.arange(v)
    np.random.shuffle(arr)
    return arr
```

then the program runs successfully.
user: tachim
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_2685: state: open
title: Radixsort in numba
body: From: https://github.com/mrocklin/sparse/issues/62

Example implementation in:
https://stackoverflow.com/questions/34023841/vectorized-radix-sort-with-numpy-can-it-beat-np-sort
user: sklam
issue_2680: state: open
title: numba.prange breaks autovectorization
body: I tried to work-around current limitations with regard to SIMD and parallelism used at the same time and found another limitation. The following code:
```
@nb.njit(error_model='numpy', fastmath=True, parallel=True)
def black_scholes( nopt, price, strike, t, rate, vol, call, put):
    chunk = int(512)
    for ch in range(nopt//chunk):
      for i in range(ch*chunk, (ch+1)*chunk):
          #body
```
enables SIMD (but it is not parallelized). While adding numba.prange like
```
    for ch in numba.prange(nopt//chunk):
      for i in range(ch*chunk, (ch+1)*chunk):
```
disables autovectorization.

user: anton-malakhov
issue_2679: state: open
title: add internal support to broadcast (@vectorize and @guvectorize) fixed-size 1-d array functions
body: we need it in order to benefit from SIMD vectorization since as of now, only explicit loops can be SIMD vectorized while leaving @vectorize and scalar forms of @guvectorize without possibility to benefit from SIMD. 
In a simplest form, such support can be implemented by compiling user's function wrapped into 1d for loop and always using `PyUFunc_RegisterLoopForType` (if it does what I mean) even for standard dtypes.
This is pre-requisite also for https://github.com/numba/numba/issues/2245 and involves refactoring of ParallelAccelerator code as well
user: anton-malakhov
issue_2677: state: open
title: Resolution of types of compile-time constants is incomplete
body: I am frequently using "factory functions" to emulate passing already compiled functions to jitted functions. This works fine if the compiled functions are in the enclosing scope. However, it stops working if they are contained in a tuple.

The following code throws an error in line 15 (tested on numba 0.36.2 and several earlier versions):
```
numba.errors.TypingError: Failed at nopython (nopython frontend)
Untyped global name 'functions': cannot determine Numba type of <class 'tuple'>
File "test.py", line 15
```

```python
import numpy as np
from numba import njit

def make_f():

    functions = (np.cos, np.sin, np.cos)
    offsets = (1,2,3)

    @njit
    def f(L):
        S = 0.0
        for i in range(3):
            s = 0.0
            for x in L[i]:
                g = functions[i]  # compile-time constant
                s += g(x+offsets[i])
            S += s
            i += 1
        return S

    return f


def main():
    y = (np.ones(200, dtype=np.float), 
         np.zeros(100, dtype=np.float), 
         np.ones(50, dtype=np.float))
    f = make_f()
    result = f(y)
    print(result)

if __name__ == "__main__":
    main()
```

As far as I understand, numba is not able to resolve the type of the values in the typle `functions` (which are functions). This should be possible, however, since these are compile-time constants. Obviously, numba can do this when the objects in the tuple are integers (or other numbers), as demonstrated by the use of `offsets`. (This works if we just use a constant function instead of iterating over functions.)

It is not clear to me whether I am describing a bug or a feature request.

user: svenrahmann
issue_2676: state: open
title: numpy in1d
body: Any chance of [numpy `in1d`](https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.in1d.html) being supported?
user: CJ-Wright
issue_2659: state: open
title: Numba fails to compile in nopython mode with a list specifing shape of an array.
body: While it is working with `tuples`. It fails with `lists` in `nopython` mode. Minimal example:

```python

import numpy as np
import numba as nb

@nb.njit
def func(size):
    arr = np.zeros([size, size])
    
func(100)

TypingError: Failed at nopython (nopython frontend)
Invalid usage of Function(<built-in function zeros>) with parameters (list(int64))
 * parameterized
```

***Python 3.6.3
numba 0.35
numpy 1.13.3***
user: godaygo
issue_2649: state: open
title: parallel schedule
body: The numba parellel with prange is awesome, but I often encounter for loops where the work needed to be done for each "i" in the loop is not the same. A scheduling option like the one in OpenMP would be a nice addition to the numba parallel feature.

For OpenMP this is descirbed as:

"dynamic: 
Use the internal work queue to give a chunk-sized block of loop iterations to each thread. When a thread is finished, it retrieves the next block of loop iterations from the top of the work queue. By default, the chunk size is 1. Be careful when using this scheduling type because of the extra overhead involved."


user: erikkjellgren
issue_2644: state: open
title: Inplace operations produce different result for jitted and pure functions.
body: Although the title speaks for itself, I gave below a minimal example with subtraction, but everything is also true for other operations (`__imul__`, `__iadd__`, ...).
``` python
import numpy as np
import numpy.random as random
import numba

random.seed(111)
points = 10*random.rand(10, 2)

def sub(pts):
    points = pts.copy()
    points -= points[3]
    return points

@numba.njit('f8[:,::1](f8[:,::1])')
def sub_njit(pts):
    points = pts.copy()
    points -= points[3]
    return points

assert np.all(sub(points) == sub_njit(points))
```

I'm not familiar with the innards of the `numpy` and the `numba`, but it looks like that `numpy` passes rhs as a copy and `numba` passes rhs as a view. I'm not sure which option is right, but in any case the result is not agreed.

```python
sub(points) == sub_njit(points)

array([[ True,  True],
       [ True,  True],
       [ True,  True],
       [ True,  True],
       [False, False],
       [False, False],
       [False, False],
       [False, False],
       [False, False],
       [False, False]], dtype=bool)
```

Python 3.6.3
numpy 1.13.3
numba 0.35
Windows 10
user: godaygo
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2640: state: open
title: numpy.random.binomial failed to convert type when input array-like probabilities
body: I am using numba to speed up a procedure that involving random number generation, in specific, binomial distribution, and then convert it into boolean. When input one number for the probability, the following code works fine and gets speed up.

```
from numba import jit, boolean

@jit
def aa():
    return np.random.binomial(n=1,p=0.5,size=17).astype(boolean)
aa()
```
```
array([ True,  True,  True,  True, False,  True, False,  True, False,
       False, False,  True,  True, False, False,  True, False], dtype=bool)
```

However, if I want to use different probabilities in each Bernoulli trial, the conversion of data type weirdly failed. Logically this should not happen, right? Is this a bug or something?

 ```
from numba import jit, boolean
prob = np.array([0.5 if i%2 ==0 else 0.9 for i in range(17)])

@jit
def aa(prob):
    return np.random.binomial(n=1,p=prob,size=17).astype(boolean)
aa(prob)
```
```
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-13-a27c3cd59f7d> in <module>()
      2 def aa(prob):
      3     return np.random.binomial(n=1,p=prob,size=17).astype(boolean)
----> 4 aa(prob)

<ipython-input-13-a27c3cd59f7d> in aa(prob)
      1 prob = [0.5 for i in range(17)]
      2 def aa(prob):
----> 3    return np.random.binomial(n=1,p=prob,size=17).astype(boolean)
      4 aa(prob)

TypeError: data type not understood
```
user: zhiruiwang
issue_2618: state: open
title: overly strict requirement for gufunc output shape symbol 
body: Numba requires all output shape symbol to be defined in the input shapes.  But numpy has no such requirement.  The output shape can be defined by the actual array given at call time.



> Typically, the size of all core dimensions in an output will be determined by the size of a core dimension with the same label in an input array. This is not a requirement, and it is possible to define a signature where a label comes up for the first time in an output, although some precautions must be taken when calling such a function. An example would be the function euclidean_pdist(a), with signature (n,d)->(p), that given an array of n d-dimensional vectors, computes all unique pairwise Euclidean distances among them. The output dimension p must therefore be equal to n * (n - 1) / 2, but it is the caller’s responsibility to pass in an output array of the right size. If the size of a core dimension of an output cannot be determined from a passed in input or output array, an error will be raised.

(Ref: https://docs.scipy.org/doc/numpy-1.13.0/reference/c-api.generalized-ufuncs.html)
user: sklam
issue_2611: state: open
title: Compilation time of a list of booleans
body: If I create a list of booleans, the compilation of the function takes a long time, especially the scaling is very bad. This problem does not occur if I use integers or floats. 
For this code
```python
from numba import jit
import numpy as np

@jit(nopython=True)
def foo(a, b):
    valid = [
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0),
        (a - 1 >= 0) and (b - 1 >= 0)
    ]

foo(1, 1)
```
the compilation time is
```
| elements | time |
-------------------
|    21    | 2.7s |
|    22    | 5.1s |
|    23    |  10s |
|   ...    |  ... |
-------------------
```

python: 3.6.3
numba: 0.35.0

Creating an empty array and setting the elements afterward, reduces the compilation time significantly [(stackexchange).](https://stackoverflow.com/questions/47264343/the-compilation-of-an-array-of-conditions-with-numba-jit-takes-a-long-time/47293732#47293732) 
user: TheIdealis
labels: performance - compile time: Performance issue occurring at compile time.
issue_2600: state: open
title: 128-bit integers
body: Can we add support for int128/uint128?  I think LLVM can generate code for this type on x86_64 (probably not ARM), but we would need to check.  Also need to ensure that nothing ever upcasts to 128-bit unless one of the operands is 128-bit.  (i.e. int64 * int64 does **not** produce int128)
user: seibert
issue_2598: state: open
title: Update documentation to reflect supported arguments to Numpy functions
body: This page needs to explicitly declare what arguments if any are supported in the functions listed:
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html
most are done, but `random` seems to be the worst offender of the missing.
user: stuartarchibald
labels: good first issue: A good issue for a first time contributor
issue_2596: state: open
title: np.random.randint with dtype
body: Hi

Shouldn't I be able to specify a numba type with dtype when using numpy to generate an array? Here generate2 works but generate1 does not. Error:

> numba.errors.InternalError: typer() got an unexpected keyword argument 'dtype'
> [1] During: resolving callee type: Function(np.random.randint)

Code:
```
import numpy as np
from numba import int32, njit


@njit
def generate1():
    return np.random.randint(0, 10, 10, dtype=int32)


@njit
def generate2():
    a = np.empty(10, dtype=int32)
    for i in range(a.size):
        a[i] = np.random.randint(0, 10)
    return a


debug = generate1()
print(debug)
```

Python 3.6.3
Numba 0.35.0
MacOS 10.13.1
user: peheje
issue_2593: state: open
title: Opaque error message on array argument with non-native byte order
body: I understand that non-native byte order arrays can or should not be accepted as arguments to functions compiled with numba.jit. However the current error message when doing so is not as informative as it can be in my opinion. See the following interactive session.

~~~py
>>> import numpy, numba
>>> a = numpy.arange(1, dtype=float)
>>> b = a.newbyteorder()
>>> a.dtype.byteorder
'='
>>> b.dtype.byteorder
'>'
>>> @numba.jit(numba.void(numba.float64[:]))
... def f(v): pass
...
>>> f(a)
>>> f(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Conda\lib\site-packages\numba\dispatcher.py", line 399, in _explain_matching_error
    raise TypeError(msg)
TypeError: No matching definition for argument type(s) pyobject
~~~

The type **pyobject** is obviously very generic here and rather confusing, especially since numpy itself is quite cool with mixing byte orders. For example in the `repr()` output of the arrays nothing about byte order is included.

~~~py
>>> repr(a)
'array([ 0.])'
>>> repr(b)
'array([ 0.])'
~~~

Also note that in the `typeof` call stack this is actually asserted properly, but the message gets silenced somewhere.

~~~py
>>> numba.typing.typeof.typeof(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Conda\lib\site-packages\numba\typing\typeof.py", line 28, in typeof
    ty = typeof_impl(val, c)
  File "C:\Conda\lib\site-packages\singledispatch.py", line 210, in wrapper
    return dispatch(args[0].__class__)(*args, **kw)
  File "C:\Conda\lib\site-packages\numba\typing\typeof.py", line 195, in _typeo_ndarray
    raise ValueError("Unsupported array dtype: %s" % (val.dtype,))
ValueError: Unsupported array dtype: >f8
~~~
user: aothms
issue_2584: state: open
title: `FunctionIR._definitions` is not updated all the time
body: The current usage is quite error-prone.  It is easy to forget updating the `._definitions` mapping.
user: sklam
issue_2578: state: open
title: Numba cfuncs not usable as scipy LowLevelCallable on Windows
body: On most platforms, this seems to work fine (inspired by [this blog post](https://ilovesymposia.com/2017/03/12/scipys-new-lowlevelcallable-is-a-game-changer/)):

```python
import numba
from numba import cfunc, carray
from numba.types import intc, CPointer, float64, intp, voidptr
from scipy import LowLevelCallable


def jit_filter_function(filter_function):
    """Decorator for use with scipy.ndimage.generic_filter."""
    jitted_function = numba.jit(filter_function, nopython=True)

    @cfunc(intc(CPointer(float64), intp, CPointer(float64), voidptr))
    def wrapped(values_ptr, len_values, result, data):
        values = carray(values_ptr, (len_values,), dtype=float64)
        result[0] = jitted_function(values)
        return 1
    return LowLevelCallable(wrapped.ctypes)

import numpy as np
import scipy.ndimage as ndi

@jit_filter_function
def fmin(values):
    result = np.inf
    for v in values:
        if v < result:
            result = v
    return result

ndi.generic_filter(np.random.random((20, 30)), fmin, 3)
```

But on platforms where `sizeof(long) == sizeof(int)`, it fails with

```
ValueError: Invalid scipy.LowLevelCallable signature "long (double *, long, double *, void *)". Expected one of: ['int (double *, intptr_t, double *, void *)', 'int (double *, npy_intp, double *, void *)', 'int (double *, long, double *, void *)', 'int (double *, long long, double *, void *)']
```

regardless of the signature I pass to `@cfunc`. SciPy explicitly expects the return type to be `int`, not `long`, but it seems I can't force Numba to produce that (equivalent) signature.

Happy for any suggestions.
user: dionhaefner
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2574: state: open
title: Expose CUDA controls for shared memory configuration
body: CUDA has allowed the shared memory bank configuration to be altered since Kepler:

http://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__DEVICE.html#group__CUDART__DEVICE_1ga4f3f8a422968f9524012f43ba852058

This is important to avoid bank conflicts when working with float64 arrays in shared memory.  We should expose set and get shared memory configuration methods on the CUDA device.
user: seibert
issue_2571: state: open
title: Array allocation for CPU and CUDA functions
body: I'm trying to write some functions that I can interchangeably use for different targets (cpu, cuda, parallel). The probelm I'm having is the allocation of a new array is different for CUDA code, e.g.:

`cuda.local.array(shape, dtype)`

vs. doing something similar for a CPU function, i.e.

`np.empty(shape, dtype)`

Is there a clever way how to deal with this without having to write separate functions?
user: philippeller
issue_2558: state: open
title: Support axis kwarg in np.linalg.norm
body: with the axis keyword! Thanks
user: nunocalaim
issue_2550: state: open
title: Importing numba takes almost half a second
body: ```
> time python -c "import numba"
python -c "import numba"  0.40s user 0.08s system 90% cpu 0.532 total
```
user: horta
labels: performance: performance related issue
issue_2546: state: open
title: liveness analysis failure
body: This somewhat nonsensical sample fails liveness analysis, as a minimum the error message could perhaps be improved?
```python
from numba import njit
import numpy as np

@njit
def foo(x):
    for k in range(10):
        y = 0
        while True:
            x[0] = y

foo(np.zeros(10))
```
backtrace:
```python
$ python foo.py 
Traceback (most recent call last):
  File "foo.py", line 11, in <module>
    foo(np.zeros(10))
  File "<path>/lib/python3.6/site-packages/numba/dispatcher.py", line 307, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "<path>/lib/python3.6/site-packages/numba/dispatcher.py", line 579, in compile
    cres = self._compiler.compile(args, return_type)
  File "<path>/lib/python3.6/site-packages/numba/dispatcher.py", line 80, in compile
    flags=flags, locals=self.locals)
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 763, in compile_extra
    return pipeline.compile_extra(func)
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 360, in compile_extra
    return self._compile_bytecode()
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 722, in _compile_bytecode
    return self._compile_core()
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 709, in _compile_core
    res = pm.run(self.status)
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 246, in run
    raise patched_exception
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 238, in run
    stage()
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 390, in stage_process_ir
    ir_processing_stage(self.func_ir)
  File "<path>/lib/python3.6/site-packages/numba/compiler.py", line 832, in ir_processing_stage
    post_proc.run()
  File "<path>/lib/python3.6/site-packages/numba/postproc.py", line 83, in run
    self._insert_var_dels()
  File "<path>/lib/python3.6/site-packages/numba/postproc.py", line 171, in _insert_var_dels
    self._patch_var_dels(vlt.deadmaps.internal, vlt.deadmaps.escaping)
  File "<path>/lib/python3.6/site-packages/numba/utils.py", line 283, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "<path>/lib/python3.6/site-packages/numba/postproc.py", line 56, in deadmaps
    self.usedefs.defmap)
  File "<path>/lib/python3.6/site-packages/numba/analysis.py", line 150, in compute_dead_maps
    raise RuntimeError(msg)
RuntimeError: Failed at nopython (processing IR)
liveness info missing for vars: {'y'}
```
user: stuartarchibald
labels: bug - ice: Bugs: internal compiler error
issue_2544: state: open
title: cumsum support
body: Can we add parallel support for cumsum (see https://en.wikipedia.org/wiki/Prefix_sum)
user: gideonsimpson
issue_2541: state: open
title: Calling function with `no_cpython_wrapper` set will segfault.
body: ```python
>>> from numba import njit
>>> @njit(no_cpython_wrapper=True)
... def foo():
...     pass
...
>>> foo()
_____
()
<built-in method foo of _dynfunc._Closure object at 0x10adac048>
[1]    656 segmentation fault  python
```

The error is due to `targetctx.get_executable` is setting a null ptr for the `cfunc` object.  See: https://github.com/numba/numba/blob/aa35fb1123fac741ab4373020df0a64f7732b0fc/numba/compiler.py#L895

Numba should have raised an exception.
user: sklam
labels: bug - segfault: Bugs that cause SIGSEGV, SIGABRT, SIGILL, SIGBUS
issue_2539: state: open
title: Support p= option in numpy.random.choice
body: In numpy.random.choice, the p= option is not supported. Please add support for this option.

For reference, the p= option specifies the probabilities for the different elements in the first argument.
user: hameerabbasi
issue_2538: state: open
title: Boolean slicing of array
body: Is there any plan to support Boolean slicing of an array?
```python
from numba import jit, prange
import numpy as np


@jit(nopython=True, parallel=True)
def internal_loop(result, values, xy):
    for i in prange(len(result)):
        result[i] = np.max(values[xy == i])
    return result

result = np.zeros(1000)
values = np.random.random((2048, 2048))
xy = np.random.randint(0, 1000, (2048, 2048))
internal_loop(result, values, xy)
```
Gives an error
```python
numba.errors.InternalError: unsupported array index type array(bool, 2d, C) in [array(bool, 2d, C)]
```

user: CJ-Wright
issue_2529: state: open
title: inference failure with np.empty on bool type
body: ~~~
import numpy as np
import numba
def f(n):
    return np.empty(n, np.bool)
print(f(10))
print(numba.njit(f)(10))
~~~

The last line fails during type inference. 

Interestingly, it works if we change to a non-bool types.
user: ninegua
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2518: state: open
title: Constant-folding pass needed to permit more "static"* expression rewrites.
body: I'm trying to write some generic code which I want to compile with numba several times, providing different values for a constant each time (constant for each compilation, similar to an `int` template parameter in C++. In particular, numba only allows constant slices for tuples, and I'd like to use a different slice in each compilation.

I've tried several approaches so far.

1. Encode an integer as a size-1 array with that many dimensions, so that the signature is different, triggering a new JIT compilation. Here's a contrived example:

```python
#!/usr/bin/env python
import numba
import numpy as np

@numba.njit
def f(a, b):
    new_shape = a.shape[:b.ndim] + a.shape[b.ndim + 1:]
    return np.ones(new_shape)

# Should return array with shape (5, 4, 2)
print f(np.zeros((5, 4, 3, 2)), np.zeros((1, 1))).shape
```

With numba 0.34, numpy 1.13.1, Python 2.7.12, Ubuntu 16.04 I get this error:
```
Failed at nopython (nopython frontend)
Invalid usage of getitem with parameters ((int64 x 3), slice<a:b>)
 * parameterized
File "axis.py", line 8
[1] During: typing of intrinsic-call at axis.py (8)
```

2. Compiling a closure, where the constant comes from the outer scope e.g.
```python
#!/usr/bin/env python
import numba
import numpy as np

def make_f(d):
    @numba.njit
    def f(a):
        new_shape = a.shape[:d] + a.shape[d + 1:]
        return np.ones(new_shape)
    return f

print make_f(2)(np.zeros((5, 4, 3, 2))).shape
```

This also fails:
```
Failed at nopython (nopython frontend)
Invalid usage of getitem with parameters ((int64 x 4), slice<a:b>)
 * parameterized
File "axis2.py", line 8
[1] During: typing of intrinsic-call at axis2.py (8)
```

3. Combining the above two approaches using `generated_jit`, where the constant n is encoded as an n-dimensional array and the dispatcher function extracts it and uses it in the returned closure. Also fails.
user: bmerry
issue_2508: state: open
title: Numba np.concatenate should support single array mode.
body: As noted here https://github.com/numba/numba/pull/2492/files#diff-62b1e2a358a67e54a61918d3e815621cR506
user: stuartarchibald
issue_2502: state: open
title: @generated_jit inside a @jitclass
body: Currently, it seems that it is not possible to have a @generated_jit function inside a @jitclass.  For example, the following code doesn't run.

For eg:
```python
@jitclass(spec = ...)
class TestClass(object):
    ...
    @generated_jit
    def my_func(...):
       if isinstance(...)
           ...
```

I can make a generated_jit function outside of the class, and then call that function from inside of the class.  But it's not very nice.  Is there a better way?
user: a-reisberg
issue_2501: state: open
title: jitclass global variable fails to to be lowered inside an njit function
body: I have the following code snippet which fails to run.

```python
from numba import *

spec = [
    ('value', int32)
]


@jitclass(spec)
class TestClass(object):
    def __init__(self, value):
        self.value = value

    def inc(self, i):
        self.value += i
        return self.value


tc = TestClass(10)


@njit
def call(inc):
    tc.inc(inc)
    return tc.value


print(call(1))

```

If I do any one of the following modifications, then it would work:
- Replace njit by jit
- Create `tc` inside of `call` instead.
- Calling `tc` inside `call` but tc is only an `int`

Is this a known bug?

Thanks.
user: a-reisberg
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2496: state: open
title: Thread placement options
body: It may be desirable to be able to tune the affinity of threads when using `parallel=True` options. The issue was raised on the mailing list here:
https://groups.google.com/a/continuum.io/forum/#!topic/numba-users/0iFVPGDHNb0
user: stuartarchibald
labels: threading: Issue involving the threading layers
issue_2475: state: open
title: Returning structure from vectorize not working
body: Something seems to go wrong with the return value when attempting to return a structured type from a `vectorize` ufunc, even though it works for `jit` function. See code below, where the returned dtype is `|V0` (numpy void of size 0).

numba 0.34, numpy 1.13.1, Ubuntu 16.04 64-bit.

```python
from __future__ import print_function
import numpy as np
import numba

dtype = np.dtype([('a', np.float32), ('b', np.int32)])
numba_dtype = numba.from_dtype(dtype)

@numba.vectorize([numba_dtype(numba.float32, numba.int32)])
def combine_ufunc(a, b):
    out = np.empty((1,), dtype)
    out[0]['a'] = a
    out[0]['b'] = b
    return out[0]

@numba.jit([numba_dtype(numba.float32, numba.int32)])
def combine_jit(a, b):
    out = np.empty((1,), dtype)
    out[0]['a'] = a
    out[0]['b'] = b
    return out[0]

print(combine_ufunc(np.float32(1.0), np.int32(2)).dtype)
print(combine_jit(np.float32(1.0), np.int32(2)).dtype)
```

Output:
```
|V0
(numpy.record, [('a', '<f4'), ('b', '<i4')])
```
user: bmerry
issue_2463: state: open
title: 2D+ Dynamic Shared Memory support
body: Right now you can pass an integer argument  to specify 1D dynamic shared memory. Allowing for a tuple argument to allow for 2D+ dynamic shared memory allocation would be a great addition.
user: ghost
labels: CUDA: CUDA related issue/PR
issue_2454: state: open
title: nopython mode generator function does NOT update structured scalar argument
body: I guess this has sth to do with the implementation details with good reason, but I'd argue the behaviours should be more consistent:

|  | non-generator | generator |
| --- | --- | --- |
| np.ndarray arg | ✅ will update | ✅ will update |
| np.record arg | ✅ will update | ❌ no update |

version 0.33.0

I need the nopython/nogil mode function to be a generator so that it stays away from python interpreter until a rolling buffer (represented by several fixed ndarray) is filled up, then yield out some intermediate data, for the calling python (slow object mode) code to handle all the data, empty the rolling buffer, then resume the nopython mode generator function (again in performance). A  structured scalar argument to the nopython/nogil function is used to pass range info of the rolling buffer (3 value for a specific case) into and out of the nopython context, since both inside/outside code need such info to address data correctly. 

I can replace the structured scalar arg with a few (at least one array per distinct dtype) ndarray args as value containers for this purpose, but that harms a lot to readability and brain health, so hope this is not too hard to fix.

structured scalar proof code:
```Python
import numba as nb
import numpy as np

point_dtype = np.dtype([
    ('x', np.float32),
    ('y', np.float32),
])


@nb.njit
def mv(pt, v, steps):
    print(
        ' --- moving point x=', pt.x, ', y=', pt.y,
        'with vector x=', v.x, ', y=', v.y,
        'for ', steps, 'steps'
    )
    d = np.sqrt(v.x ** 2 + v.y ** 2)
    for i in range(steps):
        pt.x += v.x
        pt.y += v.y
        print('  -- step', i, 'to (', pt.x, ',', pt.y, ')')


@nb.njit
def mv_yielding_d(pt, v, steps):
    print(
        ' --- moving point x=', pt.x, ', y=', pt.y,
        'with vector x=', v.x, ', y=', v.y,
        'for ', steps, 'steps'
    )
    d = np.sqrt(v.x ** 2 + v.y ** 2)
    for i in range(steps):
        pt.x += v.x
        pt.y += v.y
        print('  -- step', i, 'to (', pt.x, ',', pt.y, ')')
        yield d


pt = np.rec.array([(0, 0)], point_dtype)[0]
v = np.rec.array([(3, 7)], point_dtype)[0]

print(' *** initial point at', pt)

mv(pt, v, 5)

print(' *** moved to', pt)

for d in mv_yielding_d(pt, v, 5) or ():
    print(
        '  ** moved distance=', d,
        'now at', pt
    )

print(' *** final point at', pt)

```
which outputs:
```pycon
 *** initial point at (0.0, 0.0)
 --- moving point x= 0.0 , y= 0.0 with vector x= 3.0 , y= 7.0 for  5 steps
  -- step 0 to ( 3.0 , 7.0 )
  -- step 1 to ( 6.0 , 14.0 )
  -- step 2 to ( 9.0 , 21.0 )
  -- step 3 to ( 12.0 , 28.0 )
  -- step 4 to ( 15.0 , 35.0 )
 *** moved to (15.0, 35.0)
 --- moving point x= 15.0 , y= 35.0 with vector x= 3.0 , y= 7.0 for  5 steps
  -- step 0 to ( 18.0 , 42.0 )
  ** moved distance= 7.6157732009887695 now at (15.0, 35.0)
  -- step 1 to ( 21.0 , 49.0 )
  ** moved distance= 7.6157732009887695 now at (15.0, 35.0)
  -- step 2 to ( 24.0 , 56.0 )
  ** moved distance= 7.6157732009887695 now at (15.0, 35.0)
  -- step 3 to ( 27.0 , 63.0 )
  ** moved distance= 7.6157732009887695 now at (15.0, 35.0)
  -- step 4 to ( 30.0 , 70.0 )
  ** moved distance= 7.6157732009887695 now at (15.0, 35.0)
 *** final point at (15.0, 35.0)
```

ndarray proof code:
```Python
import numba as nb
import numpy as np


@nb.njit
def mv(pt, v, steps):
    print(
        ' --- moving point x=', pt[0], ', y=', pt[1],
        'with vector x=', v[0], ', y=', v[1],
        'for ', steps, 'steps'
    )
    d = np.sqrt(v[0] ** 2 + v[1] ** 2)
    for i in range(steps):
        pt[0] += v[0]
        pt[1] += v[1]
        print('  -- step', i, 'to (', pt[0], ',', pt[1], ')')


@nb.njit
def mv_yielding_d(pt, v, steps):
    print(
        ' --- moving point x=', pt[0], ', y=', pt[1],
        'with vector x=', v[0], ', y=', v[1],
        'for ', steps, 'steps'
    )
    d = np.sqrt(v[0] ** 2 + v[1] ** 2)
    for i in range(steps):
        pt[0] += v[0]
        pt[1] += v[1]
        print('  -- step', i, 'to (', pt[0], ',', pt[1], ')')
        yield d


pt = np.zeros(2, np.float32)
v = np.array([3, 7], np.float32)

print(' *** initial point at', pt)

mv(pt, v, 5)

print(' *** moved to', pt)

for d in mv_yielding_d(pt, v, 5) or ():
    print(
        '  ** moved distance=', d,
        'now at', pt
    )

print(' *** final point at', pt)
```
which will outputs:
```pycon
 *** initial point at [ 0.  0.]
 --- moving point x= 0.0 , y= 0.0 with vector x= 3.0 , y= 7.0 for  5 steps
  -- step 0 to ( 3.0 , 7.0 )
  -- step 1 to ( 6.0 , 14.0 )
  -- step 2 to ( 9.0 , 21.0 )
  -- step 3 to ( 12.0 , 28.0 )
  -- step 4 to ( 15.0 , 35.0 )
 *** moved to [ 15.  35.]
 --- moving point x= 15.0 , y= 35.0 with vector x= 3.0 , y= 7.0 for  5 steps
  -- step 0 to ( 18.0 , 42.0 )
  ** moved distance= 7.6157732009887695 now at [ 18.  42.]
  -- step 1 to ( 21.0 , 49.0 )
  ** moved distance= 7.6157732009887695 now at [ 21.  49.]
  -- step 2 to ( 24.0 , 56.0 )
  ** moved distance= 7.6157732009887695 now at [ 24.  56.]
  -- step 3 to ( 27.0 , 63.0 )
  ** moved distance= 7.6157732009887695 now at [ 27.  63.]
  -- step 4 to ( 30.0 , 70.0 )
  ** moved distance= 7.6157732009887695 now at [ 30.  70.]
 *** final point at [ 30.  70.]
```

user: complyue
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2432: state: open
title: ParallelAccelerator Support for Array Selection
body: We need to parallelize array selection codes like below. The selection should be fused with the boolean expression code also. The output should be written to vector(s) at first to be space efficient before conversion to array. Writes should have minimal thread synchronizations.

```python
@numba.njit(parallel=True)
def f(A):
    return A[A>.5]
```
user: ehsantn
issue_2408: state: open
title: Using list.append() with `parallel=True` fails as it is not thread-safe
body: With the work on `prange` allowing multiple threads to append to a list, the lack of thread-safety in `list.append` whilst in NPM is a problem. Brief note here https://github.com/numba/numba/pull/2391
user: stuartarchibald
issue_2390: state: open
title: Better loop index codegen for simd-vectorization
body: Refer to https://github.com/numba/llvmlite/issues/270

(EDIT)

The llvmlite issue identified several ways to enable autovec of loops.  But, we don't know which technique offers the best performance.  We should benchmark them and see if there is opportunity in numba to provide better code.  Or simply document the behavior for users to manual optimize their loops.

Here's a summary of the techniques:

* generic 1d loop over `for i in range(arr.shape[0])`
* generic 2d (nd) loop indexing over `arr.shape[n]`
* assuming constant inner shape with `assert arr.shape[-1] == 8`

Additionally, techniques that require changing the codegen:

* using llvm loop metadata (e.g. clang-loop-pragma) to control autovec behavior (interleave, unroll, vector-width)
user: sklam
issue_2334: state: open
title: Suggestion: read jit types from annotations 
body: The `@jit` allows supplying expected types

```py
@jit(int32(int32, int32))
def f(x, y):
    return x + y
```

Function type annotations in Python 3.5+ look like a good fit for this use case, annotations are easy enough to read from the decorated function properties , allowing you to write:

```py
@jit
def f(x: int32, y: int32) -> int32:
    return x + y
```

With the added bonus that the same type annotations could improve IDE support (e.g. completions and error checking in PyCharm) and mypy tests.

This might not cover every use case, but could probably cover a lot of common cases, including when several types are accepted using `Union[]`
user: mangecoeur
issue_2333: state: open
title: Using `zip` results in 3-4x slower code compared to indexing
body: This could be because it is used repeatedly in a small loop within a much bigger loop. Here is code to reproduce:

```python
import numpy as np
import numba

def moments_central_nb(image, center=None, use_zip=True, order=3):
    mu = np.zeros((order + 1,) * image.ndim)
    if center is None:
        center = np.mean(np.column_stack(np.nonzero(image)), axis=0)
    if use_zip:
        _moments_central_nb_loop(image, center, mu)
    else:
        _moments_central_nb_loop_nozip(image, center, mu)
    return mu


@numba.njit
def _moments_central_nb_loop(image, center, mu):
    for coord, val in np.ndenumerate(image):
        if val > 0:
            for powers in np.ndindex(mu.shape):
                curval = val
                for c, ctr, p in zip(coord, center, powers):
                    dc = c - ctr
                    cr = 1
                    for pcount in range(p):
                        cr *= dc
                    curval *= cr
                mu[powers] += curval


@numba.njit
def _moments_central_nb_loop_nozip(image, center, mu):
    for coord, val in np.ndenumerate(image):
        if val > 0:
            for powers in np.ndindex(mu.shape):
                curval = val
                for i in range(image.ndim):
                    c, ctr, p = coord[i], center[i], powers[i]
                    dc = c - ctr
                    cr = 1
                    for pcount in range(p):
                        cr *= dc
                    curval *= cr
                mu[powers] += curval
```

Then time it with:

```python
# get some data
from skimage import data
horse = data.horse().astype(float)

# compute the centroid
center = np.mean(np.column_stack(np.nonzero(horse)), axis=0)

# warm up the JIT
_ = moments_central_nb(horse, center=center, use_zip=True)
_ = moments_central_nb(horse, center=center, use_zip=False)

# time it
%timeit moments_central_nb(horse, center=center, use_zip=True)
%timeit moments_central_nb(horse, center=center, use_zip=False)
```

On my machine, `use_zip=True` takes 500ms, while `use_zip=False` takes 150ms. It's worth noting that the tuples being zipped have a length of just 2. This might be expected behavior compared to indexing. If so, feel free to close.
user: jni
labels: performance - run time: Performance issue occurring at run time.
issue_2327: state: open
title: Please add np.tile implementation in nopython mode
body: Right now this is crucial, How can I circumvent the fact that Numba does not support it?
user: nunocalaim
issue_2317: state: open
title: Feature request: a unified guvectorize type string
body: A non-trivial fraction of my compile-time debug cycle consists of fixing unintentional inconsistencies between the JIT string and the GUFunc string in a `@guvectorize` decorator. I concede that I might be an odd duck in the degree to which I use generalized ufuncs, but I'd still like to see a way to unify the two strings together.

I've mocked up a way to do so here: https://gist.github.com/mcg1969/694204e08df3a7f9e327e4791af7a721

I attempted to implement this using as much of the existing approaches and code as I could, to ensure it is both as flexible and back-compatible as possible. I'm quite pleased with the results and frankly am considering using this in my own projects. I'd love to see it supported alongside the traditional two-string approach.

I'm happy to submit a PR that implements a back-compatible approach.
user: mcg1969
issue_2305: state: open
title: Fixing error model propagation
body: Investigating the issue https://github.com/numba/numba/issues/2299, I discovered several problems:

1. Setting error model during compile-time does not work well with on-demand compilation with the rest of the code.  Error-model behavior may end up depending on the compilation order.  When composing jit'ed function with vectorize'd function, the numpy errormodel on the outer ufunc could be ignored.

2. The complex number and cmath implementation will always raise `ZeroDivisionError` regardless of the error model flag.

I'm suggesting the following fixes:

* [ ] Make error model a runtime option instead of compile-time option.  There will be a new error-model option: "inherit", which follows the error semantic of the caller.  The errormodel option will be passed down to each callee as a hidden function argument.  When transitioning from the interpreter into numba compiled code, the default error model is "python" unless the function is a (g)ufunc, in which case the error model is default to "numpy".
* [ ] Complex number implementation will use "inherit" model.

user: sklam
issue_2299: state: open
title: @vectorize: target parallel can fail to propagate errors
body: Observed on Windows 10, Python 3.6, Numba 0.31, Numpy 1.12. The following snippet allows to reproduce the issue (note that without the complex math operation a RuntimeWarning is emitted by the cpu target and not propagated in the parallel target).

````python
import cmath as cm
import numpy as np
from numba import vectorize, float64, complex128


def inv(a):
    return 1/cm.sqrt(a)

cpu_inv = vectorize([complex128(float64)], target='cpu')(inv)

par_inv = vectorize([complex128(float64)], target='parallel')(inv)

arr = np.linspace(-1, 1, 21)
print(arr)

try:
    cpu_inv(arr)
except ZeroDivisionError:
    print('Errored')

print(par_inv(arr))
user: MatthieuDartiailh
issue_2268: state: open
title: cuda.reduce is not caching compiled code properly 
body: The internal helper cuda kernels inside cuda.reduce implementation is not being cached properly.  As a result, every call requires a compilation, which slows down the feature significantly.


Also see #2266
user: sklam
labels: CUDA: CUDA related issue/PR
issue_2256: state: open
title: `--annotate-html` should warn if it doesn't produce any output..
body: Not knowing how `numba --annotate-html ...` works I simply tried to run it on some Python source file. That didn't produce any output, but didn't warn me either.
It would be useful if a warning would be generated, telling me that in fact no output was generated, and why (perhaps with a pointer to the docs explaining what the code needs to look like to have this annotation feature work.)
user: stefanseefeld
issue_2247: state: open
title: Error when trying to nest numba.cfunc calls
body: It can be useful to create a C-callback from a function that calls a C-callback. A specific use case is using scipy.integrate.quad to solve an integral which contains within it another integral (this is different from a double integral). Currently this is not possible in numba. Consider the following minimal working example:

```python
import numba

#Default signature for example functions
sig = numba.double(numba.double)
```
Use numba to make two precompiled functions that do the same thing except one is a jit-compiled function and the other is a numba-created C-callback. The following code compiles.

```python
@numba.cfunc(sig)
def c_foo(x):
    return x

@numba.jit(sig)
def j_foo(x):
    return x
```

Now make a C-callback from the jit-compiled function. This will compile.

```python
@numba.cfunc(sig)
def c_bar(x):
    return j_foo(x)
```

Now make a C-callback from the C-callback function. This fails to compile and raises a TypingError : 

```python
@numba.cfunc(sig)
def c_baz(x):
    return c_foo.ctypes(x)

>>>TypingError: Untyped global name 'c_foo': cannot determine Numba type of <class 'numba.ccallback.CFunc'>
```

Now that scipy 0.19 has introduced their LowLevelCallable object, numba should support creating c-callbacks that call other c-callbacks.
user: FaustinCarter
issue_2243: state: open
title: numba fails to infer 'endian' numpy dtypes
body: Here is a sample case:

```
import numba
import numpy as np

betype = np.ones((120, 120), dtype='>u2')   # big-endian
normtype = np.ones((120, 120), dtype='uint16')   # ? endian

@numba.autojit(nopython=True)
def add_arrays(arr1, arr2):
    return arr1 + arr2

# Fails
add_arrays(betype, betype)

# Succeeds
add_arrays(normtype, normtype)
```

I have many tif files the are read in as numpy '>u2' type. Right now I plan to just change the dtypes to something that works, but should there / will there be support for this dtype?

Thanks!
user: damca
labels: discussion: An issue requiring discussion
issue_2242: state: open
title: Use PEP 509 to invalidate cache of compiled @jit functions
body: Right now, Numba violates Python semantics by "freezing" the value of globals as well as the inlining other function bodies when compiling a `@jit` function in nopython mode.  This is because there has been no efficient way to detect when these external dependencies have changed.

Python 3.6 includes [PEP 509](https://www.python.org/dev/peps/pep-0509/), which adds a version number to dictionaries that Numba's dispatcher could check at call time to determine if dependent global variables or functions have been modified since the function was compiled.
user: seibert
labels: caching: Issue involving caching
issue_2235: state: open
title: Python crashes when calling compiled function with default argument
body: ## Code for reproducing the error:
```python
import numpy as np
from numba import jit

a = np.zeros(2)
@jit
def foo(a=a):
    a[0] += 1
foo()
```
## Result:
 Crash of python.exe. At the same time `foo(a=a)` works fine.

## Environment:
```python
import sys
import numba
import platform
print(sys.version)
print(numba.__version__)
print(platform.platform())
```
Output:
```
3.5.2 |Anaconda 4.2.0 (64-bit)| (default, Jul  5 2016, 11:41:13) [MSC v.1900 64 bit (AMD64)]
0.30.0
Windows-7-6.1.7601-SP1
```
user: amorgun
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2229: state: open
title: Make thread backend configurable at runtime (TBB or old system)
body: Right now TBB support must be enabled at compile time, and TBB is always used if enabled.  Before turning TBB on in our conda packages of Numba, we would like the thread pool implementation (our current one or TBB) to be changeable at runtime.  This will facilitate benchmark comparisons and testing both thread pools with the same build of Numba.
user: seibert
issue_2226: state: open
title: Error when using cffi.lib.myfun directly and not through alias
body: Having code like this:

    import numba
    numba.register_module(mymodule)
    @numba.jit(nopython=1)
    def f():
       return mymodule.lib.fun()`
doesn't work. when the similar

    import numba
    numba.register_module(mymodule)
    fun = mymodule.lib.fun
    @numba.jit(nopython=1)
    def f():
       return fun()
does work
(I use cffi 1.9.1, python 3.5, numba 0.29.0)
This is the error I get:

     Traceback (most recent call last):
      File "<ipython-input-44-44c455c5d6d6>", line 10, in <module>
        f(a)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/dispatcher.py", line 286, in _compile_for_args
        return self.compile(tuple(argtypes))

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/dispatcher.py", line 532, in compile
        cres = self._compiler.compile(args, return_type)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/dispatcher.py", line 81, in compile
        flags=flags, locals=self.locals)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 684, in compile_extra
        return pipeline.compile_extra(func)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 348, in compile_extra
        return self._compile_bytecode()

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 649, in _compile_bytecode
        return self._compile_core()

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 636, in _compile_core
        res = pm.run(self.status)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 235, in run
        raise patched_exception

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 227, in run
        stage()

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 576, in stage_nopython_backend
        self._backend(lowerfn, objectmode=False)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 531, in _backend
        lowered = lowerfn()

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 518, in backend_nopython_mode
        self.flags)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/compiler.py", line 802, in native_lowering_stage
        lower.lower()

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 126, in lower
        self.lower_normal_function(self.fndesc)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 161, in lower_normal_function
        entry_block_tail = self.lower_function_body()

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 186, in lower_function_body
        self.lower_block(block)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 201, in lower_block
        self.lower_inst(inst)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/contextlib.py", line 77, in __exit__
        self.gen.throw(type, value, traceback)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/errors.py", line 249, in new_error_context
        six.reraise(type(newerr), newerr, sys.exc_info()[2])

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/six.py", line 658, in reraise
        raise value.with_traceback(tb)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/errors.py", line 243, in new_error_context
        yield

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 201, in lower_block
        self.lower_inst(inst)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 238, in lower_inst
        val = self.lower_assign(ty, inst)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 383, in lower_assign
        return self.lower_expr(ty, value)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/lowering.py", line 790, in lower_expr
        impl = self.context.get_getattr(ty, expr.attr)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/targets/base.py", line 521, in get_getattr
        llval = self.get_constant(attrty, pyval)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/targets/base.py", line 446, in get_constant
        return self.get_constant_generic(None, ty, val)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/targets/base.py", line 436, in get_constant_generic
        return impl(self, builder, ty, val)

      File "/home/tal/anaconda3/envs/py35/lib/python3.5/site-packages/numba/targets/builtins.py", line 269, in constant_function_pointer
        return builder.inttoptr(ptrval, ptrty)

    LoweringError: 'NoneType' object has no attribute 'inttoptr'
user: talkaminker
labels: bug - failure to compile: Bugs: failed to compile valid code
issue_2220: state: open
title: Silent casting of heterogenous lists
body: In answering a stackoverflow question, I wanted to report what might be termed a bug. I'm using Numba 0.29.0. 

In the docs, it says that lists must be "strictly homogenous" or numba will reject them. However if I have a function:

```python
@nb.njit
def func(x):
    s = 0.0
    for a,b in x:
        s += a*b
        
    return s
```

and then call it with:

```python
func([(1,1), (18.3,1), (2,2)])  # return 23 instead of 23.3
```

I'm not sure about the exact implementation, but it looks like numba is looking at the types of the first item in the list and then assuming that they are the same thus producing a different output than the undecorated function would. 

The following function fails as expected:

```
@nb.njit
def func2(x):
    s = 1
    for a in x:
        s *= a
    return s

func2([1.1, 1, 3, 7.6])
```

gives:

```
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-61-d39e4199a593> in <module>()
----> 1 func2([1.1, 1, 3, 7.6])

TypeError: can't unbox heterogenous list
```

Is it a bug that Numba is not checking type consistency of complex list items?
user: synapticarbors
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2205: state: open
title: Support dtype from string spec in CUDA array allocators
body: I am getting an error where it appears I am specifying the proper signature for this device function, but it is still throwing an invalid usage of function error when compiling.  I am also a fairly new numba user so this could very well be user error

```numba.errors.TypingError: Failed at nopython (nopython frontend)
Invalid usage of Function(<DeviceFunction py_func=<function devfunc at 0x0000000F32607A60> signature=(array(float64, 1d, C),) -> float64>) with parameters (array(float64, 1d, C))
Known signatures:
* (array(float64, 1d, C),) -> float64
File "testingstuff.py", line 13


```

```python 
import numpy as np
from numba import cuda

@cuda.jit('float64(float64[::1])',device=True)
def devfunc(arr):
    return 1.0;

@cuda.jit('void(float64[:])')
def kern(arr):
    toarr=cuda.local.array(10,'float64')
    for i in range(10):
        toarr[i] = arr[i]
    print(devfunc(toarr))

kern[1,1](np.zeros(10))
```


user: blankea
labels: CUDA: CUDA related issue/PR
issue_2200: state: open
title: Mention distutils environment variables in ahead-of-time compilation
body: We should mention that Numba selects the same compiler that was used to compile CPython when compiling shared extensions, and this can be overridden with the ``CC`` environment variable.
user: seibert
issue_2196: state: open
title: Speed regression in 0.29.0
body: Referring to the discussion in #2176 it looks like there is a major speed regression from 0.28.1 to 0.29.0. The example function below and similar tight loops, doing merely more than nan checks, additions etc, only run at a fraction of the initial speed. This heavily affects the usability of numba as a replacement for some C implementations and renders 0.29.0 unusable for me. I'd also be happy to sponsor a bug bounty for this issue.

```python
import numpy as np
import numba as nb
print nb.__version__

@nb.njit
def nanmin_numbagg_1dim(a):
    amin = np.infty
    all_missing = 1
    for ai in a.flat:
        if ai <= amin:
            amin = ai
            all_missing = 0
    if all_missing:
        amin = np.nan
    return amin

x = np.random.random(100000)
x[x>0.7] = np.nan
%timeit nanmin_numbagg_1dim(x)
```
```
0.34.0
10000 loops, best of 3: 190 µs per loop
0.29.0
10000 loops, best of 3: 192 µs per loop
0.28.1
10000 loops, best of 3: 57.4 µs per loop
```
user: ml31415
labels: llvm: LLVM related issues
performance - run time: Performance issue occurring at run time.
issue_2187: state: open
title: Rethink JIT Class enhancements
body: The following series of PR is closed due to lack of progress.  

* https://github.com/numba/numba/pull/1865   (new types too complicated)
* https://github.com/numba/numba/pull/1958 (question on the spelling for `self` type; also for the complication to caching/pickling)
* https://github.com/numba/numba/pull/1964 (complication to caching/pickling)

We need to redesign this features and perhaps internal details in jitclasses.
user: sklam
issue_2181: state: open
title: np.linalg.norm() does not accept axis argument in nopython mode 
body: When I try to run the following

    import numba

    @jit(nopython = True)
    def numba_func(x)
        x_norm = np.linalg.norm(dx, axis = 1)
        return(x_norm)

    x = np.ones([3,3])
    numba_func(x)

I get `InternalError: norm_impl() got an unexpected keyword argument 'axis'`

I am running numba 0.28.1 in python 2.7.9.
user: breedlun
issue_2176: state: open
title: Speedups for jitted reductions
body: I was playing around with code like this:

``` python
import numpy as np
import numba as nb
import bottleneck as bn
import numbagg as nbg

@nb.njit
def nanmin_demo(x):
    if x.size == 0:
        raise ValueError("nanmin(): empty array")
    ret = np.nan
    for i, x_ in enumerate(x.flat):
        if not np.isnan(x_):
            ret = x_
            break
    if np.isnan(ret):
        return ret

    # This should be x.flat[i:], so that the array is
    # not iterated again unnecessarily. Better ideas?
    for x_ in x.flat:
        if x_ < ret:
            ret = x_
    return ret


@nb.njit
def nanmin_numba(a):
    if a.size == 0:
        raise ValueError("nanmin(): empty array")
    for view in np.nditer(a):
        minval = view.item()
        break
    for view in np.nditer(a):
        v = view.item()
        if not minval < v and not np.isnan(v):
            minval = v
    return minval


@nb.njit
def nanmin_numbagg_1dim(a):
    amin = np.infty
    all_missing = 1
    for ai in a.flat:
        if ai <= amin:
            amin = ai
            all_missing = 0
    if all_missing:
        amin = np.nan
    return amin


impls = [nanmin_demo, nanmin_numba, nanmin_numbagg_1dim, nbg.nanmin, bn.nanmin]

for i in range(4):
    x = np.random.random(100000)
    x[x>0.3334*i] = np.nan
    res = np.array([impl(x) for impl in impls])
    assert np.all(res[0] == res) or np.all(np.isnan(res))
    x.reshape((-1, 100))
    res = np.array([impl(x) for impl in impls])
    assert np.all(res[0] == res) or np.all(np.isnan(res))
    for impl in impls:
        %timeit impl(x)
    print '--------'
print nb.__version__
```

nanmin_impl is the currently imlemented overload. It's compared with the inbuilt numpy version, bottleneck and another experimental implementation. The timing looks like this for me:

```
10000 loops, best of 3: 63.5 µs per loop
10000 loops, best of 3: 154 µs per loop
10000 loops, best of 3: 62.8 µs per loop
10000 loops, best of 3: 151 µs per loop
10000 loops, best of 3: 68.4 µs per loop
--------
10000 loops, best of 3: 50.9 µs per loop
1000 loops, best of 3: 405 µs per loop
10000 loops, best of 3: 57.3 µs per loop
10000 loops, best of 3: 151 µs per loop
10000 loops, best of 3: 68.4 µs per loop
--------
10000 loops, best of 3: 51.1 µs per loop
1000 loops, best of 3: 409 µs per loop
10000 loops, best of 3: 57.4 µs per loop
10000 loops, best of 3: 151 µs per loop
10000 loops, best of 3: 68.5 µs per loop
--------
10000 loops, best of 3: 51.6 µs per loop
10000 loops, best of 3: 126 µs per loop
10000 loops, best of 3: 57.5 µs per loop
10000 loops, best of 3: 151 µs per loop
10000 loops, best of 3: 68.5 µs per loop
--------
0.28.1
```

```
10000 loops, best of 3: 59.4 µs per loop
10000 loops, best of 3: 153 µs per loop
10000 loops, best of 3: 192 µs per loop
1000 loops, best of 3: 207 µs per loop
10000 loops, best of 3: 68.5 µs per loop
--------
10000 loops, best of 3: 102 µs per loop
1000 loops, best of 3: 406 µs per loop
10000 loops, best of 3: 192 µs per loop
1000 loops, best of 3: 207 µs per loop
10000 loops, best of 3: 68.4 µs per loop
--------
10000 loops, best of 3: 102 µs per loop
1000 loops, best of 3: 408 µs per loop
10000 loops, best of 3: 192 µs per loop
1000 loops, best of 3: 208 µs per loop
10000 loops, best of 3: 68.4 µs per loop
--------
10000 loops, best of 3: 102 µs per loop
10000 loops, best of 3: 126 µs per loop
10000 loops, best of 3: 192 µs per loop
1000 loops, best of 3: 206 µs per loop
10000 loops, best of 3: 68.6 µs per loop
--------
0.29.0
```
As you can see, for some unlucky cases, the current implementation is 8x slower than `nanmin_demo`. About half of this speedup comes from using `x.flat` instead of `nd.iter`. I'm actually not sure, if there are some good reasons to use `nd.iter` instead of `x.flat`? If so, I'd be curious to learn, cause it would also affect a bunch of code that I wrote for [numpy_groupies](https://github.com/ml31415/numpy-groupies).

The other major speedup seems to be some unlucky branching being done when `if` is fed with more than a simple nan-check or comparison. The jitted code seems to suffer much more from adding compound if-statements than ordinary C code. Any ideas why that is?

If it should actually be valid, to use the flatiter for these cases, I'd go ahead and put some more optimizations together for a pull request.

user: ml31415
labels: performance: performance related issue
issue_2173: state: open
title: Feature request: Allow arithmetic operations with arrays and tuples
body: Since arithmetic operations between arrays and tuples are not supported yet, it is not possible to easily aggregate (i.e. without unpacking / single element assigning) results from functions which return tuples. Pseudo use case:

``` python
import numpy as np
from numba import njit

@njit
def do_something(i):
    return i+1, i*2

@njit
def aggregate_something(n):
    a = np.zeros(2, dtype=np.int64)
    for i in range(n):
        a += do_something(i)
    return a
```

Also note that the following gives a readable error message when simply adding an array and a tuple. When the addition is combined with an assignment, the error message is rather obscure.

``` python
import numpy as np
from numba import njit

def add_array_tuple(a, t):
    a + t

def add_assign_array_tuple(a, t):
    a += t

t = (1, 2)
a = np.array(t)
for func in (add_array_tuple, add_assign_array_tuple):
    func(a, t)
    njit()(func)(a, t)
```

Traceback for `func is add_array_tuple`:

``` python
Traceback (most recent call last):
  File "array_tuple_add.py", line 14, in <module>
    njit()(func)(a, t)
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 309, in _compile_for_args
    raise e
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 286, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 532, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 81, in compile
    flags=flags, locals=self.locals)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 684, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 348, in compile_extra
    return self._compile_bytecode()
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 649, in _compile_bytecode
    return self._compile_core()
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 636, in _compile_core
    res = pm.run(self.status)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 235, in run
    raise patched_exception
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 227, in run
    stage()
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 436, in stage_nopython_frontend
    self.locals)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 785, in type_inference_stage
    infer.propagate()
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 761, in propagate
    raise errors[0]
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 128, in propagate
    constraint(typeinfer)
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 431, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 395, in resolve
    raise TypingError(msg, loc=self.loc)
numba.errors.TypingError: Failed at nopython (nopython frontend)
Invalid usage of + with parameters (array(int64, 1d, C), (int64 x 2))
Known signatures:
 * (int64, int64) -> int64
 * (int64, uint64) -> int64
 * (uint64, int64) -> int64
 * (uint64, uint64) -> uint64
 * (float32, float32) -> float32
 * (float64, float64) -> float64
 * (complex64, complex64) -> complex64
 * (complex128, complex128) -> complex128
 * (uint8,) -> uint64
 * (uint32,) -> uint64
 * (uint16,) -> uint64
 * (uint64,) -> uint64
 * (int32,) -> int64
 * (int16,) -> int64
 * (int64,) -> int64
 * (int8,) -> int64
 * (float32,) -> float32
 * (float64,) -> float64
 * (complex64,) -> complex64
 * (complex128,) -> complex128
 * parameterized
File "array_tuple_add.py", line 5
[1] During: typing of intrinsic-call at array_tuple_add.py (5)
```

Traceback for `func is add_assign_array_tuple`:

``` python
Traceback (most recent call last):
  File "array_tuple_add.py", line 14, in <module>
    njit()(func)(a, t)
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 309, in _compile_for_args
    raise e
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 286, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 532, in compile
    cres = self._compiler.compile(args, return_type)
  File "/home/maba/dev/numba/git/numba/numba/dispatcher.py", line 81, in compile
    flags=flags, locals=self.locals)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 684, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 348, in compile_extra
    return self._compile_bytecode()
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 649, in _compile_bytecode
    return self._compile_core()
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 636, in _compile_core
    res = pm.run(self.status)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 235, in run
    raise patched_exception
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 227, in run
    stage()
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 436, in stage_nopython_frontend
    self.locals)
  File "/home/maba/dev/numba/git/numba/numba/compiler.py", line 785, in type_inference_stage
    infer.propagate()
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 761, in propagate
    raise errors[0]
numba.errors.TypingError: Failed at nopython (nopython frontend)
Internal error at <numba.typeinfer.IntrinsicCallConstraint object at 0x7ffbe8e0a438>:
--%<-----------------------------------------------------------------
Traceback (most recent call last):
  File "/home/maba/dev/numba/git/numba/numba/errors.py", line 243, in new_error_context
    yield
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 431, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 386, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 1021, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "/home/maba/dev/numba/git/numba/numba/typing/context.py", line 189, in resolve_function_type
    res = defn.apply(args, kws)
  File "/home/maba/dev/numba/git/numba/numba/typing/templates.py", line 185, in apply
    sig = generic(args, kws)
  File "/home/maba/dev/numba/git/numba/numba/typing/npydecl.py", line 235, in generic
    assert len(sig.args) == 3
AttributeError: 'NoneType' object has no attribute 'args'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 128, in propagate
    constraint(typeinfer)
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 431, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "/home/maba/miniconda3/envs/numba-git/lib/python3.5/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/maba/dev/numba/git/numba/numba/errors.py", line 249, in new_error_context
    six.reraise(type(newerr), newerr, sys.exc_info()[2])
  File "/home/maba/dev/numba/git/numba/numba/six.py", line 658, in reraise
    raise value.with_traceback(tb)
  File "/home/maba/dev/numba/git/numba/numba/errors.py", line 243, in new_error_context
    yield
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 431, in __call__
    self.resolve(typeinfer, typeinfer.typevars, fnty=self.func)
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 386, in resolve
    sig = typeinfer.resolve_call(fnty, pos_args, kw_args)
  File "/home/maba/dev/numba/git/numba/numba/typeinfer.py", line 1021, in resolve_call
    return self.context.resolve_function_type(fnty, pos_args, kw_args)
  File "/home/maba/dev/numba/git/numba/numba/typing/context.py", line 189, in resolve_function_type
    res = defn.apply(args, kws)
  File "/home/maba/dev/numba/git/numba/numba/typing/templates.py", line 185, in apply
    sig = generic(args, kws)
  File "/home/maba/dev/numba/git/numba/numba/typing/npydecl.py", line 235, in generic
    assert len(sig.args) == 3
numba.errors.InternalError: 'NoneType' object has no attribute 'args'
[1] During: typing of intrinsic-call at array_tuple_add.py (8)
--%<-----------------------------------------------------------------

File "array_tuple_add.py", line 8
```

user: mbargull
issue_2167: state: open
title: Make __init__ not mandatory for `jitclass`
body: It is not possible to have a `jitclass` (without fields) and omit the explicit `__init__` method.

``` python
from numba import jitclass


@jitclass([])
class Class:
    def method(self, x):
        return x
```

traceback:

``` python
Traceback (most recent call last):
  File "jitclass_init_mandatory.py", line 3, in <module>
    @jitclass([])
  File "/home/maba/dev/numba/git/numba/numba/jitclass/decorators.py", line 27, in wrap
    return register_class_type(cls, spec, types.ClassType, ClassBuilder)
  File "/home/maba/dev/numba/git/numba/numba/jitclass/base.py", line 207, in register_class_type
    __doc__=docstring))
  File "/home/maba/dev/numba/git/numba/numba/jitclass/base.py", line 90, in __new__
    outcls._set_init()
  File "/home/maba/dev/numba/git/numba/numba/jitclass/base.py", line 98, in _set_init
    init = cls.class_type.instance_type.methods['__init__']
KeyError: '__init__'
```
\[edit: fixed `def`/`class` typo\]
user: mbargull
issue_2165: state: open
title: Iterators do not get properly consumed inside generators
body: Using `Numba 0.29.0`.
In the following code
- `yield_from_iter` shows the aberrant behavior,
- `yield_from_iter_loop` only illustrates the same behavior inside a loop,
- `list_from_iter_loop` shows the correct behavior while returning a list instead of being a generator.

``` python
from numba import njit


def yield_from_iter(a, sep):
    i = iter(a)
    for x in i:
        yield x
    # `i` _should_ be consumed by now, but only its first element is
    yield sep
    for x in i:
        yield x
    yield sep


def yield_from_iter_loop(a, sep):
    i = iter(a)
    for _ in range(len(a)+2):
        for x in i:
            yield x
        # `i` _should_ be consumed by now,
        # but only one element per iteration gets consumed
        yield sep


def list_from_iter_loop(a, sep):
    i = iter(a)
    ret = []
    for _ in range(len(a)+2):
        for x in i:
            ret.append(x)
        # when saving into a list, `i` is completely consumed now
        ret.append(sep)
    return ret


a = list(range(4))
sep = 999
for pyfunc in (yield_from_iter,
               yield_from_iter_loop,
               list_from_iter_loop):
    cfunc = njit()(pyfunc)
    print(pyfunc.__name__)
    print(" pyfunc:", list(pyfunc(a, sep)))
    print(" cfunc :", list(cfunc(a, sep)))
```

output:

``` python
yield_from_iter
 pyfunc: [0, 1, 2, 3, 999, 999]
 cfunc : [0, 1, 2, 3, 999, 1, 2, 3, 999]
yield_from_iter_loop
 pyfunc: [0, 1, 2, 3, 999, 999, 999, 999, 999, 999]
 cfunc : [0, 1, 2, 3, 999, 1, 2, 3, 999, 2, 3, 999, 3, 999, 999, 999]
list_from_iter_loop
 pyfunc: [0, 1, 2, 3, 999, 999, 999, 999, 999, 999]
 cfunc : [0, 1, 2, 3, 999, 999, 999, 999, 999, 999]
```

```
```

user: mbargull
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_2162: state: open
title: Support partial typing
body: Allow function that has control-flow paths that fail typing as long as it has at least one type-able path.  The untype-able path will produce a runtime exception if it is executed.

Sample case 1: recursive function that reduce dimension

``` python
def foo(array):
     if array.ndim > 1:
        # Type inference does not know about runtime branch,
        # the following line would evetually trigger compilation of ``foo(scalar)`` and fail
        # with "scalar has no attribute `.ndim`.
        return foo(array[0])
    else:
       return array.sum()
```

Sample case 2: ad-hoc polymorphism with runtime typechecking

``` python
def foo(arg):
     if isinstance(arg, Array):
           # if ary is not Array, this branch is still visited by type inference and may fail.
           ...
    else:
           ...
```

user: sklam
issue_2131: state: open
title: Feature Request: Support Atomic Add on complex128 arrays in CUDA
body: Currently NUMBA supports int32, float32, and float64 operands only for atomic add.

It would be nice to have it for complex128 too, so one doesn't need to create separate arrays for the real and imaginary part when working with such arrays on the GPU. 

user: Escapado
labels: CUDA: CUDA related issue/PR
issue_2108: state: open
title: Syntax for "local" array definition
body: This feature would provide a custom version of `np.empty` that allocates a "local" array with fixed dimensions.  In python mode, this function would behave identically to `np.empty`, but in nopython mode, it would allocate a non-reference counted array such that LLVM could unroll loops, promote values to registers, and other optimizations that are generally hard to do with a heap-allocated, reference counted array.  This function would also work on the GPU targets, behaving just like the numba.cuda.local array does now.

The motivation for this feature is both to make it easier to write ufuncs that can be recompiled for CPU or GPU targets (the latter being a place where reference counting should be avoided), as well as to improve CPU performance for cases where fixed size scratch arrays in C and FORTRAN have much higher performance than Numba arrays.

user: seibert
issue_2104: state: open
title: numpy statistics functions
body: These functions are generically pretty useful in numerical code:

http://docs.scipy.org/doc/numpy/reference/routines.statistics.html

user: seibert
issue_2102: state: open
title: Array stacking and concatenation
body: This is a meta-issue to track the various NumPy stacking and concatenation methods.
#2069 covers hstack, vstack, dstack, column_stack.

Still need:
- tile()
- split()
- fliplr()
- flipud()

Is there a method to physically transpose an array in memory (rather than return a view)?

user: seibert
issue_2101: state: open
title: Finish off np.linalg
body: What's left to do in the np.linalg library?

user: seibert
issue_2093: state: open
title: Generalized parallel compute features
body: NumPy-style ufuncs and gufuncs are powerful parallel computing styles, but there are potential extensions that could cover other use cases:
- Non-broadcasting inputs (for passing in arrays that should be treated as constants)
- Window functions
- In place updates, "iterate until"

Look to loopy and Tensorflow for ideas.

user: seibert
issue_2089: state: open
title: Ensure that jit, vectorize and guvectorize functions can mutually call each other
body: We still have some situations where calls to one kind of function cannot be embedded in the other.

user: seibert
issue_2085: state: open
title: C code target?
body: Julia appears to be reviving the C backend to LLVM:

https://github.com/JuliaComputing/llvm-cbe

There may be some value in having Numba be able to emit C code.

user: seibert
issue_2083: state: open
title: JIT class support for object mode on method-by-method basis
user: seibert
issue_2079: state: open
title: Make `@vectorize` and `@guvectorize` independent of NumPy code
body: Our various implementations of `@vectorize` and `@guvectorize` (single core, multicore, GPU) use different amounts of NumPy machinery to implement the broadcast logic of ufuncs.  If we completely separate our implementation from NumPy, we will be able to reuse much of this code across all targets.

Note: How would this impact reduction methods?

user: seibert
issue_2065: state: open
title: Caching with closures
body: As an example, the factory function below.  I'm assuming this is tricky to handle generally, but maybe this kind of situation where the only closure references are other jit'ed functions could be special-cased?

This was previously discussed at https://github.com/numba/numba/pull/1051#issuecomment-132806795, although I don't seem to be getting the warnings added there.

``` python
import numba
from numba import njit

def make_func(f):
    f = njit(cache=True)(f)
    @njit(cache=True)
    def inner(a):
        ans = 0.0
        for i in range(a):
            ans += f(i)
        return ans
    return inner

def f(x):
    return x / 2.0 + 55

fast_a = make_func(f)
```

user: chris-b1
labels: caching: Issue involving caching
issue_2063: state: open
title: Scope of variables can go over if statement
body: Consider the following code:

```
#!/usr/bin/env python

from __future__ import print_function
from numba import jit

@jit
def f(x):
    print("x:", x)
    if x == 0:
        i = 1
        print("i:", i)
    else:
        print("i:", i)

f(1)
```

When calling f(1), an error should occur (i is not defined when the print in the else block is reached).
However, this code somehow outputs i: 0.

When the environment variable
    >> export NUMBA_DISABLE_JIT=1
is used (so that normal Python is used), this code behaves as expected (and generates an error).

This is tested with Python 2.7.12 with Numba 0.27.0.

[code.zip](https://github.com/numba/numba/files/438957/code.zip)

user: bryanhe
issue_2011: state: open
title: improve cuda gufunc: multiple output arguments
body: failing example

``` python
import numpy as np
import numba as nb


@nb.guvectorize('f8[:], f8[:], f8[:]', '()->(),()', nopython=True, target='cuda')
def foo(inp, out1, out2):
    out1[0] = inp[0] * 2.3
    out2[0] = inp[0] + 1

inp = np.arange(10, dtype=np.float64)
out1 = np.empty_like(inp)
out2 = inp
for _ in range(3):
    foo(inp, out=(out1, out2))
    print('out1', out1)
    print('out2', out2)
```

user: sklam
labels: CUDA: CUDA related issue/PR
issue_2010: state: open
title: improve gufunc by catching common user errors
body: error 1: redefine scalar output variable:

``` python
@guvectorize(["(intp, intp[:])"], "()->()", nopython=True)
def foo(x, out):
    out = x
```

error 2: output never written to

``` python

@guvectorize(["(intp, intp[:])"], "()->()", nopython=True)
def foo(x, out):
    pass
```

user: sklam
issue_1991: state: open
title: Controlling LLVM optimizations from numba
body: I couldn't find any mechanism to control LLVM optimization passes from numba via llvmlite. Would this even be possible?

I have code of the following form.

```
def make_f(offsets):
    @njit 
    def f(bigarray):
        for i in range(len(bigarray)):
            for j in offsets:
                do_stuff_with(bigarray[i+j])
    return f 
```

Since the argument offsets (a small array, length 2 to 50 with offsets) is constant at compile time of f, I was hoping that the inner loop (for j) was unrolled into a constant number of iterations. This seems to be true for small lengths of offsets (up to 10, according to my timing measurements), but not for larger arrays. This normally makes sense because of the code size increase, but here I would specifically like to instruct LLVM to perform aggressive loop unrolling.

user: svenrahmann
labels: llvm: LLVM related issues
issue_1966: state: open
title: Feature request: Abstract Base Classes with standard data structure interfaces  and methods
body: Hello Numba team,

I would like to define interfaces for a library that anyone can extend, without making an apriori  concrete implementation. Also It would be cool to be able to make my own version of built in data structures (array, list etc) by implementing minimal interfaces and  getting other methods for free.

Would this be possible at some point? 

user: datnamer
issue_1903: state: open
title: Enums not interchangeable with namedtuples
body: Consider this code: 

``` python
from collections import namedtuple
from enum import IntEnum
import numba as nb

en = IntEnum('en', 'a b c d')
nt_type = namedtuple('nt_type', 'a b c d')
nt = nt_type(1, 2, 3, 4)

@nb.njit
def cmp(x, y):
    return x.a == y.a

assert cmp(nt, nt)
assert cmp(en, en)
assert cmp(nt, en)
```

It works well with namedtuples, but rejects the enums as being python objects:

```
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/numba/compiler.py", line 249, in run
    stage()
  File "/usr/local/lib/python2.7/dist-packages/numba/compiler.py", line 468, in stage_nopython_frontend
    legalize_given_types(self.args, self.return_type)
  File "/usr/local/lib/python2.7/dist-packages/numba/compiler.py", line 719, in legalize_given_types
    "mode" % (i, a))
TypeError: Arg 0 of pyobject is not legal in nopython mode

Failed at nopython (nopython frontend)
Arg 0 of pyobject is not legal in nopython mode
```

I'm not familiar with the details, but as I had planned to replace my tuple fiddlings with proper enums, this stops me from replacing them.

user: ml31415
issue_1870: state: open
title: parallel target with vectorize requires types to be specified
body: The parallel target produces normal numpy ufuncs, not numba `DUFunc` objects:

``` python
@vectorize
def rel_diff_serial(x, y):
    return 2 * (x - y) / (x + y)

@vectorize(target='parallel')
def rel_diff_parallel(x, y):
    return 2 * (x - y) / (x + y)

type(rel_diff_serial)   # numba.npyufunc.dufunc.DUFunc
type(rel_diff_parallel) # numpy.ufunc
```

This means that just adding `target='parallel'` to `@vectorize` functions can break things because there won't be implementations for any types - should the parallel target produce `DUFunc`s as well?

user: gmarkall
issue_1849: state: open
title: nopython mode does not understand a module registered via cffi
body: The following works

``` python
from ncephes import cprob
from numba import jit

# I need this line here because I cannot use
# cprob.incbet directly inside numba_incbet
incbet = cprob.incbet

@jit(nogil=True, nopython=True)
def numba_incbet(a, b, x):
    return incbet(a, b, x)

print(numba_incbet(1., 3., 0.3))
# prints 0.657
```

But

``` python
@jit(nogil=True, nopython=True)
def numba_incbet(a, b, x):
    return cprob.incbet(a, b, x)
```

gives

> LoweringError: Internal error:
> AssertionError: Storing i8\* to ptr of double (double, double, double)\* ('$0.2'). FE type ExternalFunctionPointer((float64, float64, float64) -> float64)
> File "ai.py", line 9
> 
> Failed at nopython (nopython mode backend)
> Internal error:
> AssertionError: Storing i8\* to ptr of double (double, double, double)\* ('$0.2'). FE type ExternalFunctionPointer((float64, float64, float64) -> float64)
> File "ai.py", line 9

Source: https://github.com/Horta/ncephes

user: horta
issue_1847: state: open
title: improve jitclass doc
body: - mention special attributes like `MyJitclassName.class_type.instance_type`
- mention recursive type
- add dev-docs on internal structure of jitclass and Box type

user: sklam
issue_1846: state: open
title: make jitclass pickleable
body: from ML: https://groups.google.com/a/continuum.io/d/msg/numba-users/-oqsIRkWZfA/VhkzrocaAgAJ

user: sklam
issue_1843: state: open
title: Compile-time getattr for constant objects
body: Currently compile time attribute access for constants only works if the object with the attribute is a subclass of `ModuleType`. It would be nice if this worked for any object.

``` python
In [1]: import numba as nb

In [2]: class Config(object):
   ...:     def __init__(self, **kwargs):
   ...:         for k, v in kwargs.items():
   ...:             setattr(self, k, v)
   ...:

In [3]: config = Config(a=1, b=2)

In [4]: @nb.njit
   ...: def foo(a):
   ...:     return a + config.a
   ...:

In [5]: foo(1)    # This fails
<TypingError>

In [6]: from types import ModuleType

In [7]: class Config2(ModuleType):
   ...:     def __init__(self, **kwargs):
   ...:         for k, v in kwargs.items():
   ...:             setattr(self, k, v)
   ...:

In [8]: config2 = Config2(a=1, b=2)

In [9]: @nb.njit
   ...: def foo2(a):
   ...:     return a + config2.a
   ...:

In [10]: foo2(1)    # But this works
Out[10]: 2
```

user: jcrist
issue_1834: state: open
title: Support for numpy masked arrays
body: Do you plan supporting numpy masked arrays soon?

Currently (v0.25) Numba seems to ignore masks completely:

```
>>> import numpy as np
>>> import numba as nb
>>> def f(a, i):
>>>      return np.isfinite(a[i])
>>> g = nb.jit(f)
>>> a = np.ma.array([1, 2], mask=[0, 1])

>>> f(a, 0), f(a, 1)
(True, masked)  

>>> g(a, 0), g(a, 1)
(True, True)  
```

Anyway, thanks so much for Numba, it's an extremely useful and fascinating project!

user: forman
issue_1833: state: open
title: Caching issue : functions in different modules
body: The issue is as follow and is illustrated in the https://github.com/MatthieuDartiailh/numba_cache_bug repo (follow the instruction between parenthesis to reproduce): 
- define a cache jitted function in a module (bar and barfoo in dummy/utils.py)
- define another cache jitted function in another module (foo in dummy/dummy/foo.py)
- run once (python test_script.py)
- modify the first function (change the return value of barfoo)
- run again : calling the first function directly yields the right result calling the second still return the old result. 

I do not know for sure if the exact file structure is necessary (it is the one in which the bug was uncovered). I reproduced the error under Windows 7 and 10 (64bits) and Manjaro-linux 64bits (VM on windows host) using numba 0.25. In the original code the function where much more complex (in case that makes a difference (inlining not in cause ?)).

I will be happy to help solve this but I will need pointers.

user: MatthieuDartiailh
labels: caching: Issue involving caching
issue_1825: state: open
title: Feedback on np.nditer
body: xref https://github.com/numba/numba/pull/1787

First of all -- it's awesome to see nditer supported in Numba! I am very pleased to see this development.

Two usability issues that tripped me up:
- numba apparently needs a tuple of arrays for the argument to `nditer`. If you supply a list of arrays instead, you get an unhelpful `TypingError` when you attempt to run the function. Unfortunately, [all the docstring examples](http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.nditer.html) for nditer use lists of ararys.
- You can't use scalar arrays to index arrays, but have to unpack them into scalars by using `.item()` first. Otherwise, you get `TypeError: unsupported array index type array(int64, 0d, C) in [array(int64, 0d, C)]`. My code would look a little nicer if I didn't need to insert calls to `.item()`.

user: shoyer
issue_1822: state: open
title: scalar type takes lower precedence in casting with array types
body: The problem is noticed in [this mailing list post ](https://groups.google.com/a/continuum.io/forum/?utm_medium=email&utm_source=footer#!msg/numba-users/zqAU6MDdMf8/f8yg0kt9AQAJ) that a scalar float in an expression of `float32 (array) + float64 (scalar)` will result in `float64` in numba but python/numpy will produce `float32`.  If the RHS of `+` is an array, the result is `float64`.

The casting rule is however irregular; for example, `int32 (array) + float32 (scalar) -> float64 (array)`.

The full listing:

```
int8 (array) + int8 (scalar) -> int8 (array)
int8 (array) + int16 (scalar) -> int8 (array)
int8 (array) + int32 (scalar) -> int8 (array)
int8 (array) + int64 (scalar) -> int8 (array)
int8 (array) + float32 (scalar) -> float32 (array)
int8 (array) + float64 (scalar) -> float64 (array)
int8 (array) + complex64 (scalar) -> complex64 (array)
int8 (array) + complex128 (scalar) -> complex128 (array)
int16 (array) + int8 (scalar) -> int16 (array)
int16 (array) + int16 (scalar) -> int16 (array)
int16 (array) + int32 (scalar) -> int16 (array)
int16 (array) + int64 (scalar) -> int16 (array)
int16 (array) + float32 (scalar) -> float32 (array)
int16 (array) + float64 (scalar) -> float64 (array)
int16 (array) + complex64 (scalar) -> complex64 (array)
int16 (array) + complex128 (scalar) -> complex128 (array)
int32 (array) + int8 (scalar) -> int32 (array)
int32 (array) + int16 (scalar) -> int32 (array)
int32 (array) + int32 (scalar) -> int32 (array)
int32 (array) + int64 (scalar) -> int32 (array)
int32 (array) + float32 (scalar) -> float64 (array)
int32 (array) + float64 (scalar) -> float64 (array)
int32 (array) + complex64 (scalar) -> complex128 (array)
int32 (array) + complex128 (scalar) -> complex128 (array)
int64 (array) + int8 (scalar) -> int64 (array)
int64 (array) + int16 (scalar) -> int64 (array)
int64 (array) + int32 (scalar) -> int64 (array)
int64 (array) + int64 (scalar) -> int64 (array)
int64 (array) + float32 (scalar) -> float64 (array)
int64 (array) + float64 (scalar) -> float64 (array)
int64 (array) + complex64 (scalar) -> complex128 (array)
int64 (array) + complex128 (scalar) -> complex128 (array)
float32 (array) + int8 (scalar) -> float32 (array)
float32 (array) + int16 (scalar) -> float32 (array)
float32 (array) + int32 (scalar) -> float32 (array)
float32 (array) + int64 (scalar) -> float32 (array)
float32 (array) + float32 (scalar) -> float32 (array)
float32 (array) + float64 (scalar) -> float32 (array)
float32 (array) + complex64 (scalar) -> complex64 (array)
float32 (array) + complex128 (scalar) -> complex64 (array)
float64 (array) + int8 (scalar) -> float64 (array)
float64 (array) + int16 (scalar) -> float64 (array)
float64 (array) + int32 (scalar) -> float64 (array)
float64 (array) + int64 (scalar) -> float64 (array)
float64 (array) + float32 (scalar) -> float64 (array)
float64 (array) + float64 (scalar) -> float64 (array)
float64 (array) + complex64 (scalar) -> complex128 (array)
float64 (array) + complex128 (scalar) -> complex128 (array)
complex64 (array) + int8 (scalar) -> complex64 (array)
complex64 (array) + int16 (scalar) -> complex64 (array)
complex64 (array) + int32 (scalar) -> complex64 (array)
complex64 (array) + int64 (scalar) -> complex64 (array)
complex64 (array) + float32 (scalar) -> complex64 (array)
complex64 (array) + float64 (scalar) -> complex64 (array)
complex64 (array) + complex64 (scalar) -> complex64 (array)
complex64 (array) + complex128 (scalar) -> complex64 (array)
complex128 (array) + int8 (scalar) -> complex128 (array)
complex128 (array) + int16 (scalar) -> complex128 (array)
complex128 (array) + int32 (scalar) -> complex128 (array)
complex128 (array) + int64 (scalar) -> complex128 (array)
complex128 (array) + float32 (scalar) -> complex128 (array)
complex128 (array) + float64 (scalar) -> complex128 (array)
complex128 (array) + complex64 (scalar) -> complex128 (array)
complex128 (array) + complex128 (scalar) -> complex128 (array)
```

The above is generated by:

``` python

import numpy as np
from itertools import product

types = [
    np.int8, np.int16, np.int32, np.int64,
    np.float32, np.float64,
    np.complex64, np.complex128,
]

for at, bt in product(types, types):
    av = np.array([123], dtype=at)
    bv = bt(12.5)
    cv = av + bv
    print('{} (array) + {} (scalar) -> {} (array)'.format(av.dtype, bv.dtype, cv.dtype))
```

numpy version: 1.10

user: sklam
labels: discussion: An issue requiring discussion
issue_1818: state: open
title: jitclass: support setattr and self.__setattr__ within njit compiled functions
body: I want to initialize a jitted class with quite a list of arrays as attributes, which all need to get initialized. This means, defining the spec and initializing the attributes is highly repetitive code. Unfortunately, the logical solution, to define the list of required attributes once, and then derive as well the spec as the initialization code from it, fails. The problem is, that I can set attributes neither with `setattr` nor `self.__setattr__`, only with direct `self.asdf =` syntax. As the logic to set some attribute is obviously already implemented, it would be great if all ways of setting an attribute would actually work. 

For reference, this is the usecase I tried to get working:

``` python
def get_col_type(col, for_spec=False):
    typename = defaults.get(col, 'int64') # Arbitrary generic logic
    if for_spec:
        if typename == 'bool':
            typename += '_'
        return getattr(nb, typename)[:]
    return typename

event_buffer_fields = ('maxlen', 'len', 'id') # ... lengthy list
event_buffer_spec = OrderedDict((col, get_col_type(col, for_spec=True)) for col in event_buffer_fields)
_event_buffer_dtypes = dict((col, get_col_type(col, for_spec=False)) for col in event_buffer_fields)
event_buffer_dtypes = namedtuple('event_buffer_dtypes', event_buffer_fields)(**_event_buffer_dtypes)

@nb.jitclass(event_buffer_spec)
class JEventBuffer(object):
    def __init__(self, N):
        for attr in event_buffer_fields[2:]:
            setattr(self, attr, np.zeros(N, dtype=event_buffer_dtypes[attr]))
```

This are the errors I'm getting for the both unsuccessful attempts:

```
Failed at nopython (nopython frontend)
Untyped global name 'setattr'
File "<ipython-input-2-be43349577fb>", line 39
```

```
Failed at nopython (nopython frontend)
Unknown attribute "__setattr__" of type instance.jitclass.JEventStratData#3d7a040<maxlen:int64,len:int64,id:array(int64, 1d, A),...>
File "<ipython-input-25-fb3f90759197>", line 7
```

user: ml31415
issue_1807: state: open
title: NRT memory leak when calling function which calls a generator function
body: Calling a function which in turn calls a generator while passing over an NRT allocated object induces a memory leak. Affects release as well as git master version. Reproducer:

``` python
from numba import njit
from numba.runtime import rtsys

@njit
def generator(some_nrt_allocated_obj):
    yield 0
    # yielding multiple times does not increase leakage!
    yield 1

@njit
def caller():
    some_nrt_allocated_obj = [0]
    generator(some_nrt_allocated_obj)
    # calling generator multiple times does not increase leakage!
    generator(some_nrt_allocated_obj)
    # consuming generator does not increase leakage!
    s = 0
    for x in generator(some_nrt_allocated_obj):
        s += x
    return s 

@njit  # does not matter if compiled or not
def main():
    # each call introduces new allocation without corresponding deallocation
    caller()
    caller()
    caller()

main()
_, _, mi_alloc, mi_free = rtsys.get_allocation_stats()
print(mi_alloc - mi_free)  # prints "3" since 'main' calls 'caller' three times
```

user: mbargull
issue_1750: state: open
title: np.timedelta64 not recognized in nopython mode
body: As raised on the [ML](https://groups.google.com/a/continuum.io/forum/#!topic/numba-users/4ajAJaQFJnc) the below code fails:

``` python
import numpy as np
from numba import jit, vectorize
from numba.types import NPDatetime

@jit(NPDatetime('D')(NPDatetime('D')), nopython=True)
def add1(date):
    return date + np.timedelta64(1, 'D')
```

``` python-traceback
  File "C:/Users/Dave/Code/sandbox/numba_dates.py", line 19, in <module>
    @jit(NPDatetime('D')(NPDatetime('D')), nopython=True)

  File "C:\bin\Anaconda3\lib\site-packages\numba\decorators.py", line 169, in wrapper
    disp.compile(sig)

  File "C:\bin\Anaconda3\lib\site-packages\numba\dispatcher.py", line 458, in compile
    cres = self._compiler.compile(args, return_type)

  File "C:\bin\Anaconda3\lib\site-packages\numba\dispatcher.py", line 79, in compile
    flags=flags, locals=self.locals)

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 687, in compile_extra
    return pipeline.compile_extra(func)

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 375, in compile_extra
    return self.compile_bytecode(bc, func_attr=self.func_attr)

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 384, in compile_bytecode
    return self._compile_bytecode()

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 668, in _compile_bytecode
    res = pm.run(self.status)

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 254, in run
    raise patched_exception

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 246, in run
    stage()

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 472, in stage_nopython_frontend
    self.locals)

  File "C:\bin\Anaconda3\lib\site-packages\numba\compiler.py", line 803, in type_inference_stage
    infer.propagate()

  File "C:\bin\Anaconda3\lib\site-packages\numba\typeinfer.py", line 587, in propagate
    raise errors[0]

  File "C:\bin\Anaconda3\lib\site-packages\numba\typeinfer.py", line 114, in propagate
    constraint(typeinfer)

  File "C:\bin\Anaconda3\lib\site-packages\numba\typeinfer.py", line 375, in __call__
    raise UntypedAttributeError(ty, self.attr, loc=self.inst.loc)

UntypedAttributeError: Unknown attribute "timedelta64" of type Module(<module 'numpy' from 'C:\\bin\\Anaconda3\\lib\\site-packages\\numpy\\__init__.py'>)
```

user: dhirschfeld
issue_1721: state: open
title: Parallel vectorized function
body: Hi,

I've already asked the question on [StackOverflow](http://stackoverflow.com/questions/35459065/numbas-parallel-vectorized-functions) but I'm more and more convinced that it might be a bug in numba.

It boils down to:

```
@nb.vectorize([nb.float64(nb.float64, nb.float64)], target='parallel')
def numba_sum_parallel(element1, element2):
    return element1 + element2
```

gives me strange results when I use it together with `reduce` or `accumulate`

```
array = np.ones(100000)
np.testing.assert_almost_equal(numba_sum_parallel.reduce(array), np.sum(array))
AssertionError: 
Arrays are not almost equal to 7 decimals
 ACTUAL: 93238.0
 DESIRED: 100000.0
```

or

```
AssertionError: 
Arrays are not almost equal to 7 decimals
 ACTUAL: 83883.0
 DESIRED: 100000.0
```

I'm not sure if I shouldn't use `target=parallel` on such a vectorized function or if that's unintentional. Maybe you can have a look.

numba 0.23.1, numpy 1.10.1, python 3.5.1 64bit, windows 10 64-bit (4 core machine)

Thanks in advance,
Michael

user: MSeifert04
issue_1711: state: open
title: Add a user API for CUDA kernel cache/shared memory configuration
body: As noted in https://groups.google.com/a/continuum.io/forum/?utm_medium=email&utm_source=footer#!msg/numba-users/S0Vrk2ZfyQg/nNcxcnzzEAAJ it's quite fiddly to set the cache configuration for a kernel - support is exposed in the driver API, but there seems to be no way to reach this without going through a "private" API in a fiddly way. One way to do it is:

``` python
import numpy as np
from numba import cuda, types

@cuda.jit
def axpy(a, x, y):
    for i in range(len(x)):
        y[i] += a + x[i]

n = 10
a = 2
x = np.random.rand(n)
y = np.random.rand(n)

# Launch once to force compilation (you may do this multiple times to set cache
# config for implementations for multiple argument types)
axpy(a, x, y)

# Get the definition for the argument types we want to configure for
# e.g. (int64, array(float64, 1d, C), array(float64, 1d, C))
array_type = types.Array(types.float64, 1, 'C')
t = (types.int64, array_type, array_type)
axpy_def = axpy.definitions[t]

# Get the underlying CUDA function for the definition
axpy_func = axpy_def._func.get()

# Configure equal shared memory and cache
axpy_func.cache_config(prefer_equal=True)
axpy(a, x, y)

# Configure larger L1 cache
axpy_func.cache_config(prefer_cache=True)
axpy(a, x, y)

# Configure larger shared memory
axpy_func.cache_config(prefer_shared=True)
axpy(a, x, y)

# Configure for no preference (the default)
axpy_func.cache_config()
axpy(a, x, y)
```

This would be improved if there were a way to change this more easily - I think it would be a good start to allow setting the cache configuration for all argument types, and only adding support for configuring the cache on a per-argument-types basis later on if necessary.

user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_1694: state: open
title: Initializer for parent of jitclass with inheritance
body: A simple test of `jitclass` with inheritance seems to work just fine.  But if I want to call the parent class's `__init__` function, I have to jump through a strange hoop.  Here's a working example:

``` python
specA = [('valueA', nb.int64)]
# Note that this does not get jitclassed, because we can't (yet) inherit from jitted classes
class A(object):
    def __init__(self, value):
        self.valueA = value

specB = [('valueB', nb.int64)]
# Note that this does not get jitclassed, because we can't (yet) inherit from jitted classes
class B(object):
    def __init__(self, value):
        self.valueB = value

specC = [('valueC', nb.int64)]
@nb.jitclass(specA+specB+specC)
class C(A, B):
    __init__A = A.__init__
    __init__B = B.__init__
    def __init__(self, a, b, c):
        #super(C).__init__(self, a)  # Fails with `Untyped global name 'super'`
        #A.__init__(self, a)  # Fails with `Untyped global name 'A'`
        self.__init__A(a)  # Works fine
        self.__init__B(b)  # Works fine
        self.valueC = c

c = C(17, 23, 31)
print(c.valueA, c.valueB, c.valueC)
```

This seems to work just fine.  In particular, `c.valueA` is correctly defined.

I can imagine that making `super` work might be hard.  Intriguingly, if I change the definition to

``` python
    __init__A = super(C).__init__
```

it fails with `class members are not yet supported: _C__init__A`.  I don't know what that means in this context, because I can define `__init__A` to be something else that I had thought would be identical...

But I really don't understand why `A.__init__` can be used to define a `C` method, but cannot be called from within `C`'s own `__init__` function.  Is there a way to make this work more naturally, or even get `super` working?  Is something insidious going on that I'm not aware of, but is about to destroy my code?

user: moble
issue_1688: state: open
title: Internal error when using CFFI .lib directly
body: Apparently `numba.njit` can infer the type of the CFFI function if I extract it first to a variable, but fails if I acces `mod.lib.func` directly. Example:

``` python
# hyper/hyper.py
from numba import cffi_support
import _hyper
cffi_support.register_module(_hyper)
```

``` python
# numba_cffi.py
from hyper.hyper import _hyper
from numba import njit


c_hyp = _hyper.lib.hyp2f1x

@njit
def cffi_test_ok(x):
    return c_hyp(1, 1, 1, x)

@njit
def cffi_test_fail(x):
    return _hyper.lib.hyp2f1x(1, 1, 1, x)


if __name__ == '__main__':
    print(cffi_test_ok(1))
    print(cffi_test_fail(1))
```

``` bash
$ python numba_cffi.py 
1.0
Traceback (most recent call last):
  File "numba_cffi.py", line 19, in <module>
    print(cffi_test_fail(1))
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/dispatcher.py", line 171, in _compile_for_args
    return self.compile(sig)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/dispatcher.py", line 349, in compile
    flags=flags, locals=self.locals)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 665, in compile_extra
    return pipeline.compile_extra(func)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 366, in compile_extra
    return self.compile_bytecode(bc, func_attr=self.func_attr)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 375, in compile_bytecode
    return self._compile_bytecode()
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 652, in _compile_bytecode
    return pm.run(self.status)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 251, in run
    raise patched_exception
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 243, in run
    res = stage()
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 463, in stage_nopython_frontend
    self.locals)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/compiler.py", line 780, in type_inference_stage
    infer.propagate()
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/typeinfer.py", line 565, in propagate
    raise errors[0]
numba.errors.TypingError: Failed at nopython (nopython frontend)
Internal error at resolving type of attribute "lib" of "$0.1":
--%<-----------------------------------------------------------------
Traceback (most recent call last):
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/typeinfer.py", line 111, in propagate
    constraint(typeinfer)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/typeinfer.py", line 352, in __call__
    attrty = typeinfer.context.resolve_getattr(ty, self.attr)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/typing/context.py", line 149, in resolve_getattr
    attrty = self.resolve_module_constants(typ, attr)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/typing/context.py", line 195, in resolve_module_constants
    ty = self.resolve_value_type(attrval)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/typing/context.py", line 214, in resolve_value_type
    tp = typeof(val, Purpose.constant)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/site-packages/numba/typing/typeof.py", line 29, in typeof
    return typeof_impl(val, c)
  File "/home/juanlu/.miniconda3/envs/hyper35/lib/python3.5/functools.py", line 743, in wrapper
    return dispatch(args[0].__class__)(*args, **kw)
AttributeError: cffi library '_hyper' has no function, constant or global variable named '__class__'
--%<-----------------------------------------------------------------

File "numba_cffi.py", line 14
```

user: astrojuanlu
issue_1681: state: open
title: caching functions taking a JIT class
body: ``` python
In [71]: import numba as nb
In [72]: nb.__version__
Out[72]: '0.23.1'

In [73]: @nb.jitclass([
    ...: ('value', nb.float64[:])
    ...: ])
    ...: class Container(object):
    ...:     def __init__(self, value):
    ...:         self.value = value

In [74]: @nb.jit(nopython=True)
    ...: def fun(a, container):
    ...:     return a + container.value[0]

In [75]: c = Container(np.array([1,2.4,3]))

In [77]: fun(1, c)
Out[77]: 2.0

In [78]: @nb.jit(nopython=True, cache=True)
    ...: def fun(a, container):
    ...:     return a + container.value[0]

In [79]: fun(1, c)
---------------------------------------------------------------------------
PicklingError                             Traceback (most recent call last)
<ipython-input-79-53b1add910cd> in <module>()
----> 1 fun(1, c)

C:\Users\Chris\Anaconda\lib\site-packages\numba\dispatcher.pyc in _compile_for_args(self, *args, **kws)
    169         assert not kws
    170         sig = tuple([self.typeof_pyval(a) for a in args])
--> 171         return self.compile(sig)
    172 
    173     def inspect_llvm(self, signature=None):

C:\Users\Chris\Anaconda\lib\site-packages\numba\dispatcher.pyc in compile(self, sig)
    354 
    355             self.add_overload(cres)
--> 356             self._cache.save_overload(sig, cres)
    357             return cres.entry_point
    358 

C:\Users\Chris\Anaconda\lib\site-packages\numba\dispatcher.pyc in save_overload(self, sig, cres)
    664                     break
    665             overloads[key] = data_name
--> 666             self._save_index(overloads)
    667 
    668         self._save_data(data_name, cres)

C:\Users\Chris\Anaconda\lib\site-packages\numba\dispatcher.pyc in _save_index(self, overloads)
    753     def _save_index(self, overloads):
    754         data = self._source_stamp, overloads
--> 755         data = self._dump(data)
    756         with self._open_for_write(self._index_path) as f:
    757             pickle.dump(self._version, f, protocol=-1)

C:\Users\Chris\Anaconda\lib\site-packages\numba\dispatcher.pyc in _dump(self, obj)
    765 
    766     def _dump(self, obj):
--> 767         return pickle.dumps(obj, protocol=-1)

PicklingError: Can't pickle <type 'function'>: attribute lookup __builtin__.function failed
```

user: chris-b1
labels: caching: Issue involving caching
issue_1668: state: open
title: Guvectorize signature with frozen arguments
body: Here is a simple function:

```
def fun(x,y,out):
    out[0] = x[0]*y[0]
    out[1] = x[0]-y[1]
    out[2] = x[1]*y[0]
```

If would be great if this kind of function could be guvectorized by:

```
ftylist = [float64[:](float64[:],float64[:])]
signature = '(p),(q)->(3)'
# signature = '(p),(q)->(r)` # does not work because size of output is unknown
gufun = guvectorize(ftylist=ftylist, signature=signature)(fun)
out = gufun(x,y)
```

In the numpy mailing list there was discussion about whether this kind of signature should be part of the gufun standard and whether it could be extended to more general formulas where the size of outputs is a function of inputs (such as `(n),(n)->(n*(n-1)/2)`) (https://mail.scipy.org/pipermail/numpy-discussion/2015-June/073108.html). Without going that far, support for frozen dimensions would be uncontroversial and useful (and potentially open the way for more optimizations).

user: albop
issue_1653: state: open
title: Numpy unsigned int values evaluation
body: When you use unsigned int to int conversion followed by an absolute calculation the jitted code behaves differently than the pure python code.

Example:

Input:

``` python
@njit
def test():
        if abs(int(np.uint16(1)) - int(np.uint16(2))) <= 1:
            print(1)
        else:
            print(0)
```

Output: 0

The pure python version gives as an output 1.

user: DavidLP
labels: bug - incorrect behavior: Bugs: incorrect behavior
issue_1629: state: open
title: JIT Class: Support for (Multiple) inheritance/mixins  
body: Multiple inheritance or mixins are specifically is critical for expressively creating Agent Based Models. 

Since we are departing from python semantic a fair bit with JIT classes already, what about if we did something like Scala's traits or abstract types? 

user: datnamer
issue_1606: state: open
title: Jitclass: support for __call__ etc
body: Despite https://github.com/numba/numba/pull/1571#issuecomment-165205412, would it be possible for `jitclass` to support special methods such as
1. `__call__`
2. `__getitem__`, `__setitem__`
3. `__repr__`, `__str__`
4. `__iter__`

and others?

`__call__` would be especially useful since it will allow the instance to look like a jitted function that can be passed to another jitted function as an argument. See also https://groups.google.com/a/continuum.io/forum/#!topic/numba-users/YE12tE2dIwY.

user: oyamad
issue_1549: state: open
title: Memory leak when raise exception
body: No cleanup is emitted when an exception is raised.  Any current local reference will not be released when the function returns due to error.

user: sklam
issue_1528: state: open
title: CUDA compatible unravel_index
body: Would it be possible to get a numba/CUDA python compatible version of `numpy.unravel_index`? 

I am planning to use a couple CUDA devices to work on some voxels.  My intended workflow is to flatten the voxels and then break them up across the GPUs, however I need to get the original indexes of the voxels for some of the mathematics I am doing.

user: CJ-Wright
labels: CUDA: CUDA related issue/PR
issue_1520: state: open
title: device gufunc scheduling not handling output argument properly
body: For a gufunc `foo(arg0, arg1, ret0)` with this signature "(m,n),(k)->()", and the call with `foo(a, b, out)`, there are two bugs:
- `out` is incorrectly categorized as input shapes during scheduling;
- the above issue can be workaround by using explicit `out` arg, but the scheduling is mishandling the scalar output argument when the input in a 1d-array.

Both bugs can be workaround by not specifying the output argument.

user: sklam
issue_1512: state: open
title: the result of calling cffi function with float* argurements is not correct in numba 0.22.0 
body: tested on numba 0.22.0 win64 python 64bit

``` python
import numba.cffi_support
from numba import njit
import numpy as np
from cffi import FFI
ffi=FFI()
ffi.set_source('_my','''
float add_p(float *a, float *b){
  return a[0]+b[0];
}
''')
ffi.cdef('''
float add_p(float *a, float *b);
''')
ffi.compile()

import _my
numba.cffi_support.register_module(_my)

ffi=_my.ffi
add_p=_my.lib.add_p

@njit
def f():
    a=np.ones(10,np.float32)
    b=np.ones(10,np.float32)
    #if put the definition of a and b outside of  the function, then get the correct result
    ap=ffi.from_buffer(a)
    bp=ffi.from_buffer(b)
    return add_p(ap,bp)
print f() #the result is -1.60595174128e+19, should be 2.0
```

user: cooperliu101
issue_1478: state: open
title: Wishlist: Defining a numba capable python extension 
body: From this convo, @teoliphant  had some great thoughts : https://groups.google.com/a/continuum.io/forum/#!searchin/numba-users/travis$20oliphant|sort:date/numba-users/rxoTzoOBbgI/aJSdyc9-CwAJ 

""The question:  How would I write an array-based module (like np.linalg) so that Numba _could_ optimize it automatically when it encounters it.    

In other words,  Numba needs to define and document how a third-party extension using NumPy (or DyND, or Pandas), could be written and then what information needs to be provided so that Numba would work "out-of-the-box" on it.  

Basically, a very simple extension API needs to be constructed and documented.    For example, np.linalg is basically a wrapper around BLAS.   Numba can also call BLAS directly.    If np.linalg were written in a certain way (say with type-information published in a certain way), Numba could potentially work with it "out-of-the-box".   

With this strategy, we can encourage package authors to make their code "numba-compatible".      I would start simply --- np.linalg is a good place to start.   np.fft is another place to continue.    From there scipy modules could be adapted.    The point, however is to recognize that rather than all this information being "in numba" --- it needs to be in the Python extensions themselves and we need to document what a library author should do to make their code "numba-capable" --- particularly in no-python mode.    This would likely initially only work with Python wrappers that make heavy use of cffi, or ctypes (or cython).  "

user: datnamer
issue_1417: state: open
title: Parallel ufunc target improvements
body: There were several issues identified when the parallel ufunc target was moved over to Numba:
- [ ] Some additional functions in the workqueue module should be static
- [ ] One new callback is registered for each thread launched, which sounds wasteful.
- [ ] Adding work to the task queue is not thread-safe. Whilst this appears to not be an issue in current usage, it would be desirable to make it thread-safe.
- [ ] Ufunc tests may need some reorganisation and consolidation.

user: gmarkall
issue_1395: state: open
title: fixing the "scoping" and "backbone" logic
body: I think https://github.com/numba/numba/issues/1394 is due to the way we use the "backbone" as locations where new "scope" can be created.

~~We can do better by using the CFG and find the variable version at the IDOM.~~

the problem in detail:

``` python
@njit
def foo(a):
    if a:
        for i in range(a):
             a += i
        i += 1.0
    return a
```

The `a+=i` line should not affect the typing of `range(a)`.  It only affect `return a`.  Similarly, the `i += 1.0` should not affect the typing of `a += i`. But it does because the "scoping" does not consider the dataflow.

user: sklam
issue_1390: state: open
title: Printing in nopython mode uses the Python interpreter
body: See https://github.com/numba/numba/blob/master/numba/targets/printimpl.py#L13

user: gmarkall
issue_1361: state: open
title: numba.jit memory leak
body: The following loop produces a memory leak. If nb.jit is taken out of the loop, there is no leak.

```
    for i in range(20000000):
        @nb.jit(nopython=True, nogil=True)
        def testNumba(x):
            return np.sum(x)

        a = np.ones(100)
        testNumba(a)    
```

user: nidleo
labels: llvm: LLVM related issues
issue_1335: state: open
title: Improving support for numpy.random
body: I've noticed that there are four distributions in numpy.random that are not supported by Numba yet, i.e. 

``` python
multinomial
multivariate_normal
noncentral_chisquare
noncentral_f
```

Is there any particular difficulty? 

user: xiaoweiz
issue_1317: state: open
title: Support nogil=True for ufuncs and gufuncs
body: ```
In [3]: @numba.vectorize(nogil=True)
   ...: def f(a, b):
   ...:     return a + b
   ...:

In [4]: f(1, 2)
KeyError: "Does not support option: 'nogil'"
```

This would be extremely useful for integrating numba ufuncs with dask.array.

user: shoyer
labels: good first issue: A good issue for a first time contributor
issue_1315: state: open
title: Records, nestedarrays should use NRT
body: ... to track memory reference.

We currently avoid the problem by violating the python semantic.  Copies are made to workaround any problem with reference.

user: sklam
issue_1314: state: open
title: Record array not supported by dufunc
body: ``` python
from numba import vectorize, njit
import numpy as np

rec_dtype = np.dtype([('x', np.int32)])
rec_array = np.recarray(2, dtype=rec_dtype)


@vectorize
def foo(a):
    return a.x + 1

print(foo(rec_array))
```

outputs:

```
Traceback (most recent call last):
  File "rectest.py", line 14, in <module>
    print(foo(rec_array))
TypeError: Not implemented for this type
```

Calling dufunc from njit also fail:

``` python


@njit
def bar(a):
    return foo(a)

print(bar(rec_array))
```

```
Traceback (most recent call last):
  File "/Users/sklam/dev/numba/numba/lowering.py", line 172, in lower_block
    self.lower_inst(inst)
  File "/Users/sklam/dev/numba/numba/lowering.py", line 212, in lower_inst
    val = self.lower_assign(ty, inst)
  File "/Users/sklam/dev/numba/numba/lowering.py", line 361, in lower_assign
    return self.lower_expr(ty, value)
  File "/Users/sklam/dev/numba/numba/lowering.py", line 562, in lower_expr
    return self.lower_call(resty, expr)
  File "/Users/sklam/dev/numba/numba/lowering.py", line 533, in lower_call
    res = impl(self.builder, argvals)
  File "/Users/sklam/dev/numba/numba/targets/base.py", line 1090, in __call__
    return self._imp(self._context, builder, self._sig, args)
  File "/Users/sklam/dev/numba/numba/npyufunc/dufunc.py", line 58, in __call__
    explicit_output=explicit_output)
  File "/Users/sklam/dev/numba/numba/targets/npyimpl.py", line 309, in numpy_ufunc_kernel
    val_out = kernel.generate(*vals_in)
  File "/Users/sklam/dev/numba/numba/npyufunc/dufunc.py", line 38, in generate
    self.builder, entry_point, isig.return_type, isig.args, cast_args)
  File "/Users/sklam/dev/numba/numba/targets/callconv.py", line 389, in call_function
    code = builder.call(callee, realargs)
  File "/Users/sklam/dev/.conda.workspace/llvm36/lib/python3.4/site-packages/llvmlite/ir/builder.py", line 452, in call
    cconv=cconv, tail=tail)
  File "/Users/sklam/dev/.conda.workspace/llvm36/lib/python3.4/site-packages/llvmlite/ir/instructions.py", line 74, in __init__
    raise TypeError(msg.format(1 + argno, exptype, arg.type))
TypeError: Type of #4 arg mismatch: [4 x i8]* != [4 x i8]
```

This looks a calling convention mismatch.

user: sklam
issue_1311: state: open
title: `np.bool` vs `np.bool_`
body: This might be deliberate (numba docs do only say `np.bool_` is supported), but I'm getting an error when I use `np.bool` instead of `np.bool_` (what exactly is the difference?)

I'm using Miniconda w/ Python 3.4:

``` Python
In [1]: import numba
In [2]: import numpy as np
In [3]: numba.__version__
Out[3]: '0.20.0'

In [4]: @numba.jit(nopython=True)
   ...: def f():
   ...:     np.zeros(5, dtype=np.bool)       # works fine if I use np.bool_
   ...:     
In [5]: f()
---------------------------------------------------------------------------
TypingError                               Traceback (most recent call last)
<ipython-input-4-0ec059b9bfe1> in <module>()
----> 1 f()

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    157         assert not kws
    158         sig = tuple([self.typeof_pyval(a) for a in args])
--> 159         return self.compile(sig)
    160 
    161     def inspect_llvm(self, signature=None):

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/dispatcher.py in compile(self, sig)
    320                                           self.py_func,
    321                                           args=args, return_type=return_type,
--> 322                                           flags=flags, locals=self.locals)
    323 
    324             # Check typing error if object mode is used

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library)
    592     pipeline = Pipeline(typingctx, targetctx, library,
    593                         args, return_type, flags, locals)
--> 594     return pipeline.compile_extra(func)
    595 
    596 

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in compile_extra(self, func)
    315                 raise e
    316 
--> 317         return self.compile_bytecode(bc, func_attr=self.func_attr)
    318 
    319     def compile_bytecode(self, bc, lifted=(), lifted_from=None,

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in compile_bytecode(self, bc, lifted, lifted_from, func_attr)
    324         self.lifted_from = lifted_from
    325         self.func_attr = func_attr
--> 326         return self._compile_bytecode()
    327 
    328     def compile_internal(self, bc, func_attr=DEFAULT_FUNCTION_ATTRIBUTES):

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in _compile_bytecode(self)
    579 
    580         pm.finalize()
--> 581         return pm.run(self.status)
    582 
    583 

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in run(self, status)
    207                     # No more fallback pipelines?
    208                     if is_final_pipeline:
--> 209                         raise patched_exception
    210                     # Go to next fallback pipeline
    211                     else:

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in run(self, status)
    199             for stage, stage_name in self.pipeline_stages[pipeline_name]:
    200                 try:
--> 201                     res = stage()
    202                 except _EarlyPipelineCompletion as e:
    203                     return e.result

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in stage_nopython_frontend(self)
    412                 self.args,
    413                 self.return_type,
--> 414                 self.locals)
    415 
    416         with self.fallback_context('Function "%s" has invalid return type'

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/compiler.py in type_inference_stage(typingctx, interp, args, return_type, locals)
    707 
    708     infer.build_constrain()
--> 709     infer.propagate()
    710     typemap, restype, calltypes = infer.unify()
    711 

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/typeinfer.py in propagate(self)
    397                 print("propagate".center(80, '-'))
    398             oldtoken = newtoken
--> 399             self.constrains.propagate(self.context, self.typevars)
    400             newtoken = self.get_state_token()
    401             if config.DEBUG:

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/typeinfer.py in propagate(self, context, typevars)
     96         for constrain in self.constrains:
     97             try:
---> 98                 constrain(context, typevars)
     99             except TypingError:
    100                 raise

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/typeinfer.py in __call__(self, context, typevars)
    216     def __call__(self, context, typevars):
    217         fnty = typevars[self.func].getone()
--> 218         self.resolve(context, typevars, fnty)
    219 
    220     def resolve(self, context, typevars, fnty):

/home/alan/miniconda3/envs/test/lib/python3.4/site-packages/numba/typeinfer.py in resolve(self, context, typevars, fnty)
    241             if sig is None:
    242                 msg = "Undeclared %s%s" % (fnty, args)
--> 243                 raise TypingError(msg, loc=self.loc)
    244             restypes.append(sig.return_type)
    245         typevars[self.target].add_types(*restypes)

TypingError: Failed at nopython (nopython frontend)
Undeclared Function(<built-in function zeros>)(int32, Function(<class 'bool'>))
File "<ipython-input-3-1498f51ba672>", line 3
```

user: alanhdu
issue_1278: state: open
title: NoPython Generator Finalizer is never invoked
body: The following test is marked as expectedFailure due to a refcount leak
https://github.com/sklam/numba/commit/356aded90acd67d57f3354ca34ee2cc4035ac960#diff-19d65d89b28ed73cff82a196c1c07467R427
The leak is due to nopython generator finalizer is never invoked.  The suspended states are never destroyed.

NoPython generator object needs to be tracked by NRT so that it is handled by NRT incref/decref and its destructor be called when refct==0.

user: sklam
labels: bug - memory leak: Memory leak
issue_1269: state: open
title: Support for axis arguments on reduction functions
body: Now that we support array expressions, I'm finding that I really want to be able to pass the `axis` argument to reduction functions like `np.sum()`, `np.mean()`, etc.  This raises the issue again of how to do dispatch based on argument values, but it is becoming much more critical now that I can so easily create arrays to reduce in nopython mode.

user: seibert
issue_1261: state: open
title: Add example of using multiple GPUs to CUDA documentation
body: This would show how to use the device context manager and manually move data to device memory allocations to ensure launches are asynchronous.

user: seibert
labels: CUDA: CUDA related issue/PR
issue_1243: state: open
title: Allow nopython code to raise warnings
body: NumPy uses warnings to communicate errors in computation (e.g. divide-by-zero).
Numba needs to do the same when executing jitted numpy ufuncs.

Example:

``` python
>>> def foo(a, b):
...     return np.floor_divide(a, b)
... 
>>> numba.jit(foo)(0, 0)
0
```

Since numba did not raise a warning, we appear to be doing something stupid even though we are just matching the result of numpy.

**Suggestions**

Option 1: Use a new return status code to indicate a warning has occurred.  This may allow us to have just one warning

Option 2: Let each target decide how warnings are reported by invoking an external function that is resolved by the target at load time.  1) When used in python, just delegate to libpython API. 2) When used in pycc, NRT may provide an implementation (e.g. print to stderr).  3) In CUDA-Python, just print?

user: sklam
issue_1222: state: open
title: 'DUFunc' object has no attribute '__name__'
body: It would be nice to have the usual function metadata reflected on DUFunc (`__name__`, `__qualname__`, `__doc__`... anything else?).

user: pitrou
issue_1194: state: open
title: Support for generator delegation with `yield from`
body: Somewhat related to #984, we do not support generator delegation (a Python 3.3 feature) using `yield from`.  Now that we have support for generators in object and nopython mode, this seems like a nice thing to have.

user: seibert
issue_1175: state: open
title: Cudasim should have an option to buffer output then print it ordered by thread ID after kernel execution
body: Although printing output as it is produced is helpful for understanding races, it makes it difficult to examine the output if you're printing things out to determine what is going on in individual threads. This feature would make this use case easier by printing all of thread 0's output first, then thread 1's, and so on.

user: gmarkall
labels: CUDA: CUDA related issue/PR
issue_1160: state: open
title: DUFuncs are immortal
body: DUFunc._install_type() and DUFunc._install_cg() make a DUFunc immortal (i.e. even if the original object goes out of scope, some references to it still survive in the typing and target contexts). There's no obvious way to fix it right now, but at least we can record it as an issue here.

user: pitrou
labels: bug - memory leak: Memory leak
issue_1087: state: open
title: @jit ignores signature for return type
body: ``` python
import numpy as np
from numba import jit

@jit("float32(float32)", nopython=True)
def f(x):
    return x
```

The return value was definitely truncated to 32 bits internally at some point, but it's always a Python float, not `np.float32`:

```
In [22]: f(3.2)
Out[22]: 3.200000047683716

In [23]: type(f(3.2))
Out[23]: float

In [24]: type(f(np.float32(3.2)))
Out[24]: float
```

user: shoyer
issue_1055: state: open
title: CUDA doesn't warn the error if their launch configuration exceeds the capability of their device
body: The launch configuration is not checked and the CUDA target proceeds with attempting to call `cuLaunchKernel`. This results in the user being presented with the generic error:

```
numba.cuda.cudadrv.driver.CudaAPIError: Call to cuLaunchKernel results in CUDA_ERROR_INVALID_VALUE
```

It would be a bit more user- and beginner-friendly to check the launch configuration and point out the limits if they are exceeded.

E.g. mailing list thread: https://groups.google.com/a/continuum.io/forum/?utm_medium=email&utm_source=footer#!msg/numba-users/TkW3Bdjq_Yw/Qv5xq3e6r_sJ

user: gmarkall
labels: CUDA: CUDA related issue/PR
good first issue: A good issue for a first time contributor
issue_917: state: open
title: vectorize fails on datetime
body: There are a couple issues here:

When I construct a function with `vectorize`, seemingly equivalent ways to construct the signature yield different errors:

First try:

``` python
import numpy as nb
import numpy as np

@nb.vectorize(nb.types.NPDatetime('us')(nb.int64))
def convert_it(x):
    return np.datetime64(x)
```

gives: `TypeError: 'NotImplementedType' object is not callable`

Second try:

``` python
import numba as nb
import numpy as np

@nb.vectorize('NPDatetime("us")(int64)')
def convert_it(x):
    return np.datetime64(x)
```

gives: `TypeError: Invalid datetime metadata string "(us)" at position 1`.

In the latter case, the signature name `'datetime64(ns)` is being passed to `np.dtype` here: https://github.com/numba/numba/blob/master/numba/npyufunc/ufuncbuilder.py#L158 which fails because it should be `datetime64[ns]`. However after adding that change, numba crashes the interpreter:

``` diff
diff --git a/numba/types.py b/numba/types.py
index d4b7438..284a35a 100644
--- a/numba/types.py
+++ b/numba/types.py
@@ -212,7 +212,7 @@ class _NPDatetimeBase(Type):
     """

     def __init__(self, unit, *args, **kws):
-        name = '%s(%s)' % (self.type_name, unit)
+        name = '%s[%s]' % (self.type_name, unit)
         self.unit = unit
         self.unit_code = npdatetime.DATETIME_UNITS[self.unit]
         super(_NPDatetimeBase, self).__init__(name, *args, **kws)
```

``` python
In [3]: @nb.vectorize('NPDatetime("us")(int64)')
def convert_it(x):
    return np.datetime64(x)
   ...:

In [4]: convert_it(np.datetime64('now').view('int64'))
/Users/pcloud/miniconda/envs/py27/bin/python.app: line 3: 22194 Segmentation fault: 11
```

user: cpcloud
labels: Blocked awaiting long term feature: For PRs/Issues that require the implementation of a long term plan feature
issue_888: state: open
title: Make it easier to write single precision code
body: If you write the following code:

```
@vectorize(['float32(float32, float32)'])
def rel_diff(x, y):
    return 2 * (x - y) / (x + y)
```

it will be more than twice slower than the following:

```
two = np.float32(2)

@vectorize(['float32(float32, float32)'])
def rel_diff(x, y):
    return two * (x - y) / (x + y)
```

This is because the result of `2 * (x - y)` in the first snippet will be typed as double precision by Numba, leading to many spurious conversions in the critical path. Such constructions are often the most natural way to write numerical code.

user: pitrou
issue_838: state: open
title: Describe additional Numba types in documentation
body: The current documentation of Numba types is missing some types that are defined numba.types, and needs to be updated.

user: seibert
issue_727: state: open
title: Add function dependency/callgraph to Overloaded
body: Each Overloaded object needs to keep a reference to the depending functions.  We currently satisfy this because the IR keeps a reference to each referenced global value.  But, it will be useful to have an explicit dependency graph for other purposes, like recursion support.

user: sklam
issue_576: state: open
title: Performance enhancement for iternext in object mode
body: PR https://github.com/numba/numba/pull/572 added an extra tuple in iternext.  This increases the runtime in for-loops. 

user: sklam
issue_538: state: open
title: unary negative nonsensical in the unsigned domain
body: ```
>>> def f(x): return -x
... 
>>> jit('uintp(uintp)', nopython=True)(f)(-5)
1
>>> jit('uintp(uintp)', nopython=True)(f)(5)
OverflowError: can't convert negative int to unsigned
```

user: pitrou
issue_505: state: open
title: Generator comprehensions unsupported
body: ```
>>> @jit
... def f():
...     for i in (x * 2 for x in range(5)):
...         return i
...
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "numba\dispatcher.py", line 125, in _compile_and_call
    self.jit(sig)
  File "numba\dispatcher.py", line 120, in jit
    return self.compile(sig, **kws)
  File "numba\dispatcher.py", line 108, in compile
    flags=flags, locals=locs)
  File "numba\compiler.py", line 90, in compile_extra
    bc = bytecode.ByteCode(func=func)
  File "numba\bytecode.py", line 296, in __init__
    table = utils.SortedMap(ByteCodeIter(code))
  File "numba\utils.py", line 46, in __init__
    for i, (k, v) in enumerate(sorted(seq)):
  File "numba\bytecode.py", line 216, in next
    raise NotImplementedError(ts % tv)
NotImplementedError: offset=6 opcode=84 opname=MAKE_FUNCTION
```

user: pitrou
issue_230: state: open
title: handle overlapping memory regions when slicing correctly
body: We don't currently support slices on overlapping memory regions.  This would be nice to have :)

``` python
def overlapping_copy(a):
   a[1:] = a[0:-1]
```

user: ahmadia
labels: bug - incorrect behavior: Bugs: incorrect behavior