similar to: [LLVMdev] Windows build problems...

On Dec 19, 2008, at 4:00 PM, steve naroff wrote: > Folks, > > I'm having a bizarre build failure on Windows (having to do with > basic types such as uint8_t, uint32_t). > > I've done a clean build and it doesn't seem to fix the problem (I > made sure DataTypes.h was removed and regenerated). > > I searched through the recent llvm commits and can't

Folks, It appears the Windows build has regressed over the past week. The build fails quite early (during the "Performing TableGenStep" phase). Any help/pointers would be appreciated. Thanks, snaroff (a clang developer)

steve naroff <snaroff at apple.com> writes: > Folks, > > It appears the Windows build has regressed over the past week. > > The build fails quite early (during the "Performing TableGenStep" > phase). > > Any help/pointers would be appreciated. It breaks for me because the usage of INT64_C, which was introduced on r57663 and 57668. Some googling around

I'm seeing the following build problem on Windows. I'm using cmake, but haven't verified "it" is the problem. Is anyone else seeing this problem? Any help would be appreciated. Thanks, snaroff -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 21.png Type: image/png Size: 24840 bytes Desc: not available URL:

Folks, Is anyone else the failure below? On Mac OS X everything builds properly... Thanks for any help, snaroff -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 27.png Type: image/png Size: 18959 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081217/e7d37fee/attachment.png>

On Jan 15, 2009, at 11:40 AM, Óscar Fuentes wrote: > Hello Steve. > > steve naroff <snaroff at apple.com> writes: > >> For development, CMake is working great for me. I rarely get build >> errors related to the project file being out-of-date. >> >> Is it true that CMake only generates absolute paths? Any idea on the >> difficulty of generating

Folks, Is anyone still using the Visual Studio solution files in the win32 directory? If they aren't being maintained, they should probably be removed (to avoid any confusion). Thanks for any feedback, snaroff

Hello Steve. steve naroff <snaroff at apple.com> writes: > For development, CMake is working great for me. I rarely get build > errors related to the project file being out-of-date. > > Is it true that CMake only generates absolute paths? Any idea on the > difficulty of generating relative paths? I consider this a pretty big > obstacle... Well, the fact that you

Hi Oscar, For development, CMake is working great for me. I rarely get build errors related to the project file being out-of-date. Is it true that CMake only generates absolute paths? Any idea on the difficulty of generating relative paths? I consider this a pretty big obstacle... Thanks for all your hard work on this, snaroff On Jan 15, 2009, at 9:46 AM, Óscar Fuentes wrote: >

steve naroff <snaroff at apple.com> writes: > I'm seeing the following build problem on Windows. I'm using cmake, > but haven't verified "it" is the problem. > > Is anyone else seeing this problem? > > Any help would be appreciated. Thanks, Those are the same errors reported by OvermindDL1 a few hours ago on this mailing list. I don't think

Got it. On Mac OS, the build process update the llvmAsmParser.cpp.cvs file, and then generate llvmAsmParser.cpp from the .cvs file. But on Window, it does not update the .cvs files (probably because bison is missing), and so, the llvmAsmParser.cpp is not in sync with the .y file. As the Mac OS build process update the cvs files, commiting them after building on OS X should be enough to

Sounds like this has to do with Bill backing out r61019, r61030, and r61040. I think 61031 (which update llvmAsmParser.cpp.cvs, etc.) should be backed out as well. Can someone do that? Evan On Dec 17, 2008, at 7:20 AM, Jean-Daniel Dupas wrote: > Got it. > > On Mac OS, the build process update the llvmAsmParser.cpp.cvs file, > and then generate llvmAsmParser.cpp from the .cvs

Hi Steve, The Visual Studio solution and project files are quite handy. CMake creates absolute paths instead of relative paths, making it cumbersome to move things around. Also, for newcomers (e.g. students) it's really great to be able to download the package, open the solution and compile without any complication. They haven't been updated in a while, but it would be nice to have

Hi Piortr, This also breaks the hand-built VC++ project. Any clues on where I should define this? Thanks, snaroff -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 7.png Type: image/png Size: 13645 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090202/eb726ff5/attachment.png> -------------- next part

LLVM's typedefs for int32_t etc. under MSVC (in Support/DataTypes.h) conflict with those used by other third-party libraries. Instead of these: #ifdef _MSC_VER typedef __int64 int64_t; typedef unsigned __int64 uint64_t; typedef signed int int32_t; typedef unsigned int uint32_t; typedef short int16_t; typedef unsigned short uint16_t; typedef signed char int8_t; typedef unsigned char uint8_t;

To the mailing list this time... On Sat, Mar 6, 2010 at 4:26 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Sat, Mar 6, 2010 at 4:19 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote: >>>> --- a/include/llvm/System/DataTypes.h.cmake >>>> +++ b/include/llvm/System/DataTypes.h.cmake >>>> @@ -100,6 +100,9 @@ typedef u_int64_t uint64_t;

On 12.01.2016 12:10, Richard W.M. Jones wrote: > On Tue, Jan 12, 2016 at 10:05:00AM +0000, Richard W.M. Jones wrote: >> On Tue, Jan 12, 2016 at 07:57:03AM +0100, Hilko Bengen wrote: >>> Helge, >>> >>> I have applied all the architecture-specific bits but not the bin2s >>> script yet. TBH, so far I don't see what is wrong about export and use

I'm working on defining the instructions and implementing the lowering code for a Z80 backend. For now, the backend supports only the native CPU-supported datatypes, which are 8 and 16 bits wide (i.e. no 32 bit long, float, ... yet). So far, a lot of the simple stuff like immediate loads and return values is very straightforward, but now I got stuck with ISD::TRUNCATE, as in:

Attached are two patches with MSVC build enchancements. They are quite trivial, but were necessary to correctly link LLVM libraries with Mesa3D on Windows. Jose -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-to-build-against-static-MSVC-runtime.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL:

>> I realise that the DataTypes.h.in part might be controversial. Also, >> there's probably a better place to put it, but I'm not sure where. > > I didn't apply this part. What problems does it cause to not have > this? Can we fix uses of max and min? I get these errors in lib: .../lib/Analysis/ValueTracking.cpp:162: error: no matching function for call to