Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Windows build problems..."
2008 Dec 20
0
[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
2008 Oct 23
4
[LLVMdev] Windows build broken?
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)
2008 Oct 23
0
[LLVMdev] Windows build broken?
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
2008 Dec 05
2
[LLVMdev] Windows build problem...
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:
2008 Dec 17
5
[LLVMdev] Windows build problems
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>
2009 Jan 15
1
[LLVMdev] [cfe-dev] Testing and CMake
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
2009 Jan 15
9
[LLVMdev] win32/llvm.sln, win32/clang.sln
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
2009 Jan 15
0
[LLVMdev] [cfe-dev] Testing and CMake
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
2009 Jan 15
5
[LLVMdev] [cfe-dev] Testing and CMake (was: win32/llvm.sln, win32/clang.sln)
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:
>
2008 Dec 05
0
[LLVMdev] Windows build problem...
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
2008 Dec 17
0
[LLVMdev] Windows build problems
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
2008 Dec 17
1
[LLVMdev] Windows build problems
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
2009 Jan 15
0
[LLVMdev] win32/llvm.sln, win32/clang.sln
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
2009 Feb 02
0
[LLVMdev] [cfe-commits] r63168 - /cfe/trunk/Driver/clang.cpp
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
2009 Jan 08
1
[LLVMdev] Integer typedefs for MSVC
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;
2010 Mar 06
0
[LLVMdev] [PATCH]: MSVC build enhancements
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;
2016 Jan 12
2
Re: Note regarding bin2s.pl
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
2018 Aug 06
2
Lowering ISD::TRUNCATE
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:
2010 Mar 06
6
[LLVMdev] [PATCH]: MSVC build enhancements
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:
2009 Jan 20
4
[LLVMdev] cygwin build patch
>> 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