similar to: C or Java code generation

James, we are using an *unmodified* llvm-project (master llorg), and just add some extra projects from our internal repos to the top-level. Thanks, Slava From: James Y Knight [mailto:jyknight at google.com] Sent: Wednesday, July 17, 2019 11:19 AM To: Zakharin, Vyacheslav P <vyacheslav.p.zakharin at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC]

Vyacheslav, I've tracked down the change and I have a fix for you to test. The attached patch should be applied to the CVS head (version 1.132) of X86AsmPrinter.cpp in llvm/lib/Target/X86. The patch just includes MINGW targets in the same set of choices that it makes for Cygwin. Could you please try the patch and let me know if it solves your problem? If it does, I'll commit the patch.

Hi Cameron, Thank you for the comments, but I am confused even more now ☺ > llvm.rint won't honor the FPEnv in all cases. It falls under the default FPEnv The default FPEnv section specifies round-to-nearest rounding mode. In this case, how is it correct to map rint() user call to llvm.rint intrinsic call? If this is just a temporary inconsistency, and the long term solution is to map

Reid, This patch won't work for me. I compile llvm toolset with MSVC Express (hence __MINGW32__ won't be defined for me at compile time). I only try to feed the generated assembly into gcc (pretty much gnu assembler, I suppose). I don't use mingw tools at the earlier stage. However it's obvious for me how to modify the code now (just add MSVC at that line), thanks! I'll try it

Hello, My team is using some non-llvm projects along with llvm-project monorepo. The projects are checked out to the top level of llvm-project, and 'git status' would complain about them unless we add them to .gitignore. We do not really want to change llorg's .gitignore on our side, so may we propose changing llorg's .gitignore to ignore all top-level files/directories that are

Ok, I just tried the patch with some modifications (added msvc target and used WIN32 instead of __MINGW32__ for preprocessor) and everything worked beautifully. Thanks for the help! On Mon, 7 Mar 2005 20:45:40 -0500, Vyacheslav Akhmechet <coffeemug at gmail.com> wrote: > Reid, > > This patch won't work for me. I compile llvm toolset with MSVC Express > (hence __MINGW32__

Hi, mustPreserveAnalysisID(LCSSAID) cannot be used with the new pass manager, so what is the right way for querying it? FunctionAnalysisManager::getCachedResult<LCSSAPass>(F) will not work, since LCSSAPass does not have a result. Moreover, it is not an analysis :) Thanks, Slava -------------- next part -------------- An HTML attachment was scrubbed... URL:

REXP has an asBytes() method. Will this capture the output of an R plot function if a proper graphics device is used? It appears R insists on sending plot output to a file. Kind of strange since it insists on loading all your data into memory before it can do anything. If so then does anyone know what this would be? I prefer png or jpeg. Example: c is an RConnection REXP r =

Hello, I believe llvm.rint description in LangRef is not quite complete. Llvm seems to map math.h:rint() call to llvm.rint intrinsic, and the LangRef says that the result of llvm.rint matches the result of libm rint() call. Next, LangRef states that llvm.rint "returns the operand rounded to the nearest integer." Shouldn't the specification also say that "the actual rounding

The Asterisk Development Team has announced the release of Asterisk 13.8.0. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 13.8.0 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following are the issues resolved in this release: New

I successfully compiled CVS HEAD yesterday on my win32 machine using Visual C++ Express (2005). I also have Mingw tools installed. I wrote a simple hello world application and generated native assembly code using llvm. When I tried to feed the code into GCC, it rejected it with "junk at the end of line" error messages. Shouldn't GCC be able to assemble this code? I realize win32 port

The Asterisk Development Team has announced the release of Asterisk 11.22.0. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 11.22.0 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following are the issues resolved in this release: Bugs

Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. Reid. On Mon, 2005-03-07 at 16:39, Vyacheslav Akhmechet wrote: > Ok, I got home so I have more details. Here's the

Ok, I got home so I have more details. Here's the sample C program: ----------------- C program --------------- #include <stdio.h> int main() { printf("hello world\n"); return 0; } ------------- end C program ------------- This is compiled using llvm online demo into the following llvm code (target removed): ----------------- LLVM code -------------- deplibs

(earlier I sent it as html by mistake). Hi, How can I get from C an object name used as a function argument? I have sample code in C that gives me access to the name of the function being called: SEXP xname(SEXP x) { const char *fun_name = CHAR(PRINTNAME(CAR(x))); x = CDR(x); const char *arg_name = isNull(TAG(x)) ? "" : CHAR(PRINTNAME(TAG(x)));

I noticed that the operand commuting code in X86InstrInfo.cpp treats scalar FMA intrinsics specially. It prevents operand commuting on these scalar instructions because the scalar FMA instructions preserve the upper bits of the vector. Presumably, the restrictions are there because commuting operands potentially changes the result upper bits. However, AFAIK the Intel and GNU FMA intrinsics

Hello, I use FreeBSD 8.2-RELEASE-p7 i386 dovecot-2.1.6 dovecot-pigeonhole-0.3.0_1 I have the following problem: When I use the following script - the flag is set in \Seen : require ["imap4flags"]; # rule:[test] if anyof (header :contains "Subject" "test") { setflag "\\Seen"; stop; } . SELECT INBOX * OK [CLOSED] Previous mailbox

> a) Make all functions the same type. For example, make them all return > void, take a vector of parameters as the first argument, and a vector > for return values as the second argument. This is something I was considering. I guess I'll end up going with this option. > I don't see how this is a specific challenge with LLVM. It seems to me > that this is a challenge that

> I'm confused. My understanding is that Visual C++ Express does not > include Visual Studio, which is required to build LLVM. Well, Visual C++ Express is a cut down version of Visual Studio. I'm not sure about exact differences between editions but Visual C++ Express does read the .sln files and comes with an excellent C++ compiler. I didn't encounter any problems building llvm

I recently ran into the following problem. I'm prototyping a compiler for a dynamically typed language in which functions are first class objects. Assuming I have something like this: if(rand() > 5) i = define(x, y, z) { return x + y + z; } else i = define(x, y) { return x + y; } At this point I cannot know the type of 'i' at compile time. At runtime 'i' is a