Page MenuHomePhabricator

void (Bill Wendling)
Mind Taker

Projects

User does not belong to any projects.

User Details

User Since
Dec 3 2012, 10:22 AM (332 w, 4 d)

Sent here from the planet Zvddw, Bill's mission is to conquer the world by staying at home and occasionally (read: always) playing poker.

In his spare time, he works on LLVM-related things.

Recent Activity

Mon, Apr 15

void added a comment to D56571: [RFC prototype] Implementation of asm-goto support in clang.

I think things don't work right unless you disable the integrated assembler. I'm not sure why though.

Mon, Apr 15, 5:23 PM
void added a comment to D56571: [RFC prototype] Implementation of asm-goto support in clang.
; ModuleID = 'arch_static_branch.bc'
source_filename = "arch/x86/entry/vsyscall/vsyscall_64.c"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-grtev4-linux-gnu"
Mon, Apr 15, 12:18 PM

Sat, Apr 13

void committed rG191f1487b63b: [X86] Use PC-relative mode for the kernel code model (authored by void).
[X86] Use PC-relative mode for the kernel code model
Sat, Apr 13, 2:43 PM
void committed rL358343: [X86] Use PC-relative mode for the kernel code model.
[X86] Use PC-relative mode for the kernel code model
Sat, Apr 13, 2:42 PM
void closed D60643: [X86] Use PC-relative mode for the kernel code model.
Sat, Apr 13, 2:42 PM · Restricted Project
void added inline comments to D60643: [X86] Use PC-relative mode for the kernel code model.
Sat, Apr 13, 2:02 AM · Restricted Project

Fri, Apr 12

void created D60643: [X86] Use PC-relative mode for the kernel code model.
Fri, Apr 12, 6:18 PM · Restricted Project

Mar 1 2019

void added a comment to D58821: Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890).

My opinion doesn't carry as much weight as others who are more familiar with the front-end code, but LGTM.

Mar 1 2019, 11:25 AM · Restricted Project

Feb 26 2019

void committed rG01706bda5b60: Output ELF files after ThinLTO is run. (authored by void).
Output ELF files after ThinLTO is run.
Feb 26 2019, 11:31 AM
void committed rL354917: Output ELF files after ThinLTO is run..
Output ELF files after ThinLTO is run.
Feb 26 2019, 11:31 AM
void committed rLLD354917: Output ELF files after ThinLTO is run..
Output ELF files after ThinLTO is run.
Feb 26 2019, 11:31 AM
void closed D56046: Output ELF files after ThinLTO is run..
Feb 26 2019, 11:31 AM · Restricted Project
void updated the diff for D56046: Output ELF files after ThinLTO is run..

Move checks over to the main LL file, not Input file.

Feb 26 2019, 11:31 AM · Restricted Project

Feb 24 2019

void added a comment to D56046: Output ELF files after ThinLTO is run..

@pcc: Ping? :)

Feb 24 2019, 8:39 PM · Restricted Project

Feb 20 2019

void added a comment to D56046: Output ELF files after ThinLTO is run..

Another ping. Anyone? :-)

Feb 20 2019, 2:27 PM · Restricted Project

Feb 14 2019

void added a comment to D56046: Output ELF files after ThinLTO is run..

Friendly ping. :-)

Feb 14 2019, 12:56 PM · Restricted Project

Feb 13 2019

void added a comment to D56508: [llvm-ar] Flatten thin archives..

That should be fixed by D57842, which I'm planning to submit soon -- I want to poke a few more test cases first.

Feb 13 2019, 2:25 PM · Restricted Project
Herald added a project to D56508: [llvm-ar] Flatten thin archives.: Restricted Project.

This fails if the archives are nested. E.g.:

Feb 13 2019, 2:11 PM · Restricted Project

Feb 11 2019

Herald added a project to D56046: Output ELF files after ThinLTO is run.: Restricted Project.

Ping? :-)

Feb 11 2019, 12:42 PM · Restricted Project

Feb 8 2019

