@echristo Thanks for the comment, Eric. I'm happy to do what is expected. Do you mean that it's a bug not to accept these cases, and we should fix it rather than XFAIL? So the build should not be green from XFAIL but only from a fix in this case?

In a quick test, I used else if (TI.getTypeWidth(TI.getWCharType()) == 8) but did you want to avoid that?

At the moment Clang defines __XS1B__ for XCore, but really that's one subtarget, I need to patch to define __xcore__ . It's an embedded processor, usually bare metal, so wouldn't have an OS character set. I just saw this change and thought I'd mention it's only 8 bits wide - I don't know what the best approach is. I'll discuss with others. Thanks for the quick reply.

The XCore target has 8-bit wchar_t (unsigned char). Should there be a test for width == 8 and set to "UTF-8", or at least not "UTF-16"?

Use XFAIL

Invite inline assembly code owner to review.

Tidy up.

Thank you for the reviews, I appreciate people taking time on something that is only for this target.

Invite debug info code owner to review.

As suggested, excluded xcore from DebugInfo/Generic rather than patching each file.

Tidy up.

Restore lit feature object-emission. Omit DebugInfo/Generic on XCore.

Thanks, I see what you mean about churn and maintenance. The integrated assembler is planned. I will rework the patch.

DebugInfo/Generic can be handled by two lines in lit.local.cfg:

@MaskRay Thanks for the comment. I will look at that. But DebugInfo/Generic has 78 files requiring object-emission and 60 not requiring it - isn't it worth still running the 60? (I looked at some to see what they were doing: running llvm-as, llvm-dis, and checking assembly output.)

Invite reviewers around llvm-mc tool tests.

Invite reviewers around llvm-mc tool tests.

Invite reviewers around lit.cfg.py changes.

Add reviewer suggestions from CodeGen/Generic history.

Thanks, Galina.

Thanks @clayborg

• Incorporate isConfigurationSupported in isObjectEmissionSupported

@labath Thanks for the quick response. That looks like a good idea. I will try that.

Run clang-format

arc --update with all changes.

[XCore] Do not override LLVM_LIT_ARGS: use -j from the factory.

https://github.com/llvm/llvm-zorg/commit/f128ee547d9f4d1fc9480b9e95b6c119d9a08392

Revise as per review comments.

Created by mistake.

I think this patch can be cancelled, because the issue is already fixed in the main branch. But please say if I have missed something.

I've reproduced the failure. The test passes when I change -march=xcore to -mtriple=xcore-unknown-unknown, as in main branch commit https://github.com/llvm/llvm-project/commit/15ca54525d6c2927b2a51b871a9e343c7ce1c2ea. Does that commit solve this problem and unblock D91556 ? (I will continue to investigate to understand the reason for the register swap.)

The specified XCore backend code owner has moved on from XMOS and from working on XCore. I will have a look at this patch.

Many thanks for review and approval. Please could it be committed as I do not have commit access? (I will request.)

Added reviewer suggestions from git history. If someone familiar with updating the documentation could commit for me, I would be grateful, as I do not have commit access.

Run clang-format

Run clang-format

Alternatively, if all 1-byte-character strings are acceptable, should I remove the check that the first token is a string literal, and omit the failing test case on XCore?

I do not have commit access, so if this is approved, please could it be committed against author "Nigel Perks" nigelp@xmos.com ?

Added explanatory comment and CHECK lines to test case, as per review comment.

Ping. I made the change suggested by @erichkeane .

As suggested by FIXME comment in code, and review comment, moved the EmitTargetMetadata loop into XCore target.

Thanks for the comment, I will look into that.

Adding code reviewer suggestions from git history. I would be grateful for review and/or reviewer suggestions. Many thanks.

This patches fixes two Clang tests which are failing for XCore target on 2020-04-27 with "unexpected null value" assert failures:

Just a polite ping to keep it alive. I hope that's all right. Not urgent at all.