search for: release_37

...-> llvm.org/release_33 = [up to date] release_34 -> llvm.org/release_34 = [up to date] release_35 -> llvm.org/release_35 = [up to date] release_35 at 215010 -> llvm.org/release_35 at 215010 = [up to date] release_36 -> llvm.org/release_36 = [up to date] release_37 -> llvm.org/release_37 = [up to date] release_38 -> llvm.org/release_38 = [up to date] stable -> llvm.org/stable = [up to date] testing -> llvm.org/testing ``` The release_35 at 215010 looks bogus. Why is it there? If there's no good reason, who has permis...

...nks, Hans On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <dimitry at andric.com> wrote: > Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): > > . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 > tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 > tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 > > I'll investigate, because it would be nice to have those tools. > > -Dimitr...

...3 > = [up to date] release_34 -> llvm.org/release_34 > = [up to date] release_35 -> llvm.org/release_35 > = [up to date] release_35 at 215010 -> llvm.org/release_35 at 215010 > = [up to date] release_36 -> llvm.org/release_36 > = [up to date] release_37 -> llvm.org/release_37 > = [up to date] release_38 -> llvm.org/release_38 > = [up to date] stable -> llvm.org/stable > = [up to date] testing -> llvm.org/testing > ``` > The release_35 at 215010 looks bogus. Why is it there? If there's no go...

Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: > Hm, it does not seem to compile at all here? The build ends with: > > In file included from >

...ug 2015, at 14:09, Dimitry Andric via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): > > . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 > tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 > tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 > > I'll investigate, because it would be nice to have those tools. > > -Dimi...

...c via lldb-dev <lldb-dev at lists.llvm.org> wrote: >>> >>> Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): >>> >>> . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 >>> tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 >>> tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 >>> >>> I'll investigate, because it would be nice to ha...

...p.exe. Sly. On 30.08.2015 06:10, Yaron Keren wrote: > Which mingw distribution exactly do you use? > > 2015-08-30 0:46 GMT+03:00 Slycelote via llvm-dev <llvm-dev at lists.llvm.org>: > >> Hi all, >> >> I'm hitting the same problem as in this[1] thread. I use release_37 >> branch on 64-bit Windows 7. >> The problem is here: >> >> #ifdef __MINGW32__ >> #include <imagehlp.h> >> #else >> #include <dbghelp.h> >> #endif >> >> <skip> >> >> typedef BOOL (WINAPI >> *fpEnumera...

Hi all, I'm hitting the same problem as in this[1] thread. I use release_37 branch on 64-bit Windows 7. The problem is here: #ifdef __MINGW32__ #include <imagehlp.h> #else #include <dbghelp.h> #endif <skip> typedef BOOL (WINAPI *fpEnumerateLoadedModules)(HANDLE,PENUMLOADED_MODULES_CALLBACK64,PVOID); imagehlp.h doesn't define PENUMLOADED_MODULES_...

...lthough the first function to get compiled has GlobalsAA available during GVN, rest of them do not as SLP vectorizer run on that function invalidates GlobalsAA which is a module pass. Is there a way to force re-computation of a particular analysis? As a side note, I didn't have this problem on release_37. Thanks a lot. Regards, - Vaivaswatha On Thu, Dec 3, 2015 at 3:02 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Vaivaswatha, > > GlobalsAA is not an immutable pass because it needs to cache queries to > avoid them being unusably slow. It therefore relies on pass...

Hi, I am using the LLVM release_37 branch and have a strange issue. Please see the two IR outputs I have saved below: https://github.com/dibyendumajumdar/ravi/tree/master/ravi-tests/comp_issue The original.ll is the code I am generating. The aftercompiling.ll is the output from LLVM with opt level 0. The issue is that LLVM is de...

...at 4) uses llvm::IndexedInstrProfReader to read-in the profdata file for the 2nd PGO compile pass This all works well with LLVM 3.7. While testing this with LLVM trunk, I run into a version compatibility problem between different versions of LLVM: I made a local copy of the compiler-rt/lib/profile release_37 version (with a few fixes for MSVC) and so steps 1,2, and 4 use LLVM trunk, but step 2 uses an older version of compiler-rt/lib/profile. Apparently, trunk's llvm-profdata cannot read raw profile data files generated by compiler-rt 3.7. Is this intended? Is llvm-profdata's output also incomp...

Hello everyone, Source, binaries and docs for LLVM 3.7.0-rc2 are now available at http://llvm.org/pre-releases/3.7.0/ Please try them out, run tests, build your favourite projects, and *file bugs* reporting any issues that you find. We are now getting into the part of the release process where it's time to wrap things up, so if you were thinking about doing some tests or getting something

...so we will have to cope with that anyway. All in all, making it the default, at least on the master branch, will expose those kind of problems earlier, so we can fix them before shipping any stable compiler. If, during release 3.7, there are still too many bugs, we can revert the patch on branch release_37, so to have another six months to fix them, and so on. cheers, --renato

...there > > a way to force re-computation of a particular analysis? > > You can specifically insert it into the pass pipeline, but in this case, > we should just fix SLP to preserve the analysis. > > -Hal > > > > > As a side note, I didn't have this problem on release_37. > > > > Thanks a lot. > > > > Regards, > > > > > > > > > > > > - Vaivaswatha > > > > > > On Thu, Dec 3, 2015 at 3:02 PM, James Molloy < > > james at jamesmolloy.co.uk > wrote: > > > > > > &g...

...ed -e 's,Phase2,Phase3,g' $p2) <(sed -e '' $p3) \ 16 16 ; then I think this is the final adjustment I have to make to get the building and testing to complete. Hans, is it OK if I commit these changes to test-release.sh in trunk? Then I'll merge them to release_37 afterwards. -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: use-autoconf-on-freebsd-too-3.diff Type: application/octet-stream Size: 2477 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150719/c85baa5b/attachment...

...e-computation of a particular analysis? >> >> You can specifically insert it into the pass pipeline, but in this case, >> we should just fix SLP to preserve the analysis. >> >> -Hal >> >> > >> > As a side note, I didn't have this problem on release_37. >> > >> > Thanks a lot. >> > >> > Regards, >> > >> > >> > >> > >> > >> > - Vaivaswatha >> > >> > >> > On Thu, Dec 3, 2015 at 3:02 PM, James Molloy < >> > james at jamesm...

Hi Hans, I'm wondering where I should commit 3.7 release notes - I really should add a note about the opaque pointer stuff so people have a bit of an idea of what's going on... - Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/8747b439/attachment.html>

On 31 Jan 2015, at 03:02, Dan Albert <danalbert at google.com> wrote: > > Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. On FreeBSD, we install compiler-rt as libgcc (or, at least, symlink it to libgcc). This means that

...alysis? >>> >>> You can specifically insert it into the pass pipeline, but in this case, >>> we should just fix SLP to preserve the analysis. >>> >>> -Hal >>> >>> > >>> > As a side note, I didn't have this problem on release_37. >>> > >>> > Thanks a lot. >>> > >>> > Regards, >>> > >>> > >>> > >>> > >>> > >>> > - Vaivaswatha >>> > >>> > >>> > On Thu, Dec 3, 2015 at 3:02...

Hi, I've noticed that alias analysis queries arising from GVN do not use the results from GlobalsAA. The last call to AAResultsWrapperPass::runOnFunction() before GVN does not add GlobalsAAWrapperPass due to unavailability. This leads to the alias queries from GVN not having any globals mod-ref info. Is this a known issue? and is there any way to have globals mod-ref info available for GVN?