similar to: llvm-pdbdump proposal

On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscall calling convention to methods by > default. > > I think the last bug blocking us to support the new abi has just been > fixed.

Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what

On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: > It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ > Does this patch fix any failures for you? It doesn't fix that test case, unfortunately.

On Monday 15 March 2010 13:45:14 David Greene wrote: > On Sunday 14 March 2010 18:32:35 Chris Lattner wrote: > > This is much better than the first iteration but still has many issues. I believe I've addressed all your points with this patch except I didn't use StringRef. It doesn't appear to be useful since createPrinterPass will be sent a const std::string & and will

On Mar 17, 2010, at 11:25 AM, David Greene wrote: > On Monday 15 March 2010 13:45:14 David Greene wrote: >> On Sunday 14 March 2010 18:32:35 Chris Lattner wrote: >>> This is much better than the first iteration but still has many issues. > > I believe I've addressed all your points with this patch except I didn't use > StringRef. It doesn't appear to be

Ok just tried on Win 7 and the same problem occurs. I am building with : cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_CRT_RELEASE=MT -DLLVM_ENABLE_TIMESTAMPS=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON -DLLVM_TARGETS_TO_BUILD="ARM;X86" -DPYTHON_EXECUTABLE=$python_exe -DLLVM_BUILD_TESTS=ON -DLLVM_LIT_TOOLS_DIR=C:/cygwin64/bin fwiw compiler-rt is

I think we need to relax the test cases. MSVC usually prints the calling convention, and it's often useful information. Maybe we can make the diagnostic text smaller by using the __thiscall, __cdecl, __stdcall, etc keywords when printing types with LangOpts.MicrosoftExt, but it will require moving the attribute from after the identifier to before, which is exciting. On Tue, Dec 10, 2013 at

FWIW, this test is passing for me on Windows 7 with Visual Studio 2015 (debug build). 59> Running all regression tests 59> -- Testing: 23734 tests, 32 threads -- 59> 59> Testing Time: 634.19s 59> Expected Passes : 22821 59> Expected Failures : 160 59> Unsupported Tests : 753 59> lit.py: lit.cfg:195: note: using clang:

> There are a handful other tests failing in the same way. > > It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ They are all TypePrinter failures like this one? If so I would say we should not block on it since it is a small

Hi, This might be interesting since it seems to be the only LLVM test failing with VS 2015: FAIL: LLVM :: DebugInfo/PDB/pdbdump-symbol-format.test (7377 of 14212) ******************** TEST 'LLVM :: DebugInfo/PDB/pdbdump-symbol-format.test' FAILED ******************** Script: -- llvm-pdbdump -symbols C:\cygwin64\home\ismail\src\llvm\test\DebugInfo\PDB/Inputs/symbolformat.pdb |

On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: >> >> It would be nice if we could make the TypePrinter not print the >> calling convention if it's the default one for the ABI, but >> TypePrinter doesn't have a lot of context.. no Sema, no

On Tue, Dec 10, 2013 at 4:39 PM, Reid Kleckner <rnk at google.com> wrote: > I think we need to relax the test cases. MSVC usually prints the calling > convention, and it's often useful information. I was going to argue that MSVC doesn't print them, but then I tried, and you're right - it does :) I'll start relaxing the tests then. > Maybe we can make the

On Friday 12 March 2010 08:13:05 Kalle Raiskila wrote: > David Greene wrote: > > Here's a rework using PassManager as Chris suggested. Comments? > > Tried this second patch with the svn version 97812 (the one the patch is > made against), but it doesn't compile: > "llvm/include/llvm/Pass.h:127: Error: expected unqualified-id before "&" >

David Greene wrote: > Here's a rework using PassManager as Chris suggested. Comments? Tried this second patch with the svn version 97812 (the one the patch is made against), but it doesn't compile: "llvm/include/llvm/Pass.h:127: Error: expected unqualified-id before "&" token" Seems raw_ostream is forward declared but not defined (adding a missing #include

On Mar 12, 2010, at 8:10 AM, David Greene wrote: > On Friday 12 March 2010 08:13:05 Kalle Raiskila wrote: >> David Greene wrote: >>> Here's a rework using PassManager as Chris suggested. Comments? >> >> Tried this second patch with the svn version 97812 (the one the patch is >> made against), but it doesn't compile: >>

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. > >

Hello, We would like to propose a way for improving the diagnostics for address_space by being able to pass strings as an argument to it instead of just an integer. This was initially proposed before (http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html) but did not focus on it at the time. Reasoning: Clang's __attribute__((address_space(...))) feature uses an arbitrary integer as

On Friday 26 March 2010 18:19:07 Chris Lattner wrote: > > Any additional feedback from anyone? > > This is looking much better, thanks. I'd still prefer using StringRef > instead of std::string here because it cleans up the interface, but I won't > insist. Wouldn't using StringRef actually cause more constructors to be invoked to manage the type conversions? The

Hi Zach (or anyone else who may have a clue), I'm currently investigating making use of LLVM for PDB parsing for with a view to supporting partial PDBs as produced by /DEBUG:FASTLINK as the VS DIA SDK hasn't been updated to handle them. I know this is probably low on your priority list but since /DEBUG:FASTLINK is now the implied default for VS2017 I figure it's a good time to take a

Ah, I see this was addressed in 250386 - though might be nice to address across the whole project rather than this particular inclusion. Though maybe we've few enough inclusions that it's not too bad. On Fri, Oct 16, 2015 at 2:51 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Oct 15, 2015 at 2:17 AM, David Majnemer via llvm-commits < > llvm-commits at