void added a comment to D57267: [AST] Factor out the logic of the various Expr::Ignore*.

@void @rnk Perhaps you can comment on this: currently Expr::IgnoreImpCasts skips FullExprs, but Expr::IgnoreParenImpCasts only skips (via IgnoreParens) ConstantExprs. Is there any reason for this inconsistency ? I would like to add FullExpr to the nodes skipped by IgnoreParenImpCasts for consistency but I am worried about unexpected issues even though all tests pass.

Feb 8 2019, 12:25 PM · Restricted Project, Restricted Project

Jan 29 2019

void accepted D57427: [CodeGen][ObjC] Fix assert on calling `__builtin_constant_p` with ObjC objects..

LGTM, but may want to wait for other reviewers.

Jan 29 2019, 5:22 PM · Restricted Project

Jan 26 2019

void committed rL352307: Remove Expr sugar decorating the CXXUuidofExpr node..
Remove Expr sugar decorating the CXXUuidofExpr node.
Jan 26 2019, 11:25 PM
void committed rC352307: Remove Expr sugar decorating the CXXUuidofExpr node..
Remove Expr sugar decorating the CXXUuidofExpr node.
Jan 26 2019, 11:24 PM
void closed D57114: Remove Expr sugar decorating the CXXUuidofExpr node..
Jan 26 2019, 11:24 PM

Jan 23 2019

void updated the diff for D57114: Remove Expr sugar decorating the CXXUuidofExpr node..

Move test to proper place and add "-verify" flag.

Jan 23 2019, 2:33 PM
void added inline comments to D57114: Remove Expr sugar decorating the CXXUuidofExpr node..
Jan 23 2019, 2:33 PM
void created D57114: Remove Expr sugar decorating the CXXUuidofExpr node..
Jan 23 2019, 12:13 PM

Jan 17 2019

void added a comment to D53765: [RFC prototype] Implementation of asm-goto support in LLVM.

I encountered another ICE here: https://github.com/ClangBuiltLinux/linux/issues/320#issuecomment-455456506

Jan 17 2019, 11:49 PM · Restricted Project

Jan 16 2019

void added a comment to D53765: [RFC prototype] Implementation of asm-goto support in LLVM.

There appears to be an ICE with this patch: https://github.com/ClangBuiltLinux/linux/issues/6#issuecomment-454675962

Jan 16 2019, 5:42 PM · Restricted Project

Jan 15 2019

void added a comment to D53765: [RFC prototype] Implementation of asm-goto support in LLVM.

I like these changes. Could you add the documentation for the new instruction?

Jan 15 2019, 12:43 PM · Restricted Project

Jan 14 2019

void added inline comments to D53765: [RFC prototype] Implementation of asm-goto support in LLVM.
Jan 14 2019, 1:10 PM · Restricted Project
void added inline comments to D53765: [RFC prototype] Implementation of asm-goto support in LLVM.
Jan 14 2019, 12:59 PM · Restricted Project

Jan 11 2019

void added a comment to D55616: Emit ASM input in a constant context.

Apologies - the value seems to indeed overflow, but I'm still very confused how this was affected by this change.

Jan 11 2019, 5:58 PM · Restricted Project

Jan 10 2019

void added inline comments to D53765: [RFC prototype] Implementation of asm-goto support in LLVM.
Jan 10 2019, 5:48 PM · Restricted Project

Jan 4 2019

void added inline comments to D56046: Output ELF files after ThinLTO is run..
Jan 4 2019, 3:30 PM · Restricted Project
void updated the diff for D56046: Output ELF files after ThinLTO is run..

Implement Rui's suggestion for how to output the ELF files.

Jan 4 2019, 3:28 PM · Restricted Project

Jan 2 2019

void updated the diff for D56046: Output ELF files after ThinLTO is run..

Add check that the object file is still valid after using "obj-path".

Jan 2 2019, 5:33 PM · Restricted Project

Dec 31 2018

void added a comment to D56046: Output ELF files after ThinLTO is run..

The filenames of Task=0 and different. Is this preferable?

t.o t2.o were compiled with -module-summary

ld.lld --plugin-opt=obj-path=t3.o -shared t.o t2.o => creates t2.o0 t2.o1 t2.o2

gold --plugin=~/llvm/Release/lib/LLVMgold.so --plugin-opt=thinlto --plugin-opt=obj-path=t3.o -shared t.o t2.o => creates t2.o t2.o1 t2.o2

Dec 31 2018, 10:08 PM · Restricted Project
void updated the diff for D56046: Output ELF files after ThinLTO is run..

Don't append "0" to the object filename.

Dec 31 2018, 10:08 PM · Restricted Project
void updated the diff for D56046: Output ELF files after ThinLTO is run..

Add testcase.

Dec 31 2018, 10:05 PM · Restricted Project

Dec 27 2018

void added a comment to D56046: Output ELF files after ThinLTO is run..

Replicating the gold behavior sounds fine, but does this patch work? This change seems to leave Buf uninitialized while Buf will be used later. Also, in gold LTO plugin, -obj-path overwrites -save-temps, but this change doesn't seem to replicate that behavior. Could you add tests?

Dec 27 2018, 2:38 PM · Restricted Project
void added reviewers for D56046: Output ELF files after ThinLTO is run.: ruiu, MaskRay.
Dec 27 2018, 12:54 PM · Restricted Project
void added a comment to D56046: Output ELF files after ThinLTO is run..

Ping? :-)

Dec 27 2018, 12:54 PM · Restricted Project

Dec 21 2018

void created D56046: Output ELF files after ThinLTO is run..
Dec 21 2018, 11:33 PM · Restricted Project

Dec 18 2018

void added a comment to D55616: Emit ASM input in a constant context.

Looks like it's broken by this patch

