Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLVM 9.0

lists.llvm.org

Post reply on HN
Print view View original

91–100 of 111 posts

Re: LLVM 9.0

#91

Post by pjmlp »

ndesaulniers wrote: post #87
pjmlp wrote: post #85

Earlier quoted context omitted.

As mentioned already a couple of times with online discussions with Dan and AMA on Reddit, from me and others: An NDK version of Android JetPack/AndroidX, for starters proper C++ API, instead of forcing everyone to code 90's style, each re-creating their own C++ wrappers for the Android C++ APIs exposed as C function calls. Which by the way, given the whole security theme on Android, means more insecure code than if…

Thanks for the feedback, we will look into it. :P I'm happy to pass these along to Dan and your comment is easy for me to link to, but I don't know why you're suggesting Google move LLVM compiler engineers to work on NDK, which is more of a userspace C++ framework for third party applications to interface with the Android platform. Kind of feels orthogonal to this thread which is about the llvm 9.0 release. > fix the…

I am suggesting that, because as I mentioned it looks understaffed from the outside, either that or there isn't that much willingness to spend resources on improving it beyond "good enough".

Given that you mentioned, that there were actually so many LLVM engineers around, I thought they could give them an hand. :)

Regarding the clang regressations:

https://github.com/android/ndk/issues/742

https://github.com/android/ndk/issues/721

There are way less than I remembered though, sorry for the confusion.

Re: LLVM 9.0

#92

Post by leni536 »

DerekL wrote: post #48
d33 wrote: post #35

Earlier quoted context omitted.

I guess the question is: will it silently optimize them away or will it be a compile error to use such expressions?

It can't be a compile error. It's not an error for a program to contain such code, it's only an error if that code executes.

That's not strictly true. Undefined behavior includes unsuccessful compilation as well [0]. But for this the compiler has to prove that the offending code is executed every time the program is executed. I think compilers don't bother with this though.

[0] https://eel.is/c++draft/intro.defs#defns.undefined-sentence-...

Re: LLVM 9.0

#93

Post by caspervonb »

sanxiyn wrote: post #67
favorited wrote: post #16

Earlier quoted context omitted.

LLVM changed their versioning scheme a few releases back (maybe around 3.9 -> 4.0 IIRC?), so major version increases will be more common now. I think it used to be roughly tied to bitcode compatibility? Someone who works on LLVM can give a more specific answer, but the gist of it is we'll see more major version increments now.

http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... explains the exact change.

Ahh thanks!

Re: LLVM 9.0

#94

Post by wiz21c »

morning_gelato wrote: post #4

>Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang This is great for Linux, no longer being dependent on a single compiler for one of the most popular ISAs can only be a good thing for the overall health of the project. To be clear, I have nothing against gcc.

2 cents prediction :

Android will leave linux (fuschia), linux will leave gcc because companies developing the kernel will push for clang, clang will have media coverage, gcc will therefore loose a huge user base and the power of the FSF will go south.

(as a free software zealot ( :-) ), I'm worried)

Re: LLVM 9.0

#96

Post by BurningCycles »

ndesaulniers wrote: post #72
BurningCycles wrote: post #57

Earlier quoted context omitted.

Yes, there are still some stability issues though. Phoronix benchmarked the Linux kernel built with Clang/LLVM against GCC recently: https://www.phoronix.com/scan.php?page=article&item=clang-li...

Android and CrOS have not had stability issues related to the compiler since switching to Clang. And Phoronix didn't send me any reports; I reached out to Michael and he said he'll send them to me next time he tries.

I was referring to the problems in said benchmark test on Phoronix, where Michael stated:

'The main culprits were Blender and GeekBench 5 causing the Clang-built kernel to cause the system to reset during testing while this behavior wasn't seen when the kernel was built under GCC, so likely some problematic code generation on the Clang side.'

Re: LLVM 9.0

#97

Post by hwj »

brynet wrote: post #26

Note that this release (9.x) marks the first to be no longer available under the original permissive NCSA (BSD-like) LLVM license, going forward the LLVM project has moved to an "Apache 2.0 with LLVM Exceptions" for everything. And not just the compiler itself, but also sub-projects like the supporting libc++/libc++abi standard libraries. This change only happened due to corporate pressure, and was done without consi…

What does that mean for compilers that use LLVM underneath? (I'm not a lawyer).

Re: LLVM 9.0

#98

Post by d33 »

rurban wrote: post #58
cryptonector wrote: post #18

> LLVM will now remove stores to constant memory (since this is a contradiction) under the assumption the code in question must be dead. This has proven to be problematic for some C/C++ code bases which expect to be able to cast away ‘const’. This is (and has always been) undefined behavior, but up until now had not been actively utilized for optimization purposes in this exact way. For more information, please see:…

Optimizing away even more calls of memset, memcpy or memmove is the completely wrong way. gcc went down this bug and called it "optimization", now llvm did the same. Can we at least keep at least one sane working compiler? At least emit a prominent warning when "optimizing" away lib calls. This helps only artificial benchmarks and will hurt everybody. If an assignment to const memory is illegal, treat it as error, an…

I believe rurban might have some point - for example, consider this CCC talk:

https://www.youtube.com/watch?v=0WzjAKABSDk

The point is that memset is often critical for security and compilers don't always do a good job of optimizing it out. If they strike a false positive, information leak vulnerabilities are very likely. It's also pretty difficult to detect those failures without recompiling entire program with a modified compiler, as shown in the talk.

Re: LLVM 9.0

#99

Post by Someone »

tedunangst wrote: post #52
saagarjha wrote: post #50

Earlier quoted context omitted.

The compiler will surely use a (most likely intrinsic) function with appropriate semantics in that case.

The release notes go on to say that you may need to provide your own implementation of bcmp, which does not sound very intrinsic.

You may if you’re building freestanding code (code that doesn’t use the standard library), but do not specify that you are. I think that’s reasonable.

I do wonder why this is a LLVM feature, though, and not a clang one. The system should only make this change if it came from a C(++) compiler and the source included the system header ( or ) to get memcmp.

How can LLVM know that the symbol memcmp it sees came from that header, and not from user C code that may do something different, or even from, say, a Cobol compiler?

Re: LLVM 9.0

#100

Post by simcop2387 »

brynet wrote: post #42
simcop2387 wrote: post #38

Earlier quoted context omitted.

It wouldn't cover anything from OpenBSD, if as excerpted by you, it only covers exceptions related to GPLv2 as I don't believe OpenBSD considers GPLv2 to be acceptable either.

> I don't believe OpenBSD considers GPLv2 to be acceptable either. The GPLv3 is not acceptable in base at all, GPLv2 is unacceptable for new code, but we still have a few examples in base, very few.

Ah that'd probably be why I was thinking it was any code, small difference that's easy to forget about.
Post reply on HN