similar to: [LLVMdev] Question about non-UTF-8 filesystems

On Wednesday, August 18, 2010 11:49:28 am Anton Korobeynikov wrote: > Hello > > > Is there some official git repository to clone from? > > Not yet, but probably there will be something pretty soon. > Right now there are some unofficial mirrors at repo.or.cz and github Ok, then I will try to wait until the official is ready. If I now start that with an unofficial one, I will

Hi, we want to use LLVM together with clang internally for preprocessing and Co. Therefor we would like to integrate it in our buildsystem. The nicest thing for us would be a local git repository mirror, to allow us to easily create own branches and Co. Is there some official git repository to clone from? I looked up the archives and seen that creating own clones of the SVN via git svn is not

Hi, I want to use llvm::Value::print to output the assembly strings for llvm::Instructions inside a rather large llvm::Module (linked module with lots of types/...). I started with plain ::print and switched over to http://llvm.org/docs/doxygen/html/classllvm_1_1Value.html#a04e6fc765eeb0c4c90ac5d55113db116 with a ModuleSlotTracker I pass in myself to avoid some complexity. Still now I have

Dear Thomas, > Hi Christoph, > > maybe there is a way of caching the print outputs and output them at the > end of the program execution? > So, your real application do not have this kind of bottle neck. this is a valid idea, thought the problem is: I output all things only "once" and I even output it like: 1) load module 2) go over functions 3) output all blocks with

Hi, > Hi Alexandre, > > LLVM currently doesn't have trunc nsw/nuw, no. > Which frontend would emit such instructions? Any application in mind? > Just asking because if no frontend could emit those, then the motivation to > add nsw/nuw support to trunc would be very low I guess. I think the clang frontend could use that to allow better static analysis of integer overflows on

It's not *very* easy to do, but if you were to pull in the new branch, and then rebase the old branches onto the proper revisions of the new one, you *could* keep your branches. Also, any idea what is *very* soon? Are we talking this month, or maybe this year? Indy On Wed, Aug 18, 2010 at 3:52 AM, Christoph Cullmann <cullmann at absint.de> wrote: > On Wednesday, August 18, 2010

Hello > Is there some official git repository to clone from? Not yet, but probably there will be something pretty soon. Right now there are some unofficial mirrors at repo.or.cz and github -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello, >From [1], trunc does not seems to have a nsw/nuw attribute. Is it possible to have that? Or do we have that and it is not up-to-date? The definition would be: If the nuw keyword is present, the result value of the trunc is a poison value if the truncated high order bits are non-zero. If the nsw keyword is present, the result value of the trunc is a poison value if the truncated high

Dear testers, 5.0.0-rc3 was just tagged. This is a release candidate in the real sense: if nothing bad comes up in testing, this is what the release is going to look like. Please build, test and upload binaries to the sftp (use the /data/testers-uploads/ directory) and let me know what issues remain. I know we're a little bit behind schedule, but hopefully we can get to 'final'

Hello, at our company we are using Samba 4.3.2 in conjunction with Windows 7. We use the Windows 7 machines for our nightly compiles. However, occasionally the schedules compiles stop with a Windows network error message, such as: . . . [ 16%] Generating ui/moc_versiondialog.cxx [ 16%] NMAKE : fatal error U1077: 'R:\usr\20091022\121890\release\win\bin\cmake.exe' : return code

Dear all, I've got a list L <- list(L1 = list (foo = "bar" , SL = NULL ) , L2 = list ( foo = "bar" , SL = list (SSL1 = list (DF = data.frame(val = 21, foo = "bar") , DFOO = list(foo = "foo", bar = "bar") ) ,

On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 07/04/2017 01:41 AM, Dr.-Ing. Christoph Cullmann via llvm-dev wrote: > >> Hi, >> >> Hi Alexandre, >>> >>> LLVM currently doesn't have trunc nsw/nuw, no. >>> Which frontend would emit such instructions? Any application in mind?

On 07/05/2017 03:10 PM, Alexandre Isoard wrote: > Ah, ok. I read it wrong. In *neither* case it is UB. > > Hum, can an implementation define it as UB? :-) Nope :-) The only case I've thought of where we could add these for C++ would be on conversions to (most) enums (because they used signed underlying types and the out-of-bounds mapping won't generally be one of the allowed

Hi Jan, I asked almost the exact same question as you about 6 months ago and someone provided some Gen4 results for me (But I can''t seem to find them in email), they were a fair bit better than Gen3. With IPOIB, you want connected mode and a large 32Kb+ MTU for max bandwidth, 1Gbyte/sec or more should be possible with Gen 4. Here are some of my original test results on my Opteron

According to 6.3.1.3/3 of the C standard (I didn't check C++): "3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised." I *think* that means that IF a signal is raised then the signal raised could be one that you can't guarantee to be able to return from

Hi Quentin, thank you for the reply! This clears up a lot of the questions I was having. It seems like we should definitely invest some time in rewriting some of our legalization rules then! I also posted some questions further down below. I would appreciate getting your opinion on them. > Hi Dominik, > > I’ll do a brief reply here and if you want more information we can talk further

Hi, We're working on adding exception handling support for a downstream bare-metal target. I read through the LLVM exception handling docs [1] and went through some patches from other backends to understand what parts we need to implement. We're now at a point were it feels like it should work, but unfortunately exceptions are still not getting caught. Our target uses DWARF

Hi all, After a recent upstream merge into our downstream sources we are suddenly encountering the freeze instruction in LLVM IR for div/rem pairs. This seems to be related to [1]. Our downstream target is GlobalISel only and unfortunately GlobalISel doesn't support this instruction yet, so most of our internal test-suite is now breaking due to GlobalISel not being able to translate this

Hi Louis, sorry for bothering you once more about the libcxx test suite! I was wondering whether you could help with some of my problems again. After the recent discussion on the mailing list and your diff, I was able to set up cross-compilation and remote-execution of the libcxx test suite, so thank you for that! We have split up the build of the libraries into different stages, so libcxx,

Hi all, recently when working with GlobalISel we have often encountered cases in the legalizer where instructions could not be narrowed because the narrowing code relies on G_UNMERGE_VALUES and therefore requires the source type to be a multiple of the narrow type. Often times these instructions can be widened without any problem to a fitting type. This has us writing legalization rules like