search for: scshunt

On Fri, Mar 30, 2012 at 15:22, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Mar 30, 2012 at 12:12 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> > wrote: > > Why is it that high (>127) bytes in symbol names get mangled by LLVM into > > _XX_, where XX is the hex representation of the character? Is this > required > > by ELF or some similar standard? This behavior is inconsistent with GCC....

Why is it that high (>127) bytes in symbol names get mangled by LLVM into _XX_, where XX is the hex representation of the character? Is this required by ELF or some similar standard? This behavior is inconsistent with GCC. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Mar 30, 2012 at 12:12 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> wrote: > Why is it that high (>127) bytes in symbol names get mangled by LLVM into > _XX_, where XX is the hex representation of the character? Is this required > by ELF or some similar standard? This behavior is inconsistent with GCC. I think it's just s...

On Fri, Mar 30, 2012 at 6:17 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> wrote: > On Fri, Mar 30, 2012 at 15:22, Eli Friedman <eli.friedman at gmail.com> wrote: >> >> On Fri, Mar 30, 2012 at 12:12 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> >> wrote: >> > Why is it that high (>127) bytes in symbo...

On Fri, Mar 30, 2012 at 21:22, Eli Friedman <eli.friedman at gmail.com> wrote: > Okay... then we should probably support that as well.  Might need to > be a bit careful to make sure the assembly files work correctly. > > -Eli > You mean machine assembly and not IR, right? Sean

On Sat, Mar 31, 2012 at 2:44 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> wrote: > On Fri, Mar 30, 2012 at 21:22, Eli Friedman <eli.friedman at gmail.com> wrote: >> Okay... then we should probably support that as well.  Might need to >> be a bit careful to make sure the assembly files work correctly. >> >> -Eli...

On Sun, Jun 17, 2012 at 7:30 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi Christoph, > > It is a good question even though it is obvious :-)  No, for the last few > days, I have not been able to build Clang with make -j2 or -j4 - the build > always fails on a ranlib operation. > > Also, on Windows, GNU Make seems to be somewhat broken with respect to >

Hi Christoph, It is a good question even though it is obvious :-) No, for the last few days, I have not been able to build Clang with make -j2 or -j4 - the build always fails on a ranlib operation. Also, on Windows, GNU Make seems to be somewhat broken with respect to parallel builds: It doesn't change a thing whether you specify -j2 or -j4 on a quad-core machine (with hyper-threading

This is a behaviour configurable in the MCAsmInfo. I've decided to turn it on by default in (possibly optimistic) hopes that most assemblers are reasonably sane. If this proves a problem, switching to default seems reasonable. --- include/llvm/MC/MCAsmInfo.h | 7 +++++++ lib/MC/MCAsmInfo.cpp | 1 + lib/Target/Mangler.cpp | 11 +++++++---- 3 files changed, 15 insertions(+),

Would anyone object to an attempt to improve cast<> error messages by outputting the expected type and the type received? The interface I'm thinking of is to use ADL to do visitor-style lookup, so we don't need to change every client. In particular, for clients in clang, we can just create these functions implicitly from our TableGen-generated files. I'm not sure about