similar to: [LLVMdev] DragonEgg 3.0 with GCC 4.7

On Tue, Jul 19, 2011 at 10:12:47AM +0100, Jay Foad wrote: > On 18 July 2011 15:23, David Blaikie <dblaikie at gmail.com> wrote: > > Looks like that break came > > from http://llvm.org/viewvc/llvm-project?view=rev&revision=135154 > > Judging by this ArrayRef ctor you should be able to simplify those calls by > > changing the last two arguments from

Hi, guys, If there is a struct {i8, i8, i32}, and there are several parameter GPRs(32bits), say, r0, r1~r5, I can make this struct to be passed in r0, r1 because LLVM_SHOULD_PASS_AGGREGATE_IN_INTEGER_REGS is true in DefaultABI, neither it passed by value, nor it passed as FCA. But if the first parameter register r0 is occupied by other argument, in DefaultABI, that struct passed as a i64, and

Evan Cheng <evan.cheng at apple.com> writes: >> I'll be interested on hearing ideas about how to determine how a >> function returns a small struct, without knowing the internals of the >> struct. > Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. This does not qualify as "without knowing the internals of the struct" :-)

> struct T { > struct T (*p)(void); > } t; This testcase also generates infinite recursion when we use llvm-gcc for arm-target. Because return type of function pointer p's is struct type T which has one element, llvm-gcc for arm target calls a function which tries to chang aggregate return type to inner element. (For example, C.HandleAggregateResultAsScalar(Ty); -->

On 18 July 2011 15:23, David Blaikie <dblaikie at gmail.com> wrote: > Looks like that break came > from http://llvm.org/viewvc/llvm-project?view=rev&revision=135154 > Judging by this ArrayRef ctor you should be able to simplify those calls by > changing the last two arguments from "&foo, 1" to, simply, "foo". I've done this in r135472. Jay.

Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. Evan On Mar 26, 2008, at 10:31 AM, Óscar Fuentes wrote: > Óscar Fuentes <ofv at wanadoo.es> writes: > >> BTW, -fpcc-struct-return solves the case that motivated this thread. > > -fpcc-struct-return is an ABI change, hence it requires "compiling the > world". Not acceptable. > > I'll

Dear All, Could you please recommend how I can do this? I have several text files in one folder. Let's name them A0801.RSK, A0802.RSK, .... I would like R to 1) Know all file names in this folder 2) Update value in one column of these files 3) Write results in another text file with _xval in the file names Below is R code for read, update, and write one file

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Hi, I'm very fond of maildirs, they are simple, I like that. But I've never really understood the significance of maildir/new/. The only use I can see is that (for example in the case of dovecot), you'd move a message from new to cur and then update the index-file, that's it. So to make put it more direct, you'd know when and with what to update the index-file, based on

On Sat, Jul 9, 2011 at 4:27 PM, Chris Lattner <clattner at apple.com> wrote: > I'm sorry, I've been away from the computer. I'll investigate this in the next half hour.  Thanks for the test cases! One more testcase, which might be of interest; crashes clang on x86-64: struct T { struct T (*p)(void); } t; -Eli

On Jul 9, 2011, at 4:35 PM, Eli Friedman wrote: > On Sat, Jul 9, 2011 at 4:27 PM, Chris Lattner <clattner at apple.com> wrote: >> I'm sorry, I've been away from the computer. I'll investigate this in the next half hour. Thanks for the test cases! > > One more testcase, which might be of interest; crashes clang on x86-64: > > struct T { > struct T

Hi Nick, On Tue, 26 Oct 2010, Nick Lewycky wrote: > Joel E. Denny wrote: > > Given this LLVM assembly: > > > > @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* > > getelementptr (i32* null, i32 1) to i64), i64 2)) > > > > llc fails an assertion: > > > > llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202:

There are various functions in llvm-convert.cpp that depend on BITS_BIG_ENDIAN: TreeToLLVM::EmitLoadOfLValue() TreeToLLVM::EmitMODIFY_EXPR() InsertBitFieldValue() ProcessBitFieldInitialization() The comments say things like: // If this target has bitfields laid out in big-endian order, invert the bit // in the word if needed. // If this is a big-endian bit-field, take the top

Hi all, I'm currently trying to bootstrap llvm-gcc-4.2 from the latest stable LLVM release 2.6 on Solaris SPARC. The compilation with a self-build gcc-4.2.4 goes pretty well, however, I hit a seemingly widely know error during llvm-gcc's bootstrap in getting an assertion during the compile of /data/LLVM/src/GCC/RELEASE_26/gcc/libgcc2.c: /data/LLVM/src/GCC/RELEASE_26/gcc/libgcc2.c: In

Hello, Juergen > With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', > so I wonder what needs to be done in order to get LLVM to produce > code for 'TREE_CODE(type) == REAL_TYPE' in the 'HandleArgument' function. > > > Does anyone have an idea? And why does this only happen on SPARC? What is the value of "Ty" in your case?

On Mon, Oct 22, 2012 at 10:17:56AM -0700, Nick Kledzik wrote: > Jack, > > I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: > > dyld: fast lazy bind offset out of range (53437, max=7640) in image

Luke Dalessandro wrote: > OK. So I've discovered --with-sysroot which seems to be grabbing and > patching the include files correctly. Now it's dieing with > > ./options.h:462: error: 'HOST_BITS_PER_INT' undeclared here (not in a > function) > ./options.h:462: error: bit-field 'padding' width not an integer constant > > which appears to be

After applying the patches in my previous message... I'm getting the following when building dovecot for CentOS 6 (but not for CentOS 7): lmtp payload - normal: parallel pipelining ssl ....................... : ok CLIENT: Panic: file smtp-client-connection.c: line 1309 (smtp_client_connection_established): assertion failed: (!conn->connect_succeeded) CLIENT: Error: Raw backtrace:

On Mon, 21 Sep 2020 at 09:53, Hisashi T Fujinaka <htodd at twofifty.com> wrote: > OK, NetBSD-current amd64, NetBSD-9-amd64, and NetBSD-9-i386 all pass all > tests. MacOS, well, I always try it but it has problems. What's the problem on OS X? We test on it regularly (El Capitan and High Sierra) and the only problem I'm aware of is that the native libcrypto on High Sierra is

Mike Stump wrote: > On Oct 31, 2008, at 1:10 PM, Luke Dalessandro wrote: >> I've started trying by trying to get sparc-sun-solaris2.10 (niagara) >> working. It appears that neither llvm nor llvm-gcc will build natively >> on the system, so I think that I need to build an llvm-gcc cross >> compiler. > > Get a gcc binary from someplace, use that to then build