LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 1929 - APInt.h:216: error: expected ‘,’ or ‘...’ before numeric constant
Summary: APInt.h:216: error: expected ‘,’ or ‘...’ before numeric constant
Status: RESOLVED FIXED
Alias: None
Product: new-bugs
Classification: Unclassified
Component: new bugs (show other bugs)
Version: unspecified
Hardware: PC Linux
: P normal
Assignee: Ted Kremenek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-19 07:41 PST by Török Edwin
Modified: 2018-11-07 00:22 PST (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments
preprocessed source, before updating from SVN (911.72 KB, text/plain)
2008-01-19 11:31 PST, Török Edwin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Török Edwin 2008-01-19 07:41:46 PST
Build fails for svn r46191.

make[2]: Entering directory `/home/edwin/llvm-svn/llvm/utils/TableGen'
llvm[2]: Compiling FileParser.cpp for Release build
In file included from /home/edwin/llvm-svn/llvm/include/llvm/ADT/APFloat.h:105,
                 from /home/edwin/llvm-svn/llvm/include/llvm/ADT/StringExtras.h:19,
                 from /home/edwin/llvm-svn/llvm/utils/TableGen/FileParser.y:17:
/home/edwin/llvm-svn/llvm/include/llvm/ADT/APInt.h:216: error: expected ‘,’ or ‘...’ before numeric constant
make[2]: *** [/home/edwin/llvm-svn/llvm/utils/TableGen/Release/FileParser.o] Error 1
make[2]: Leaving directory `/home/edwin/llvm-svn/llvm/utils/TableGen'
make[1]: *** [TableGen/.makeall] Error 2
make[1]: Leaving directory `/home/edwin/llvm-svn/llvm/utils'
make: *** [all] Error 1

That line contains: 
  /// Profile - Used to insert APInt objects, or objects that contain APInt 
  ///  objects, into FoldingSets.
  void Profile(FoldingSetNodeID& ID) const;
Comment 1 Török Edwin 2008-01-19 07:43:08 PST
Environment:

$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-libmudflap --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 20080114 (prerelease) (Debian 4.2.2-7)

$ uname -a
Linux lightspeed2 2.6.24-rc8-g8b2d1833-dirty #4 Sat Jan 19 13:33:53 EET 2008 x86_64 GNU/Linux
Comment 2 Ted Kremenek 2008-01-19 11:27:41 PST
This looks like a potential macro conflict in preprocessed source for FileParser.cpp.  I have committed r46193 which provides a hack to hopefully fix this problem ('ID' is renamed to 'id'):

http://llvm.org/viewvc/llvm-project?rev=46193&view=rev

Edwin: Can you confirm that this fixes the problem?   Also, what would be helpful is if you could attach the preprocessed source for FileParser.cpp.  Having a name conflict on something like the word 'ID' seems like badness to me, making believe that the root cause of this problem is elsewhere.
Comment 3 Török Edwin 2008-01-19 11:31:25 PST
Created attachment 1344 [details]
preprocessed source, before updating from SVN

This is the preprocessed source, I see no conflicts on ID...
Comment 4 Török Edwin 2008-01-19 11:32:11 PST
(In reply to comment #3)
> Created an attachment (id=1344) [details]
> preprocessed source, before updating from SVN
> 
> This is the preprocessed source, I see no conflicts on ID...
> 

Ehrm, I was wrong, ID got expanded to 278.
Comment 5 Ted Kremenek 2008-01-19 11:37:46 PST
Thanks.  It looks like ID is an enum value in the generated output of bison.  Does the build work for you now?
Comment 6 Török Edwin 2008-01-19 11:39:27 PST
(In reply to comment #5)
> Thanks.  It looks like ID is an enum value in the generated output of bison. 
> Does the build work for you now?
> 

Yes, utils/TableGen builds now. The rest is still compiling, but I suppose those will be ok too.
Thanks.