similar to: Windows /bigobj

> -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On > Behalf Of Aaron Ballman > Sent: Monday, September 29, 2014 4:45 PM > To: Chris Bieneman > Cc: lldb-dev at cs.uiuc.edu; cfe-dev Developers; LLVM Developers Mailing List > Subject: Re: [cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC > version to 2013

Hi Galina, I am working on getting a new Windows bot up and running. Would you please review and apply the attached patch when you have a moment. Thanks, Mike Edwards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/70f2ab88/attachment.html> -------------- next part -------------- Index:

A test I added in r317607 is passing almost everywhere, except for llvm-clang-x86_64-expensive-checks-win. Other Windows bots are happy. http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6013 The test runs 'sed' on a file to generate variations of the input assembler source for Linux and Darwin. I have to say it looks like 'sed' is being the

On Tue, 29 Jan 2019 at 21:05, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch. > > The last remaining issue are the buildbots. I audited *all* bots in

I’ve had another look, and some of the failing tests don’t use temporary files, so I don’t think this is a case of tests having side-effects. Instead, I’ve noticed that in the build log (http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6552/steps/build-unified-tree/logs/stdio), llvm-tblgen.exe is built (my patch modified it), but the table-generation steps of the

No, we use msvc cl.exe as a compiler generating C7 debug information (here is more or less our compiler options regarding optimization/debugability): /Z7 /GL- /bigobj /Zo /utf-8 /arch:AVX /std:c++14 /Zc:inline /Zc:ternary /Zc:rvalueCast /Zc:strictStrings /O2 /MD In this list the only weird one is /bigobj, my main fear is that we might get to the limit of sections on an obj and then by adding the

Hello, After switching from a Linux development host to Windows7 with Cygwin, I notice the following problem when building clang (trunk, HEAD): (also happens with Mingw) ... llvm[4]: Compiling ParseInit.cpp for Debug+Asserts build as: /cygdrive/d/Projects/Cpp/llvm/cfgCygwin/tools/clang/lib/AST/Debug+Asserts/ASTContext.o: too many sections (33066) /tmp/ccmtDH7w.s: Assembler messages:

After a few attempts I think we’re in sight of success: we only have the two following bots remaining with old versions of libstdc++ and new versions of clang: polly-amd64-linux polly-arm-linux Once fixed the toolchain bump should stick. > On Jan 31, 2019, at 2:07 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Jan 31, 2019, at 2:03 PM,

On 5/2/2014 11:41 PM, David Blaikie wrote: > Any idea what all those sections are - comdat inline functions? > No idea, as I cannot run objdump -h on a object file that I couldn't build :) Anyhow, I have an old, successful Debug+Asserts build of clang, made with Mingw also, for clang revision 206070. Apparently, the ASTContext.o file there contained 16453 sections, not 33066, as

+1, thanks again for driving this. On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The discussion seems to have died down and gotten good consensus. I’ve > therefore create a patch which applies the proposed soft-errors: > > https://reviews.llvm.org/D57264 > > > We’ll only migrate to hard-error (and start using new

Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to 2013. The motivating reason is this will allow us to take advantage of a bunch of C++11 features that are not supported by MSVC 2012. According to MSDN (http://msdn.microsoft.com/en-us/library/hh567368.aspx) the list is:

Dear testers, The final version of 7.0.0 has been tagged from the branch at r342370. It is identical to rc3 modulo release notes and docs changes. Please build the final binaries and upload to the sftp. For those following along: this means 7.0.0 is done, but it will take a few days to get all the tarballs ready and published on the web page. I will send the announcement once everything is

Indeed this has finally stuck, with just clang-with-lto-ubuntu broken at the moment. I’m inclined to leave it checked in, and try to get it into the LLVM 8 branch as well. > On Feb 7, 2019, at 9:18 AM, paul.robinson at sony.com wrote: > > It seems the CMake changes have landed; but the docs are still a bit out of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not

Should "lit :: shtest-format.py" (from check-lit) be marked unsupported on PS4? It seems flakey there. This evening, it failed on my commit, r337514, and I'm fairly confident it wasn't my commit's fault. Then it recovered on the next commit. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/33502

FWIW, I've seen it fail on some of my commits too, but I don't remember whether it was on the PS4 bot exclusively or not. Anyway, my understanding is that this test shouldn't inherently have different behaviour on PS4 specifically, but I could be mistaken. I suspect it's something more general to do with the configuration of the bot. James On 20 July 2018 at 03:52, Justin Bogner

I have the following statement cl = ChatEvent.find_all("ev_type <> #{t} and chat_id = #{@params [:chat_id]} order by created_at") which produces the following error: #42000You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''order by created_at)'' at line 1: SELECT * FROM

Hi, We are starting to test binaries generated by lld on windows and we notices that sometimes the visual studio debugger can't see the content of variables or gets the call stack wrong for deeply nested or complex types. Did anyone else have the same problems, or any way to try to figure out what is missing? I tried llvm-pdbutil dump -symbols but there is a lot of small diferences on

As I've left Sony, I should handoff code ownership of the PS4 triple. Sony is still committed to LLVM and I look forward to continue to work with them in open source. Sony has asked that I nominate Paul Robinson to become code owner. +------------------------------------------------------------+ | Alexander M. Rosenberg <mailto:alexr at leftfield.org> | | Nobody cares what I

Thanks! On Mon, Jan 27, 2020 at 6:05 PM Teresa Johnson <tejohnson at google.com> wrote: > By default even regular LTO now has module summaries (like the kind used > for ThinLTO). LTO will then run index based dead symbol analysis here: > http://llvm-cs.pcc.me.uk/lib/LTO/LTO.cpp#923. Then when linkRegularLTO is > called here: http://llvm-cs.pcc.me.uk/lib/LTO/LTO.cpp#935, it

I''ve been using Rails for more than six months and until today I had no problem with mysql connection. It''s a Mac OS X 10.4 box having rails installed and updated by gem. I use a remote mysql server no local instance installed. Here''s my config: development: adapter: mysql database: hdchat host: 10.0.0.1 username: webuser password: test: adapter: