similar to: [LLVMdev] Utilizing gperf for TableGen

On Jan 1, 2008, at 1:51 AM, Wilhansen Li wrote: > The output of TableGen (intrinsics.gen) seems a bit too clunky > specifically the switching parts (input the string, output the enum). > Moreover, the code makes MSVC barf due to its nesting limit which even > applices to if-else statements. Right, fixing the VC++ issue is straight-forward. I will do it in the next couple of days

FYI, gperf is a very good perfect hash utility written originally by Doug Schmidt (of ACE fame). I used it in XPS for speeding up XML parsing by hashing all the element and attribute names. Unfortunately, its a code generator, which we're trying to get rid of in LLVM. Still, I recommend the tool highly. Reid. On Tue, 1 Jan 2008 13:04:57 -0800 Chris Lattner <sabre at nondot.org>

On Tue, 1 Jan 2008, Wilhansen Li wrote: > The output of TableGen (intrinsics.gen) seems a bit too clunky > specifically the switching parts (input the string, output the enum). > Moreover, the code makes MSVC barf due to its nesting limit which even > applices to if-else statements. This should be fixed now, please verify, thanks! -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Wed, 2 Jan 2008, Chris Lattner wrote: >This should be fixed now, please verify, thanks! > >-Chris The newer code that TableGen produces is indeed lower however, MSVC still throws the same error messages (and moreover, I don't think they're fixing it anytime soon.. I'll try to re-open this issue to them). Also, it seems that the new code produces an extraneous "if

---------- Forwarded message ---------- From: Wilhansen Li <krad at crammerz-inc.net> Date: Jan 4, 2008 6:18 PM Subject: Re: [LLVMdev] Utilizing gperf for TableGen To: Chris Lattner <sabre at nondot.org> It finally compiles well with MSVC. Thanks! On 1/4/08, Chris Lattner <sabre at nondot.org> wrote: > > > Alright, try this: >

Hello, > One one hand, gperf > (http://www.gnu.org/software/gperf/manual/gperf.html) offers a way to > map strings to records without much difficulty (and it does its job > efficiently). > > My point is, are there plans to utilize gperf for table generation? I'm aware about gperf. However we're planning to utilize some another approach based on tries. The idea behind

This patch lets guestfish show command synopsis if the syntax of command issued by user is wrong, rather than telling user that the number of parameters is wrong. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> --- changes in v2: - fix the error of ' error: control reaches end of non-void function [-Werror=return-type]' - change the return value from -2 to -1 fish/cmds-gperf.h |

On Oct 11, 2011, at 2:03 PM, David Blaikie wrote: > I'd assume something like: > > for (x, y) = [(1, 4), (2, 5), (3, 6)] in { ... } > > Though I don't know a great deal about tablegen syntax. But so long as the lists are separate it seems it'd always be unclear that it was a zip. +1 Nobody actually needs the zip functionality anyway. /jakob -------------- next

On Oct 11, 2011, at 1:07 PM, Jim Grosbach wrote: > Perhaps a minor note, but can I'd prefer we call them something other than a "for loop." That implies a more procedural nature than is natural for the language. TableGen is far more declarative that procedural. Even something simple like using a "for each" type syntax and refering to the construct as a "for each

Prune from the list of sources where to extract messages various sources with no messages: - .pl and .pm files, as they do not contain messages: almost all the .pl files are tests, and the only .pm file is the Perl Sys::Guestfs module, which wraps the XS extension - dummy.c sources; they are empty sources used to build OCaml-only targets using automake - gperf generated sources - C/OCaml

Hi folks, I have been stumped on a compilation problem when I tried to build 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since the default C standard of Clang is c99 while that of gcc is c89. It reported this error: ./c-gperf.h:14:1: error: unknown type name 'inline' inline ^

When running (eg) dnf on a 32 bit i686 guest when the host is 64 bit x86_64, dnf believes it is running on a 64 bit machine and so tries to install x86_64 packages. We can 'trick' dnf into believing it's a 32 bit machine using the setarch program. $ virt-builder fedora-22 --arch i686 --install 'gperf' ... [ 27.4] Installing packages: gperf ... Running transaction test Error:

As an update to this: http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's nice to know. The workaround involves marking a single function with attribute((noinline)) and is

On Wed Jan 15, 2020 at 6:58 PM, Reid Kleckner wrote: > Does the same limitation exist in VS 2017? I think that's our support > floor > these days: > https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library > It appears that all releases including the latest 2019 are affected. > > One *could* make the tablegen behavior conditional on the

On 04/12/2012 06:29, Michael Spencer wrote: > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: >> As an update to this: >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 >> >> Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release.

On 01/18/2011 06:38 PM, Bin Zeng wrote: > Hi folks, > > I have been stumped on a compilation problem when I tried to build > 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. > First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since > the default C standard of Clang is c99 while that of gcc is c89. It > reported this error: >

> On Behalf Of Nicholas Chapman > > On 04/12/2012 06:29, Michael Spencer wrote: > > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> > wrote: > >> As an update to this: > >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl- > >> exe-ice-when-building-llvm-trunk-at-o2 > >> > >> Microsoft

On Wed, 15 Jan 2020, Reid Kleckner via llvm-dev wrote: > On Wed, Jan 15, 2020 at 11:14 AM Luke Drummond <luke.drummond at codeplay.com> > wrote: > On Wed Jan 15, 2020 at 6:58 PM, Reid Kleckner wrote: > > Does the same limitation exist in VS 2017? I think that's our > support > > floor > > these days: >

On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: > As an update to this: > http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 > > Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's

On Tue Jan 14, 2020 at 8:27 PM, Reid Kleckner wrote: > I don't think there's any technical reason for the current structure. Apparently [this](https://docs.microsoft.com/en-us/cpp/cpp/compiler-limits?view=vs-2019) is a thing. This results in the following delight happening on Visual Studio 2015: > fatal error C1091: compiler limit: string exceeds 65535 bytes in length So maybe