royger (Roger)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 1 2017, 2:37 AM (85 w, 6 d)

Recent Activity

Mar 16 2018

royger added a comment to D44531: MC: fix layering violation introduced in r325139.

llvm/tools/clang/lib/Basic/SourceManager.cpp:173:17: error: no viable conversion from 'const char [5]' to 'llvm::StringLiteral'

Are you using gcc (~4.x) by any chance? Older versions of gcc seem to have issues with the StringLiteral constructor. One solution is to wrap the argument in extra {}, so something like .StartsWith({"\x00\x00\xFE\xFF"}, "UTF-32 (BE)")

Mar 16 2018, 2:48 AM

Mar 15 2018

royger created D44531: MC: fix layering violation introduced in r325139.
Mar 15 2018, 11:45 AM

Feb 14 2018

royger updated the diff for D43006: MC: store defined macros in MCContext.
  • Remove unneeded includes from MCAsmMacro.h
Feb 14 2018, 12:37 AM

Feb 13 2018

royger updated the diff for D43006: MC: store defined macros in MCContext.
  • Fix nits in the test.
  • Properly format MCAsmMacro.h.
Feb 13 2018, 9:22 AM
royger added a reviewer for D43006: MC: store defined macros in MCContext: grosbach.
Feb 13 2018, 4:28 AM

Feb 7 2018

royger created D43006: MC: store defined macros in MCContext.
Feb 7 2018, 2:11 AM

Jan 16 2018

royger added a comment to D41723: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre...

I still think the interface should be fixed, so that later on when lfence (or other thunks) is added clang doesn't end up with:

Jan 16 2018, 10:58 AM

Jan 5 2018

royger added a comment to D41723: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre...

Add support for externally provided thunks. This is an independent feature;
when combined with the overall retpoline feature it suppresses the thunk
emission and rotates the names to be distinct names that an external build
system for the kernel (for example) can provide.

I've added some minimal documentation about the semantic requirements of these
thunks to the commit log, although it is fairly obvious. More comprehensive
documentation will be part of the large follow-up effort around docs.

Jan 5 2018, 1:58 AM

Jan 4 2018

royger added a comment to D41723: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre...

AFAICT this change doesn't allow to use different indirect thunks, gcc allows such usage with the -mindirect-branch=thunk-extern/-mindirect-branch-register options. The following patches for example allow Xen to choose the optimal thunk depending on the processor:

Jan 4 2018, 9:55 AM

Feb 2 2017

royger added a comment to D20561: Warn when taking address of packed member.

It's not clear to me whether upstream is going to do something about this or not. I would like to know in case I need to start passing "-Wno-address-of-packed-member" around.

Feb 2 2017, 8:18 AM

Feb 1 2017

royger added a comment to D20561: Warn when taking address of packed member.

@royger: Your example is missing explicit alignment. packed has two side effects: remove internal padding and set the alignment to 1. That means that the offset of base doesn't matter so much because reg itself is not necessarily aligned.

Feb 1 2017, 5:29 AM
royger added a comment to D20561: Warn when taking address of packed member.

... and both revisions should be in the 4.0 branch (taken from r291814)

I was looking forward to this warning to help iron out alignment issues at compile-time instead of runtime (our ARM CPUs don't like unaligned access). @royger, can you expand a little on what you mean by

For once, it doesn't really check whether the access is actually unaligned or no

? Isn't that exactly what it does? Or do you mean in relation to whether the target allows unaligned access or not?

Feb 1 2017, 4:15 AM
royger added a comment to D20561: Warn when taking address of packed member.

We fixed all identified false positives in later patches to this one. So maybe you want to check against trunk clang. If trunk still diagnoses false positives, please report them to me and I will be more than happy to fix them.

Feb 1 2017, 3:27 AM
royger reopened D20561: Warn when taking address of packed member.

This addition is silly, and too noisy for real world usage.

Feb 1 2017, 2:40 AM