Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add test for inlinealways function attribute #426

Merged
merged 4 commits into from
Jul 22, 2023

Conversation

folkertdev
Copy link
Contributor

Description

Improve test for attributes on functions. Attributes on the Function location were not tested at all. The alignstack attribute was applied to the return type, but this attribute is not actually valid in that position. A verify() on the module called this issue out.

Checklist

Comment on lines +157 to +161
// private function to make code elsewhere easier
#[llvm_versions(4.0..12.0)]
fn is_type(self) -> bool {
false
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this feels a bit cheaty, but it's the simplest way I saw to keep code duplication to a minimum. Suggestions are welcome.

Comment on lines -87 to -88
let alignstack_attribute = Attribute::get_named_enum_kind_id("alignstack");
let enum_attribute = context.create_enum_attribute(alignstack_attribute, 1);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

alignstack is not a valid attibute on a function return type. At least for llvm 15, any value beside 0 (1 on line 88 here) leads to issues. The attribute is still applied when that value is 0. I think the value is only useful for some attributes (e.g. dereferencable(n), where n is the enum value).

to apply the noalias attribute instead, the function return type must be a pointer type.

pub struct Attribute {
pub(crate) attribute: LLVMAttributeRef,
}

impl std::fmt::Debug for Attribute {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used the Debug and PartialEq instance during debugging. I can remove them again, but then when something fails you only see an address, which is not helpful at all.

@folkertdev
Copy link
Contributor Author

is CI supposed to work for LLVM 16? it seems to fail before it even tries to build/run tests, like LLVM 16 is just not installed on the CI machine.

@TheDan64
Copy link
Owner

Yes, 16 was working before. Not sure what changed

@folkertdev
Copy link
Contributor Author

well I'm not sure what changed then. The branch is rebased on current TheDan64:master so it should be using whatever master is using.

@TheDan64
Copy link
Owner

@FawazTirmizi do you think you'd be able to look into LLVM16 suddenly failing in CI?

@folkertdev
Copy link
Contributor Author

gently bumping this

@TheDan64
Copy link
Owner

Hi, sorry for the delay. The llvm16 build will have to get fixed before this can be merged

@folkertdev
Copy link
Contributor Author

yes. Anything I can help with for that? the failure seems kind of random. Maybe we should just retry it?

@TheDan64
Copy link
Owner

Yeah, I'll rerun it but I'm not confident it'll fix it

@TheDan64
Copy link
Owner

Been looking into this but it's not really clear why it fails for the latest version but not the others..

@TheDan64
Copy link
Owner

Been wondering if llvm-sys changed something in 160

@folkertdev
Copy link
Contributor Author

I added a call to llvm-config to the CI script, and it prints

Run llvm-config --version --bindir --libdir
llvm-config: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by llvm-config)
llvm-config: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by llvm-config)
llvm-config: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by llvm-config)
llvm-config: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by llvm-config)

that makes sense actually, the LLVM install action installs clang+llvm-16.0.4-x86_64-linux-gnu-ubuntu-22.04.tar.xz. So I think the VM that we run this on uses a version of ubuntu that is too old for the LLVM build that is used.

@folkertdev
Copy link
Contributor Author

and it just looks like for llvm 16.04 ubuntu 22.04 is the only one for which a pre-built tar exists. For earlier point releases it was ubuntu 20.04 still.

I'm not sure what the best approach is here. I suspect we can configure this in github CI using something like this maybe

+        # only use ubuntu-22.04 for llvm 16 and higher
+        include:
+          - os: ubuntu-22.04
+            llvm-version: ["16.0", "16-0"]
+        exclude:
+          - os: ubuntu-20.04
+            llvm-version: ["16.0", "16-0"]

not pretty, but might do the trick. I have no idea if this is just a fluke or if llvm (in a point release ?!) decided do bump its minimum supported ubuntu version?

an alternative is to force an earlier version of llvm. 16.01 is the latest one that has a 20.04 build

@TheDan64
Copy link
Owner

ugh, that's really annoying if they bumped the ubuntu version in a point release of all times

@folkertdev
Copy link
Contributor Author

for point releases, the builds they provide are really spotty. The later point releases have no binaries for ubuntu at all...

so what is the best option here

  1. use 22.04 for llvm 16 only (I assume we want to keep testing with an older OS where possible)
  2. pin the llvm 16 version to 16.0.1, so ubuntu 20.04 can be used for everyone

@TheDan64
Copy link
Owner

If all the older versions work on u22 then we should just update to that. I'm assuming that isn't the case, so we probably want to make newer versions start using u22 but keep the older ones on u20

@folkertdev
Copy link
Contributor Author

allright, got it to work. Turns out there is a way to do this sort of thing compactly

@TheDan64
Copy link
Owner

Oh wow, thank you for looking into it!

Copy link
Owner

@TheDan64 TheDan64 left a comment

Choose a reason for hiding this comment

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

Thank you!

@TheDan64 TheDan64 merged commit eb3ca22 into TheDan64:master Jul 22, 2023
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants