Clarify what happens in LookupOption when failing to match an option.

Fix comment in LookupOption for AlwaysPrefix early bail out

Take CommandLine option code into a separate patch

• Forbid AlwaysPrefix option to look for their value in following argument
• Add unit tests for changes to CommandLine

Add AlwaysPrefix option formatting flag and define FileCheck's -D option with it.
Add detection of missing variable name.

In D55940#1337957, @jdenny wrote:

In D55940#1337906, @probinson wrote:

This will permit -DVALUE= (with no value) is that a supported usage?

I think it should be. You could have a string that sometimes appears and sometimes is excluded entirely.

It also permits -D=10 which I daresay doesn't mean anything.

Agreed.

Document how to set numeric variable with -D option

FileCheck: Add support for numeric variables and expressions

LGTM. Thanks!

In D49084#1203189, @rnk wrote:

FWIW I had a use case for this recently, and found it hadn't landed. Is there anything blocking that you need help with?

Hi George,

• Change test for isSized() into assert
• Add test for multiple return values with matching input
• Rewrite hardfloat tests to return a struct to make register used predictable and not dependent on register allocator

Ping? This fix the bug reported in https://reviews.llvm.org/rL337903

In rL337903#281385, @thopre wrote:

In rL337903#281283, @tra wrote:

It appears that this patch crashes llvm under some circumstances.

Reproduction:

test.cc:

float asmfunc(int a, int b) {
  float read_value;
  asm("" : "=r"(read_value), "=r"(a));
  return read_value;
}
int B_X;
void kFCNorm(int a, float b) {
  B_X = asmfunc(a, B_X) * b;
}

$ clang -S -O3 test.cc -o - `
...
clang-7: <redacted>/repo/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:4489: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc &, llvm::EVT, llvm::SDValue, llvm::SDValue, const llvm::SDNodeFlags): Assertion `VT.isFloatingPoint() && "This operator only applies to FP types!"' failed.

I can reproduce, thanks. I'll see if I can find a fix today and if not will revert it and its follow-up patch.

Fixed in trunk

In rL337903#281283, @tra wrote:

It appears that this patch crashes llvm under some circumstances.

Reproduction:

test.cc:

float asmfunc(int a, int b) {
  float read_value;
  asm("" : "=r"(read_value), "=r"(a));
  return read_value;
}
int B_X;
void kFCNorm(int a, float b) {
  B_X = asmfunc(a, B_X) * b;
}

$ clang -S -O3 test.cc -o - `
...
clang-7: <redacted>/repo/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:4489: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc &, llvm::EVT, llvm::SDValue, llvm::SDValue, const llvm::SDNodeFlags): Assertion `VT.isFloatingPoint() && "This operator only applies to FP types!"' failed.

Rebase and rename testcase for consistency

Hi Jackson, can you reupload the patch with more context line? Something like git diff -U99999 (arc diff does it automatically). Thanks.

Rebase on latest version of previous patch in stack

Fix logic for input matching a register constraint for a specific register and add tests for it. I've verified that the code for this logic is executed by those new testcases and that the testcase failed without the fix.

LGTM now.

Hi Kyungtak,

In D49525#1173010, @Dor1s wrote:

Kevin, looks like test is not fully deterministic :(

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/5509

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/5509/steps/ninja%20check%202/logs/FAIL%3A%20libFuzzer%3A%3A%20handle_unstable_minunstable.test

This is the first testbot failure I've seen so far, so am not reverting the change yet, but please take a look into why the test might be failing sometimes.

Rename testcase and test both soft and hard float ABI

Rename testcase and test both soft and hard float ABI

Rename testcase and test both soft and hard float ABI

Hi Eli,

In D49084#1158838, @thopre wrote:

In D49084#1156379, @probinson wrote:

Maybe this should be a new class of "numeric variables" with distinct syntax, e.g., [[#VAR]] or something, with an implicit regex of [[:digit:]]+ instead of making the test-writer use a valid regex.

I'm not sure I'm following you. Do you mean using a different syntax when (i) defining numeric variable or (ii) when using numeric expression?
I also do not understand how this would prevent the test-writer from having to use a valid regex. Could you give an example of the problem you see?

In D49084#1156379, @probinson wrote:

Maybe this should be a new class of "numeric variables" with distinct syntax, e.g., [[#VAR]] or something, with an implicit regex of [[:digit:]]+ instead of making the test-writer use a valid regex.

Thanks all for the valuable comments. It seems clear that more discussion is needed on the syntax before doing any code change. I'll think about it and post a proposal to the ML.

In D45376#1139317, @thopre wrote:

In D45376#1070014, @efriedma wrote:

Could you separate the "add support for matching input" part into a separate patch? I'm having trouble following what exactly you're trying to do.

Done. Sorry for the delay, was in extended leave away from computer.

Rebase

In D45376#1070014, @efriedma wrote:

Could you separate the "add support for matching input" part into a separate patch? I'm having trouble following what exactly you're trying to do.

Split the matching input handling into a separate patch.

As I said, LGTM. Please wait a few days (say next Monday) in case anyone else has any objection.

FWIW LGTM.

Ping?

Ping?

Fix code style issue