Have you had a chance to look at it yet?

I was wrong, if all inputs are BC and we have foo = 1 script then I do not see it in output and link succeeds.
I'll take a look closer on this case.

In D37014#850064, @tbourvon wrote:

In D37014#849157, @lebedev.ri wrote:

Please add the following test: (and make sure that it does the right thing :))

bool f_with_preproc_condition() {
  auto test = 42;
  assert(test == 42);
  return test;
}

I.e. if -DNDEBUG is present, variable is not needed, but if -DNDEBUG is *NOT* present...

Shouldn't we ignore these cases whether or not -DNDEBUG is present?

That's *exactly* what i was talking about.

Addressed @Meinersbur's comments.

• remove duplicated release note

In D37059#850075, @davide wrote:

What happens if foo is specified in the linker script but actually doesn't appear in any bitcode file?
IIRC we should error in that case.

Given that this is regression from 3.9 and it's release-critical, I'd would suggest to commit it now. After all, the patch was in review for more than a week.

What happens if foo is specified in the linker script but actually doesn't appear in any bitcode file?
IIRC we should error in that case.

ping

In D37014#849157, @lebedev.ri wrote:

Please add the following test: (and make sure that it does the right thing :))

bool f_with_preproc_condition() {
  auto test = 42;
  assert(test == 42);
  return test;
}

I.e. if -DNDEBUG is present, variable is not needed, but if -DNDEBUG is *NOT* present...

Updated according to comments
Added test.

Looks phab ate my first reply. Duplicating again for history:

In D37059#850053, @davide wrote:

Out of curiosity, where did you hit this?

In D33574#850019, @hfinkel wrote:

I think that the test here is: is this something that a user could hit, (including with inline assembly, etc.), or does this indicate an internal problem only? For internal errors, we have lots of checks that we optimize out for release builds (and there's always the option of building release+asserts, and I deploy those builds on more experimental platforms as a general rule). If it is something that a user could hit, then it should be an error that the user will always get.

Out of curiosity, where did you hit this?
Is there any way to test that the assignment updates the value of foo to be 1 ?

Uploaded the wrong diff, here's the right one

Add tests

formatting

Don't check address space when looking up global values by name

In D33574#849770, @asb wrote:

Hi folks, I think llvm_unreachable is really the wrong error handling strategy here. It _won't_ necessarily cause the process to exit on a release build. This is actually one of the cases where it is possible to report a nice error without too much hassle. In rL299529 I added an MCContext parameter to MCAsmBackend::applyFixup in order to make it easy to use MCContext::reportError for effort reporting in helper functions like adjustFixupValue. Due to later upstream changes, you now get hold of your MCContext via the MCAssembler argument. You can see an example of this approach in action in D23568.

• [Test] upadte tests to refect state of exp, powi in PPCGCodeGen

• test case fixed expected warning
• address review comments from aaron