clang: /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm/tools/clang/lib/AST/ExprConstant.cpp:11055: llvm::APSInt clang::Expr::EvaluateKnownConstInt(const clang::ASTContext &, SmallVectorImpl<clang::PartialDiagnosticAt> *) const: Assertion `Result && "Could not evaluate expression"' failed.

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/9281/steps/check-clang%20msan/logs/stdio

Dec 18 2018, 9:02 PM · Restricted Project
void committed rL349604: Use "EvaluateAsRValue" instead of as a known int, because if it's not a known.
Use "EvaluateAsRValue" instead of as a known int, because if it's not a known
Dec 18 2018, 8:59 PM
void committed rC349604: Use "EvaluateAsRValue" instead of as a known int, because if it's not a known.
Use "EvaluateAsRValue" instead of as a known int, because if it's not a known
Dec 18 2018, 8:59 PM
void committed rL349603: Revert accidentally included code..
Revert accidentally included code.
Dec 18 2018, 8:40 PM
void committed rC349603: Revert accidentally included code..
Revert accidentally included code.
Dec 18 2018, 8:40 PM
void committed rL349561: Emit ASM input in a constant context.
Emit ASM input in a constant context
Dec 18 2018, 2:58 PM
void committed rC349561: Emit ASM input in a constant context.
Emit ASM input in a constant context
Dec 18 2018, 2:57 PM
void closed D55616: Emit ASM input in a constant context.
Dec 18 2018, 2:57 PM · Restricted Project
void updated the diff for D55616: Emit ASM input in a constant context.

Fix how prefixes are used in the testcase.

Dec 18 2018, 2:57 PM · Restricted Project
void added inline comments to D55616: Emit ASM input in a constant context.
Dec 18 2018, 2:57 PM · Restricted Project

Dec 17 2018

void updated the diff for D55616: Emit ASM input in a constant context.

Reduce duplication by using multiple check prefixes.

Dec 17 2018, 8:10 PM · Restricted Project
void added inline comments to D55616: Emit ASM input in a constant context.
Dec 17 2018, 3:09 PM · Restricted Project
void added a comment to D55616: Emit ASM input in a constant context.

Ping? :-)

Dec 17 2018, 1:08 PM · Restricted Project

Dec 13 2018

void added a comment to D55616: Emit ASM input in a constant context.

This seems like a good start, but not complete.

"n" and "i" both should require that their argument is a constant expression. For "n", it actually must be an immediate constant integer, so setRequiresImmediate() should be used there. For "i", you may use an lvalue constant as well. The way we seem to indicate that, today, is with if (!Info.allowsRegister() && !Info.allowsMemory()). However the code in that block does not today *require* that the evaluation as a constant succeed...and it should.

It should also only require that the result is an integer when requiresImmediateConstant().

Additionally, the Sema code needs to have the same conditions as the CodeGen code for when a constant expression is required, but it doesn't. (before or after your change).

Dec 13 2018, 4:12 PM · Restricted Project
void updated the diff for D55616: Emit ASM input in a constant context.

The n constriant *requires* a known integer. Therefore, enforce this in both
Sema and CodeGen by setting the "requires immediate" flag and evaluating to a
known integer instead of random "int"..

Dec 13 2018, 4:11 PM · Restricted Project

Dec 12 2018

void added a comment to D55616: Emit ASM input in a constant context.

Addressed Eli's comment.

Dec 12 2018, 2:43 PM · Restricted Project
void updated the diff for D55616: Emit ASM input in a constant context.

Don't look at the optimization level here.

Dec 12 2018, 2:42 PM · Restricted Project
void added a comment to D54355: Use is.constant intrinsic for __builtin_constant_p.

The issue is that "n" is expecting an immediate value, but the result of the ternary operator isn't calculated by the front-end, because it doesn't "know" that the evaluation of __builtin_constant_p shouldn't be delayed (it being compiled at -O0). I suspect that this issue will also happen with the "i" constraint.

Indeed. We _do_ actually already know that in clang too, however -- clang already knows that "n" requires an immediate, and does constant expression evaluation for it, e.g. to expand constexpr functions. Grep for "requiresImmediateConstant". I guess it's just not hooked up to the __b_c_p correctly, though.

(Note, as a workaround, you could use | instead of ||, or put the expression as the value of an enumeration constant).

Dec 12 2018, 2:12 PM
void added a comment to D55616: Emit ASM input in a constant context.

As a side note, the number of ways to evaluate a constant expression are legion in clang. They should really be unified...

Dec 12 2018, 2:00 PM · Restricted Project
void created D55616: Emit ASM input in a constant context.
Dec 12 2018, 2:00 PM · Restricted Project
void updated subscribers of D55616: Emit ASM input in a constant context.
Dec 12 2018, 2:00 PM · Restricted Project
void added a comment to D54355: Use is.constant intrinsic for __builtin_constant_p.

The issue is that "n" is expecting an immediate value, but the result of the ternary operator isn't calculated by the front-end, because it doesn't "know" that the evaluation of __builtin_constant_p shouldn't be delayed (it being compiled at -O0). I suspect that this issue will also happen with the "i" constraint.

Dec 12 2018, 11:19 AM

Dec 10 2018

void added a comment to D54355: Use is.constant intrinsic for __builtin_constant_p.

I'm seeing a case where an inline assembly 'n' constraint is behaving differently in -O0 now. Previously we would evaluate the builtin_constant_p as part of the EvaluateAsInt call in CodeGenFunction::EmitAsmInput, but I think we're not doing that now. This causes us to fail later because the constraint wasn't satisfied since we were in -O0 and thus we didn't optimize the rest of the expression. The test case we have is a nasty mix of builtin_constant_p, builtin_choose_expr, and builtin_classify_type. I can see about sharing it if needed.

Dec 10 2018, 9:09 PM

Dec 5 2018

void abandoned D55311: Add support for OUTPUT_ARCH linker script command.
Dec 5 2018, 3:57 PM
void added a comment to D55311: Add support for OUTPUT_ARCH linker script command.

Sorry, I'm really confused. Could you explain again for me why you need this patch to link Linux kernel?

Dec 5 2018, 3:49 PM
void added a comment to D55311: Add support for OUTPUT_ARCH linker script command.

What is the motivation to do this? We don't try too hard to implement every detail of the linker script because it's just too complicated and there is usually an easy workaround that works without a linker script.

The motivation is to support linking Linux, which uses linker scripts heavily. I added a comment by IanT from another thread about why this is a good addition.

Now I remember. We saw this bug earlier and decided to report an issue to linux kernel and not change the linker.
Bug reported here: https://bugzilla.kernel.org/show_bug.cgi?id=194091.

Dec 5 2018, 3:23 PM
void added a comment to D55311: Add support for OUTPUT_ARCH linker script command.

Looks like what you are trying to do is to generate a x86-64 executable from i386 object files. That's what we do not expect in lld. With this patch, in theory you can create AArch64 exectuables from x86-64 object files, but that doesn't make sense and likely to crash the linker because we assume that all object files are uniform in terms of target types.

I think this use case is too tricky to directly support in the linker. I'd probably use objcopy or something to transplant i386 code to x86-64 object file before passing it to the linker, so that we don't deal with the trickiness in the linker.

Dec 5 2018, 3:20 PM
void added a comment to D55311: Add support for OUTPUT_ARCH linker script command.

Even with this patch, don't you still have to make a change to lld so that it accepts a set of input files of different targets?

Dec 5 2018, 3:02 PM
void added inline comments to D55311: Add support for OUTPUT_ARCH linker script command.
Dec 5 2018, 2:12 PM
void added a comment to D55311: Add support for OUTPUT_ARCH linker script command.

What is the motivation to do this? We don't try too hard to implement every detail of the linker script because it's just too complicated and there is usually an easy workaround that works without a linker script.

Dec 5 2018, 12:58 PM
void added a comment to D55311: Add support for OUTPUT_ARCH linker script command.

What is your use case? I wonder what is the reason to use OUTPUT_ARCH to override -m?

It was pointed out that the "-m" flag has slightly different semantics than what we would expect:

Dec 5 2018, 12:57 PM
void added a comment to D55311: Add support for OUTPUT_ARCH linker script command.

Note: I tried to add as many BFD arch entries as I could muster from binutils. It's obvious not complete, so any further entries you think should be here let me know.

Dec 5 2018, 12:41 AM
void created D55311: Add support for OUTPUT_ARCH linker script command.
Dec 5 2018, 12:27 AM

Dec 1 2018

void committed rC348071: Correct indentation..
Correct indentation.
Dec 1 2018, 1:09 AM
void committed rL348071: Correct indentation..
Correct indentation.
Dec 1 2018, 1:09 AM
void committed rC348070: Specify constant context in constant emitter.
Specify constant context in constant emitter
Dec 1 2018, 12:33 AM
void committed rL348070: Specify constant context in constant emitter.
Specify constant context in constant emitter
Dec 1 2018, 12:33 AM

Nov 30 2018

void committed rL348032: Revert r348029. I was git-ing and jumped the gun..
Revert r348029. I was git-ing and jumped the gun.
Nov 30 2018, 12:47 PM
void committed rC348032: Revert r348029. I was git-ing and jumped the gun..
Revert r348029. I was git-ing and jumped the gun.
Nov 30 2018, 12:47 PM
void committed rL348029: We're in a constant context in the ConstantEmitter..
We're in a constant context in the ConstantEmitter.
Nov 30 2018, 12:43 PM
void committed rC348029: We're in a constant context in the ConstantEmitter..
We're in a constant context in the ConstantEmitter.
Nov 30 2018, 12:43 PM
void added a comment to D54125: [LTO] Drop non-prevailing definitions only if linkage is not local or appending.

To replicate the failure, do this:

$ llvm-ar rcsTD test-archive.o softirq.o irqdesc.o
$ ld.gold -plugin LLVMgold.so -plugin-opt=thinlto -plugin-opt=-code-model=kernel -plugin-opt=jobs=6 -plugin-opt=-stack-alignment=8 -m elf_x86_64 -r -o test-object.o --whole-archive test-archive.o
$ nm test-object.o  | grep W
0000000000001370 W arch_dynirq_lower_bound
00000000000001b0 W arch_early_irq_init
00000000000001a0 W arch_probe_nr_irqs
0000000000000190 W early_irq_init

Note that early_irq_init is still weak. It should have resolved to a concrete function.

I tried the reproducer and via -plugin-opts=save-temps I can see that the linker is telling LTO that the copy of early_irq_init in irqdesc.o is non-prevailing and that the softirq.o copy is prevailing. Therefore, with this patch the copy in irqdesc.o which is non-weak is dropped, and the weak copy in softirq.o is kept. So LTO seems to be doing what it should be based on what gold tells it.

The question is why is gold picking the weak symbol as the prevailing copy and not the strong one? Note that if the order of the object files is reversed in the llvm-ar invocation, the irqdesc.o copy of that symbol is the prevailing one as per the linker, and we keep the strong symbol instead.

Interestingly, lld behaves differently. Even with the softirq.o being put first in the archive as you have in your repro, it says that the version of early_irq_init in irqdesc is the prevailing copy, and the strong symbol is kept. Bug in gold?

I confirmed that the the llvm gold-plugin is telling gold that softirq.o:early_irq_init is a hidden weak def and that irqdesc.o:early_irq_init is a hidden strong def, and that gold is subsequently coming back and providing the following resolutions to the plugin for LTO:
softirq.o: early_irq_init: PREVAILING_DEF_REG
irqdesc.o: early_irq_init: PREEMPTED_IR

Interestingly, if I compile the .o files down to native objects, then go through the same llvm-ar and gold link sequence with them, gold does what you want: it keeps the strong def. So this seems to be a bug specific to gold's plugin handling. I'm not sure how to proceed, as the patch fixes a bug and is apparently just exposing a gold linker plugin handling bug.

ah - looks like this patch exposed an issue you already discovered for this same symbol and regular LTO:

http://lists.llvm.org/pipermail/llvm-dev/2018-October/127051.html

Was this ever reported to binutils/gold?

Actually - as Peter suggested there, this is in fact fixed by a more recent version of gold. The gold I use with llvm regression tests (GNU gold (GNU Binutils 2.30.51.20180214) 1.16) fixes this issue:

softirq.o: early_irq_init: PREEMPTED_IR
irqdesc.o: early_irq_init: PREVAILING_DEF_REG

$ nm test-object.o | grep W
0000000000001370 W arch_dynirq_lower_bound
00000000000001a0 W arch_early_irq_init
0000000000000190 W arch_probe_nr_irqs
$

My installed version of gold (1.15) has the bug. So please do use a more recent version of gold to fix this issue.

Nov 30 2018, 11:13 AM
void added a comment to D54125: [LTO] Drop non-prevailing definitions only if linkage is not local or appending.

To replicate the failure, do this:

$ llvm-ar rcsTD test-archive.o softirq.o irqdesc.o
$ ld.gold -plugin LLVMgold.so -plugin-opt=thinlto -plugin-opt=-code-model=kernel -plugin-opt=jobs=6 -plugin-opt=-stack-alignment=8 -m elf_x86_64 -r -o test-object.o --whole-archive test-archive.o
$ nm test-object.o  | grep W
0000000000001370 W arch_dynirq_lower_bound
00000000000001b0 W arch_early_irq_init
00000000000001a0 W arch_probe_nr_irqs
0000000000000190 W early_irq_init

Note that early_irq_init is still weak. It should have resolved to a concrete function.

I tried the reproducer and via -plugin-opts=save-temps I can see that the linker is telling LTO that the copy of early_irq_init in irqdesc.o is non-prevailing and that the softirq.o copy is prevailing. Therefore, with this patch the copy in irqdesc.o which is non-weak is dropped, and the weak copy in softirq.o is kept. So LTO seems to be doing what it should be based on what gold tells it.

The question is why is gold picking the weak symbol as the prevailing copy and not the strong one? Note that if the order of the object files is reversed in the llvm-ar invocation, the irqdesc.o copy of that symbol is the prevailing one as per the linker, and we keep the strong symbol instead.

Interestingly, lld behaves differently. Even with the softirq.o being put first in the archive as you have in your repro, it says that the version of early_irq_init in irqdesc is the prevailing copy, and the strong symbol is kept. Bug in gold?

I confirmed that the the llvm gold-plugin is telling gold that softirq.o:early_irq_init is a hidden weak def and that irqdesc.o:early_irq_init is a hidden strong def, and that gold is subsequently coming back and providing the following resolutions to the plugin for LTO:
softirq.o: early_irq_init: PREVAILING_DEF_REG
irqdesc.o: early_irq_init: PREEMPTED_IR

Interestingly, if I compile the .o files down to native objects, then go through the same llvm-ar and gold link sequence with them, gold does what you want: it keeps the strong def. So this seems to be a bug specific to gold's plugin handling. I'm not sure how to proceed, as the patch fixes a bug and is apparently just exposing a gold linker plugin handling bug.

ah - looks like this patch exposed an issue you already discovered for this same symbol and regular LTO:

http://lists.llvm.org/pipermail/llvm-dev/2018-October/127051.html

Was this ever reported to binutils/gold?

Nov 30 2018, 11:10 AM

Nov 29 2018

void added a comment to D54125: [LTO] Drop non-prevailing definitions only if linkage is not local or appending.

To replicate the failure, do this:

Nov 29 2018, 5:52 PM
void added a comment to D54125: [LTO] Drop non-prevailing definitions only if linkage is not local or appending.

Hi @piramam,

This change is breaking the Linux ThinLTO build. I'll work to get you a test case. Could you revert this patch until we can resolve the issue?

This patch fixed a longstanding break with ThinLTO + PGO + LLD. If the current issue is easy to fix, I'd prefer to fix forward rather than revert this patch. Can you share details on what fails - error message or crash?

But ultimately, this is @tejohnson's call to revert or fix forward.

Nov 29 2018, 5:49 PM
void reopened D54125: [LTO] Drop non-prevailing definitions only if linkage is not local or appending.

This change is breaking the Linux ThinLTO build. I'll work to get you a test case. Could you revert this patch until we can resolve the issue?

Nov 29 2018, 5:32 PM
void accepted D54964: Add test about __builtin_constant_p.
Nov 29 2018, 10:17 AM

Nov 25 2018

void committed rC347531: A "constexpr" is evaluated in a constant context. Make sure this is reflected.
A "constexpr" is evaluated in a constant context. Make sure this is reflected
Nov 25 2018, 6:14 PM
void committed rL347531: A "constexpr" is evaluated in a constant context. Make sure this is reflected.
A "constexpr" is evaluated in a constant context. Make sure this is reflected
Nov 25 2018, 6:14 PM
void added a comment to D54355: Use is.constant intrinsic for __builtin_constant_p.

Fixed in r347531.

Nov 25 2018, 6:14 PM
void added a comment to D54355: Use is.constant intrinsic for __builtin_constant_p.

Doh! I'll take a look at it.

Nov 25 2018, 4:28 PM

Nov 24 2018

void committed rC347512: isEvaluatable() implies a constant context..
isEvaluatable() implies a constant context.
Nov 24 2018, 2:49 AM
void committed rL347512: isEvaluatable() implies a constant context..
isEvaluatable() implies a constant context.
Nov 24 2018, 2:49 AM

Nov 22 2018

void committed rC347480: A __builtin_constant_p() returns 0 with a function type..
A __builtin_constant_p() returns 0 with a function type.
Nov 22 2018, 3:01 PM
void committed rL347480: A __builtin_constant_p() returns 0 with a function type..
A __builtin_constant_p() returns 0 with a function type.
Nov 22 2018, 3:01 PM
void committed rC347446: The result of is.constant() is unsigned..
The result of is.constant() is unsigned.
Nov 22 2018, 1:34 AM