Skip to content

Few LLVM lint "Unusual" #48229

@leonardo-m

Description

@leonardo-m

In Issue #48227 I've seen code compiled with "-C passes=lint", I've used it on some of my code and I've found few problems, reduced below:


fn foo(_: &u32, _: &u32) {}
fn main() {
    let a = 0;
    foo(&a, &a);
}


...>rustc -C passes=lint test1.rs
Unusual: noalias argument aliases another argument
  call void @_ZN4bug13foo17h2a852a9d6b40f8a0E(i32* noalias readonly dereferenceable(4) %1, i32* noalias readonly dereferenceable(4) %1)

fn main() {
    (1 .. 9).take_while(|i| i * i <= 10).any(|_| true);
}


...>rustc -C passes=lint test2.rs
Unusual: noalias argument aliases another argument
  %3 = call i32 @"_ZN86_$LT$$RF$$u27$b$u20$i32$u20$as$u20$core..ops..arith..Mul$LT$$RF$$u27$a$u20$i32$GT$$GT$3mul17hdb3638dfdb52b819E"(i32* noalias readonly dereferenceab
le(4) %1, i32* noalias readonly dereferenceable(4) %1)

fn main() {
    (1 .. 9).filter(|_| true).sum::<u32>();
}


...>rustc -C passes=lint test3.rs
Unusual: Return statement in function with noreturn attribute
  ret void


Activity

leonardo-m

leonardo-m commented on Feb 15, 2018

@leonardo-m
Author
rustc 1.25.0-nightly (3ec5a99aa 2018-02-14)
binary: rustc
commit-hash: 3ec5a99aaa0084d97a9e845b34fdf03d1462c475
commit-date: 2018-02-14
host: x86_64-pc-windows-gnu
release: 1.25.0-nightly
LLVM version: 6.0
added
A-codegenArea: Code generation
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness
C-bugCategory: This is a bug.
on Feb 15, 2018
nagisa

nagisa commented on Feb 16, 2018

@nagisa
Member

Duplicate of #7463

nagisa

nagisa commented on Feb 16, 2018

@nagisa
Member

I guess I’ll reopen, since this contains minimal and actionable code samples.

reopened this on Feb 16, 2018
RalfJung

RalfJung commented on Mar 28, 2018

@RalfJung
Member

This seems like the LLVM lint disagrees with the statement somewhere in the compiler sources saying that noalias on read-only data is fine even if thins alias -- because we can still reorder them?

hanna-kruppe

hanna-kruppe commented on Mar 28, 2018

@hanna-kruppe
Contributor

Doesn't noalias also factor into optimizing pointer comparisons?

RalfJung

RalfJung commented on Mar 28, 2018

@RalfJung
Member

Well, whoever wrote that code strongly things that is not the case...

Also, depending on what exactly clang does, that would be unsound:

int foo(restrict int *x, restrict int *y) {
  (x == y) ? 1 : 0
}

This can not be optimized to return 0.

hanna-kruppe

hanna-kruppe commented on Mar 28, 2018

@hanna-kruppe
Contributor

Hm, you're right, and indeed I couldn't find any such optimization in a quick skim of instcombine.

14 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationC-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @cuviper@kennytm@RalfJung@nagisa@jonas-schievink

        Issue actions

          Few LLVM lint "Unusual" · Issue #48229 · rust-lang/rust