Get to LLVM-lint-clean #7463

graydon · 2013-06-28T21:13:12Z

Not sure what all is involved, but I gather when we turn on LLVM's internal lint checking, all hell breaks loose. Let's tidy this up.

Blei · 2013-06-29T07:27:05Z

I would say over 90% (not measured) of lint errors are because of bitcasting function pointers, like the ones mentioned in #6779. I have a patch that removes most of them, but is somewhat hacky and not complete yet. But most importantly, it makes the code bigger and doesn't seem to help time-wise either. According to the LLVM IRC channel, those lint errors are false positives.

msullivan · 2013-08-23T00:33:07Z

Nothing new to add.

thestinger · 2013-08-23T22:30:29Z

A big cause of this is #8720.

thestinger · 2013-08-23T23:57:40Z

I think most of the rest are caused by type_use (similar to the #8720 issue). Replacing it would mergefunc would be the laziest way of fixing them.

brson · 2013-09-18T22:40:58Z

Not 0.8

thestinger · 2013-11-03T10:04:31Z

The only remaining lint appears to be many cases of Pessimization: Static alloca outside of entry block.

steveklabnik · 2015-01-20T20:32:09Z

Triage: I pinged @Aatch about this on IRC, but I am bad at our build system, and so I have nothing specific to add.

tamird · 2015-05-29T13:40:08Z

@steveklabnik rustc -C passes=lint turns this on.

steveklabnik · 2017-01-03T18:15:47Z

Triage: to try this today, do

RUSTFLAGS="-C passes=lint" python x.py build

We are very much not close to clean, though it seems like many of these are similar issues, so it's possible that a fix would fix many of them.

nagisa · 2017-01-03T23:53:52Z

We have 2 broad kinds of warnings coming up while translating rustc:

Undefined behavior: Memory reference address is misaligned
  store i32 %1, i32* %3, !dbg !2710

and

Unusual: noalias argument aliases another argument
  %4 = call zeroext i1 @core::cmp::PartialEq::gt(i8* noalias readonly dereferenceable(1) %1, i8* noalias readonly dereferenceable(1) %3), !dbg !679

The first is very scary, not sure about 2nd.

matthiaskrgr · 2018-01-27T08:01:35Z

cargo 0.26.0-nightly (91e36aa86 2018-01-25)
rustc 1.25.0-nightly (bacb5c58d 2018-01-26)

I was giving RUSTFLAGS="-C passes=lint" python x.py build a try and these are the kinds that I got:

Unusual: noalias argument aliases another argument
  %3 = call zeroext i1 @_ZN4core3cmp10PartialOrd2gt17h599e81f888a1fe30E(i8* noalias readonly dereferenceable(1) %0, i8* noalias readonly dereferenceable(1) %2)

Undefined behavior: Buffer overflow
  %3 = load i64, i64* %2, align 1, !range !0

Unusual: Return statement in function with noreturn attribute
  ret void

While doing a debug crater build, ( RUSTFLAGS="-C passes=lint" cargo build in crater repo) this showed up:

Unusual: unreachable immediately preceded by instruction without side effects
  unreachable, !dbg !69

steveklabnik · 2019-03-11T20:46:46Z

Still getting a bunch of

Unusual: Return statement in function with noreturn attribute=>        ] 19/22: alloc
  ret void
   Compiling panic_unwind v0.0.0 (C:\Users\steve\src\rust\src\libpanic_unwind)
Unusual: Return statement in function with noreturn attribute======>   ] 21/22: std
  ret void

@eddyb

Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now mark such return values with a new `IgnoreMode::Uninhabited`, and emit an `abort` anywhere that would have returned. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb

@eddyb

Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now mark such return values with a new `IgnoreMode::Uninhabited`, and emit an `abort` anywhere that would have returned. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb

cuviper · 2019-04-04T00:00:52Z

Unusual: Return statement in function with noreturn attribute

These should be cleaned up by #59639.

Unusual: noalias argument aliases another argument

I believe these are a false positive by the lint -- it should be fine for noalias arguments to point to the same memory when they're both readonly, as there's no possible memory dependence. I've opened LLVM D60239 to try to recognize that.

@eddyb

Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb

@eddyb

Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb

@eddyb

Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb

@eddyb

Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb

@eddyb

Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb

Mark-Simulacrum · 2019-09-18T00:59:05Z

Running a full x.py build I can't seem to get any warnings today so I'm going to presume we've fixed this (or LLVM has moved on and doesn't emit as many lints as previously); either way, closing until we get a reliable reproduction.

Fix `any()` not taking reference in `search_is_some` lint `find` gives reference to the item, but `any` does not, so suggestion is broken in some specific cases. Fixes: rust-lang#7392 changelog: [`search_is_some`] Fix suggestion for `any()` not taking item by reference

Aatch mentioned this issue Jun 28, 2013

Improve LLVM IR Code generation #6819

Closed

sanxiyn added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 25, 2015

sanxiyn mentioned this issue Oct 8, 2015

LLVM lint: Memory reference address is misaligned #28912

Closed

kennytm added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 27, 2018

This was referenced Feb 15, 2018

llvm lint: "Return statement in function with noreturn attribute" caused by .count() ? #48227

Closed

llvm lint: "unreachable immediately preceded by instruction without side effects" #48228

Open

nagisa mentioned this issue Feb 16, 2018

Few LLVM lint "Unusual" #48229

Closed

matthiaskrgr mentioned this issue Feb 17, 2018

llvm lint: "Undefined behavior: Call argument type mismatches callee parameter type" with mixing debug and release #48310

Closed

matthiaskrgr mentioned this issue Nov 27, 2018

llvm lint: Undefined behavior: Memory reference address is misaligned #56267

Closed

cuviper mentioned this issue Apr 2, 2019

Never return uninhabited values at all #59639

Merged

This was referenced Apr 26, 2019

llvm lint: "Unusual: Address one pointer dereference" on unsafe code #60320

Closed

llvm lint: Unusual: "Load from function body" on unsafe code #60321

Closed

llvm lint: Pessimization: Static alloca outside of entry block / UB #60322

Closed

Mark-Simulacrum closed this as completed Sep 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Get to LLVM-lint-clean #7463

Get to LLVM-lint-clean #7463

graydon commented Jun 28, 2013

Blei commented Jun 29, 2013

msullivan commented Aug 23, 2013

thestinger commented Aug 23, 2013

thestinger commented Aug 23, 2013

brson commented Sep 18, 2013

thestinger commented Nov 3, 2013

steveklabnik commented Jan 20, 2015

tamird commented May 29, 2015

steveklabnik commented Jan 3, 2017 •

edited

Loading

nagisa commented Jan 3, 2017

matthiaskrgr commented Jan 27, 2018

steveklabnik commented Mar 11, 2019

cuviper commented Apr 4, 2019

Mark-Simulacrum commented Sep 18, 2019

Get to LLVM-lint-clean #7463

Get to LLVM-lint-clean #7463

Comments

graydon commented Jun 28, 2013

Blei commented Jun 29, 2013

msullivan commented Aug 23, 2013

thestinger commented Aug 23, 2013

thestinger commented Aug 23, 2013

brson commented Sep 18, 2013

thestinger commented Nov 3, 2013

steveklabnik commented Jan 20, 2015

tamird commented May 29, 2015

steveklabnik commented Jan 3, 2017 • edited Loading

nagisa commented Jan 3, 2017

matthiaskrgr commented Jan 27, 2018

steveklabnik commented Mar 11, 2019

cuviper commented Apr 4, 2019

Mark-Simulacrum commented Sep 18, 2019

steveklabnik commented Jan 3, 2017 •

edited

Loading