Displaying 20 results from an estimated 26 matches for "cstdint".
Did you mean:
stdint
2016 Jan 30
2
[llvm] r259255 - Need #include <cstdint> for uint64_t
Oh I did not know about DataTypes.h. However given that there are already two other files in llvm (in the AMDGPU and Hexagon targets) that #include <cstdint> since 2014, maybe we can loosen the requirement for DataTypes.h nowadays as #include <cstdint> seems to be working everywhere?
- Matthias
> On Jan 29, 2016, at 3:06 PM, Craig Topper <craig.topper at gmail.com> wrote:
>
> I think you may really want include/llvm/Support/D...
2009 May 12
1
[LLVMdev] MSVC cstdint
In the llvm file include/llvm/Support/DataTypes.h (.in/.cmake), for
MSVCit defines some macros that are defined in the cstdint.hpp file in
boost (and boost does it better, detailed below):
The basic error is:
R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(347) :
warning C4005: 'INT8_C' : macro redefinition
R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(116)
: see previous d...
2016 Jan 30
2
[llvm] r259255 - Need #include <cstdint> for uint64_t
...other things. And it guarantees that the entire compiler uses
> the SAME definition, rather than, potentially, using different variants of
> the "same" type in different places.
>
> I'd argue the other way around, that you probably should fix the other
> bits that use `cstdint` to use `DataTypes.h`.
>
> --
> Mats
>
> On 30 January 2016 at 00:33, Matthias Braun via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> Oh I did not know about DataTypes.h. However given that there are already
>> two other files in llvm (in the A...
2016 Jan 30
1
[llvm] r259255 - Need #include <cstdint> for uint64_t
...tthias Braun via llvm-commits <
llvm-commits at lists.llvm.org> wrote:
> The point I was trying to make here is that all things that DataTypes.h
> provides:
> intXXX_t, uintXX_t, PRIdXX, INT64_MAX, HUGE_VAL, ssize_t ...
> are all part of the C++11 standard and can be found in <cstdint>, <cmath>
> (except for ssize_t) so I wondered if there is still a need for llvm to
> provide this header since we require a C++11 compiler anyway nowadays.
>
FWIW, I've thought about this too. cstdint and stdint.h are C++11, and I
think that MSVC claims to support them. Mayb...
2009 Dec 07
2
[LLVMdev] Macro redefinitions
...DataTypes.h starting on line 121 are these lines:
#define INT8_C(C) C
#define UINT8_C(C) C
#define INT16_C(C) C
#define UINT16_C(C) C
#define INT32_C(C) C
#define UINT32_C(C) C ## U
#define INT64_C(C) ((int64_t) C ## LL)
#define UINT64_C(C) ((uint64_t) C ## ULL)
They are conflicting with the cstdint when we have updated headers in
our MSVC build. I could have sworn I talked about this before along
with a patch, guess no one ever fixed it, hence consider this a poke.
The above lines should be changed into:
#ifndef INT8_C
# define INT8_C(C) C
#endif
#ifndef UINT8_C
# define UINT8_C(C) C
#e...
2017 Mar 08
3
Use of the C++ standard library in XRay compiler-rt
...t; f|grep -v 'tests'` | sort | uniq -c
> 1 #include <algorithm>
> 10 #include <atomic>
> 1 #include <bitset>
> 6 #include <cassert>
> 1 #include <cerrno>
> 1 #include <cstddef>
> 7 #include <cstdint>
> 2 #include <cstdio>
> 1 #include <cstdlib>
> 2 #include <cstring>
> 1 #include <deque>
> 2 #include <iterator>
> 2 #include <limits>
> 2 #include <memory>
> 4 #include <mutex&g...
2017 Mar 08
2
Use of the C++ standard library in XRay compiler-rt
So I stumbled across an issue that I think is a bit fundamental:
The xray runtime uses the C++ standard library.
This seems like a problem because whatever C++ standard library is used to
compile the XRay runtime may not be the same as the C++ standard library
(if any) that is used to build the target application and link XRay into.
Does this make sense? Is this a problem?
Talking to Chandler
2017 Jun 11
2
Force casting a Value*
On 11 June 2017 at 07:53, David Blaikie <dblaikie at gmail.com> wrote:
> Sounds like you're looking for reinterpret_cast: http://en.
> cppreference.com/w/cpp/language/reinterpret_cast
>
I tried cast<ConstInt>(vo), but that failed at run-time.
>
> On Sun, Jun 11, 2017 at 3:06 AM Dipanjan Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
2018 Aug 03
10
[7.0.0 Release] rc1 has been tagged
Dear testers,
7.0.0-rc1 was just tagged (from the branch at r338847).
It's early in the release process, but I'd like to find out what the
status is of the branch on our various platforms.
Please run the test script, share the results, and upload binaries.
Thanks,
Hans
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;
2013 Oct 31
3
[LLVMdev] loop vectorizer misses opportunity, exploit
...will vectorize the unrolled iterations, or the loop-vectorizer would catch it.
Thanks,
Nadav
On Oct 31, 2013, at 8:01 AM, Frank Winter <fwinter at jlab.org> wrote:
> A quite small but yet complete example function which all vectorization passes fail to optimize:
>
> #include <cstdint>
> #include <iostream>
>
> void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b)
> {
> for ( std::uint64_t i = start ; i < end ; i += 4 ) {
> {
> const std::uint64_t ir0 = (i+0)%4 + 8*(...
2013 Oct 31
0
[LLVMdev] loop vectorizer misses opportunity, exploit
A quite small but yet complete example function which all vectorization
passes fail to optimize:
#include <cstdint>
#include <iostream>
void bar(std::uint64_t start, std::uint64_t end, float * __restrict__
c, float * __restrict__ a, float * __restrict__ b)
{
for ( std::uint64_t i = start ; i < end ; i += 4 ) {
{
const std::uint64_t ir0 = (i+0)%4 + 8*((i+0)/4);
c[ ir0 ]...
2017 Mar 13
5
Use of the C++ standard library in XRay compiler-rt
...t | uniq -c
> > 1 #include <algorithm>
> > 10 #include <atomic>
> > 1 #include <bitset>
> > 6 #include <cassert>
> > 1 #include <cerrno>
> > 1 #include <cstddef>
> > 7 #include <cstdint>
> > 2 #include <cstdio>
> > 1 #include <cstdlib>
> > 2 #include <cstring>
> > 1 #include <deque>
> > 2 #include <iterator>
> > 2 #include <limits>
> > 2 #include <memory>...
2013 Oct 31
3
[LLVMdev] loop vectorizer misses opportunity, exploit
...ld catch it.
>
>
> Thanks,
> Nadav
>
>
> On Oct 31, 2013, at 8:01 AM, Frank Winter < fwinter at jlab.org > wrote:
>
>
>
>
> A quite small but yet complete example function which all
> vectorization passes fail to optimize:
>
> #include <cstdint>
> #include <iostream>
>
> void bar(std::uint64_t start, std::uint64_t end, float * __restrict__
> c, float * __restrict__ a, float * __restrict__ b)
> {
> for ( std::uint64_t i = start ; i < end ; i += 4 ) {
> {
> const std::uint64_t ir0 = (i+0)%4 + 8*((i+0)/4)...
2017 Mar 15
2
Use of the C++ standard library in XRay compiler-rt
...t | uniq -c
> > 1 #include <algorithm>
> > 10 #include <atomic>
> > 1 #include <bitset>
> > 6 #include <cassert>
> > 1 #include <cerrno>
> > 1 #include <cstddef>
> > 7 #include <cstdint>
> > 2 #include <cstdio>
> > 1 #include <cstdlib>
> > 2 #include <cstring>
> > 1 #include <deque>
> > 2 #include <iterator>
> > 2 #include <limits>
> > 2 #include <memory>...
2013 Oct 31
0
[LLVMdev] loop vectorizer misses opportunity, exploit
...Thanks,
> Nadav
>
> On Oct 31, 2013, at 8:01 AM, Frank Winter <fwinter at jlab.org
> <mailto:fwinter at jlab.org>> wrote:
>
>> A quite small but yet complete example function which all
>> vectorization passes fail to optimize:
>>
>> #include <cstdint>
>> #include <iostream>
>>
>> void bar(std::uint64_t start, std::uint64_t end, float *
>> __restrict__ c, float * __restrict__ a, float * __restrict__ b)
>> {
>> for ( std::uint64_t i = start ; i < end ; i += 4 ) {
>> {
>> co...
2013 Oct 31
0
[LLVMdev] loop vectorizer misses opportunity, exploit
...;> Nadav
>>
>>
>> On Oct 31, 2013, at 8:01 AM, Frank Winter < fwinter at jlab.org > wrote:
>>
>>
>>
>>
>> A quite small but yet complete example function which all
>> vectorization passes fail to optimize:
>>
>> #include <cstdint>
>> #include <iostream>
>>
>> void bar(std::uint64_t start, std::uint64_t end, float * __restrict__
>> c, float * __restrict__ a, float * __restrict__ b)
>> {
>> for ( std::uint64_t i = start ; i < end ; i += 4 ) {
>> {
>> const std::uint6...
2013 Oct 31
5
[LLVMdev] loop vectorizer
On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org> wrote:
> const std::uint64_t ir0 = (i+0)%4; // not working
>
I thought this would be the case when I saw the original expression. Maybe
we need to teach module arithmetic to SCEV?
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
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:
2018 Aug 06
4
[Release-testers] [7.0.0 Release] rc1 has been tagged
...ded-availability-new CMakeFiles/cmTC_845df.dir/src.cxx.o -o cmTC_845df -lm
> gmake[1]: Leaving directory '/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
>
> Source file was:
>
> #include <atomic>
> #include <cstdint>
> std::atomic<uint64_t> x (0);
> int main() {
> uint64_t i = x.load(std::memory_order_relaxed);
> return 0;
> }
>
> Phase2 CMake output:
>
> Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB failed with the following outp...