similar to: [LLVMdev] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes

On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> non-8-bit byte I'm a bit confused by this concept. I'm aware of the archaic meaning of the word byte, but it has meant 8 bits for the last 30 years. There's even an ISO/IEC standard. I know of architectures like Texas' C55x DSPs that address 16 bits at a time, but even their

On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > >>> non-8-bit byte > > I'm a bit confused by this concept. I'm aware of the archaic meaning of the word byte, but it has meant 8 bits for the last 30 years. There's even an

On Oct 19, 2012, at 10:47 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> >> On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> >>>> non-8-bit byte >> >> I'm a bit confused by this concept.

> I'm a bit confused by this concept. For the term byte, I use the "archaic" definition in the C (and C++) standard (section 3.6): addressable unit of data storage large enough to hold any member of the basic character set of the execution environment /Patrik Hägglund -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: den 19 oktober

On Oct 19, 2012, at 11:43 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> I'm a bit confused by this concept. > > For the term byte, I use the "archaic" definition in the C (and C++) standard (section 3.6): > > addressable unit of data storage large enough to hold any member of the basic character > set of the execution environment

Hi Chris and John, You are listed as administrators for llvm-commits. Can you provide some help in this issue: that my LLVM svn commit messages do not reach llvm-commits? /Patrik Hägglund -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Patrik Hägglund H Sent: den 28 november 2012 22:19 To: Tobias Grosser Cc:

> @Patrik: would you mind to check if you are subscribed with your ericsson email address? As far as I can see, I'm subscribed to llvm-commits with the same email address used in commits (I get buildbot failure emails to the same mail account as llvm-commits messages). (BTW, why should my subscription status to llvm-commits matter?) > It would be nice to see your commit mails. Yes,

On Nov 29, 2012, at 7:11 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 29.11.2012, at 15:53, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > >> Hi Chris and John, >> >> You are listed as administrators for llvm-commits. Can you provide some help in this issue: that my LLVM svn commit messages do not reach llvm-commits? >

On 29.11.2012, at 15:53, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > Hi Chris and John, > > You are listed as administrators for llvm-commits. Can you provide some help in this issue: that my LLVM svn commit messages do not reach llvm-commits? My guess: the mailer may have issues with the non-ascii character "ä" in your name. See also

On Jan 19, 2012, at 2:16 AM, Patrik Hägglund <patrik.h.hagglund at ericsson.com> wrote: > Is it intended that in some cases it is necessary to use > "-disable-cross-class-join" to be sure the resulting code is ok? No. > I have several cases where cross class joins are carried out that makes > the code turn out illegal, because the "new" register class is

Thanks, now it links. If nobody objects, I will commit the following patch: diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp index 44d8cce..8acc220 100644 --- a/lib/Target/X86/X86JITInfo.cpp +++ b/lib/Target/X86/X86JITInfo.cpp @@ -339,6 +339,8 @@ extern "C" { /// must locate the start of the stub or call site and pass it into the JIT /// compiler function.

Compiling LLVM with gcc, 4.3 and upwards, seems to give compile warnings. Is there any canonical gcc version that should be used (for building trunk)? >From http://llvm.org/docs/HowToReleaseLLVM.html#release-build: The builds of llvm, clang, and dragonegg must be free of errors and warnings in Debug, Release+Asserts, and Release builds. The table below specifies which compilers are used

I tried to compile LLVM with gcc-4.8.1 -flto. I got the following error, when linking lli, llc, opt, or libLTO.so: `LLVMX86CompilationCallback2' referenced in section `.text' of /tmp/cclv7BYB.ltrans0.ltrans.o: defined in discarded section `.text' of X86JITInfo.o (symbol from plugin) collect2: error: ld returned 1 exit status Removing the LLVM_LIBRARY_VISIBILITY attribute for

2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is

> It's definitely doable, but I'd be worried about the maintenance burden. Yes, that is a problem. We are currently not allowed to reveal our target (which has 16-bit bytes, and registers with non-power-of-two bit widths) fully, and therefore not able to submit it upstream. One idea we have toyed with is to create a simple "dummy" version of our target, just to be able

On Sat, Nov 10, 2012 at 3:21 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > From r167602 and onwards I get a fail in 'make check-all' for llvm+clang, > built with gcc-4.7.1 (but not with clang-3.1) on Linux x86_64: > > Failing Tests (1): > Clang :: CodeGenCXX/mangle-ms-templates.cpp > > clang:

Hi Alexandra, I'm not sure want you want to do. Is the data layout string (http://llvm.org/docs/LangRef.html#datalayout, also usually set by each target specific *TargetMachine constructor), for setting the alignment good enough for you? Or is it more than the alignment you want to control? Do you have a target with 16-bit bytes? In that case, there is quite a lot of changes that needs to be

On 11/28/2012 03:47 PM, Jean-Daniel Dupas wrote: > > Le 28 nov. 2012 à 15:07, Tobias Grosser <tobias at grosser.es> a écrit : > >> Hi, >> >> I just realized non of Patrik's commit mails has every reached llvm-commits. Neither my own archive nor the web interface contains commit messages for any of his commits. The relevant commits are >> >> 168785,

I think that the relevant part in C11 is section 6.2.6.1, which tells you that accessing a trap representation, _other than using a char type_, is undefined. Objects of automatic storage, which don't have an initializer are of indeterminate value, which either is an unspecified value or a trap representation. > What I found is that with -O2: > LLVM (trunk) prints both "a" and

There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor,