similar to: [LLVMdev] Integer typedefs for MSVC

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Integer typedefs for MSVC"

2012 Feb 09
2
[PATCH] Remove even more CPP hackery
> Dave Yeo wrote: >> Yes that makes sense. Requiring a C99 compliant compiler seems quite reasonable. > Well I'm actually going to be even more reasonable than that. The only bits of C99 that flac will really require is header file > with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik I would recommend including with the distribution a file for windows
2012 Feb 09
1
[PATCH] Remove even more CPP hackery
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09.02.2012 21:41, Ben Allison wrote: >>> Dave Yeo wrote: >>>> Yes that makes sense. Requiring a C99 compliant compiler >>>> seems quite >> reasonable. >>> Well I'm actually going to be even more reasonable than that. >>> The only >> bits of C99 that flac will really require is
2012 Feb 09
0
[PATCH] Remove even more CPP hackery
>> Dave Yeo wrote: >>> Yes that makes sense. Requiring a C99 compliant compiler seems quite > reasonable. >> Well I'm actually going to be even more reasonable than that. The only > bits of C99 that flac will really require is header file >> with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik > > I would recommend including with the
2015 Jun 03
5
[PATCH 1/1] Updated opus_types.h to correctly support 8 and 64 bit types.
- Replaced blanket #define of 8 & 64 bit types with typedefs for each platform to match 16 & 32 bit types. - Updated existing typedefs for each platform to fix odd values and improve consistency. --- include/opus_types.h | 125 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 100 insertions(+), 25 deletions(-) diff --git a/include/opus_types.h
2002 Dec 10
2
mingw compiling problem for libogg
(i hope this is correct m.list) Hi, there is a small compiling problem for mingw when compiling on libogg.. in include/ogg/os_types.h : ogg_int64_t, ogg_int32_t, etc are defined correctly on cygwin and MSVC/Borland but not on mingw... i have attached a patch that will fix this problem (i hope it attaches correctly) thx, Nehal --- os_types.h.old Fri Jul 19 02:25:52 2002 +++ os_types.h Tue
2003 Sep 29
1
openssh-3-7-1p2 compiling problems on Reliant UNIX
Martin.Rottler at nuernberger.de wrote: > I have problems compiling openssh-3-7-1p2 on Reliant UNIX. > (same problem with 3-7-1p1) > > first error was: > ../defines.h 144: [error] CFE1101 "int8_t" has already been declared in the > current scope > typedef char int8_t; The configure test tests for int8_t, int16_t and int32_t before defining HAVE_INTXX_T. Does your
2020 Apr 07
2
Questions about vscale
Hi, Looking at the language reference, vscale is an integer. This might pose a problem for fractional vscale. Furthermore, I believe that vscale is constant throughout the life of the program; so if RISC-V vscale can vary from instruction to instruction that may also be problematic unless you can just commit to one specific value of vscale. Also, I had a question about your table. Based
2019 Sep 23
2
[PATCH nbdkit v2] server: public: Add nbdkit_parse_* functions for safely parsing integers.
On Mon, Sep 23, 2019 at 01:23:28PM -0500, Eric Blake wrote: > > Hopefully it will warn us if uid_t stops being int. (Also > > we're assuming pid_t == int). > > 64-bit mingw has had a long-standing bug that pid_t was declared as > 64-bit, even though getpid() returns a 32-bit 'int'; I wish they'd fix > their headers, but it violates the assumption of pid_t
2020 Apr 07
2
Questions about vscale
Hi, In RISC-V v-extension, operations could operate on a group of vector registers; we called it LMUL. If LMUL equals 2, it means we could operate on 2 vector registers at the same time. So, we have the following combinations of types. LMUL = 1 LMUL = 2 LMUL = 4 LMUL = 8 int64_t | vscale x 1 x i64 | vscale x 2 x i64 | vscale x 4 x i64 | vscale x 8
2012 Feb 07
2
[PATCH] Remove even more CPP hackery
This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been been replaced by klibc. Considering the age of EMX and lack of testing and that klibc contains so many improvements I think this is exceptable. --- include/FLAC/ordinals.h | 17 +++++++++-------- src/flac/main.c | 2 +- src/libFLAC/metadata_iterators.c | 2 +-
2020 Aug 18
0
[PATCH nbdkit 8/9] include: Prefix all exports with NBDKIT_DLLEXPORT.
This is #defined as empty at the moment, but it allows the Windows port to define this __declspec(dllexport), which is necessary for symbols to be exported in DLLs. --- include/nbdkit-common.h | 86 ++++++++++++++++++++++++----------------- include/nbdkit-filter.h | 42 +++++++++++++------- include/nbdkit-plugin.h | 6 +-- server/main.c | 2 + 4 files changed, 83 insertions(+), 53
2018 Mar 20
3
What is the status of the "Killing Undef and Spreading Poison" RFC?
On 20 March 2018 at 09:39, Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > Let me give you my view of the status: > The proposal you mentioned was, I believe, well understood and accepted. > Except for one bit, which was that it requires correct typing of load/store > operations. That is, if you load an i32, it means you are loading a single >
2012 Jun 14
1
High CPU usage
Hi Mark, Code below: int16_t* samples; int16_t* fbSilenceFrame; void *fSpeexState; float eng(0.f); int speexFrameSize(0); speex_encoder_ctl(speexState, SPEEX_GET_FRAME_SIZE, &speexFrameSize); for (int i = 0; i < speexFrameSize; i++) { eng += samples[i] * samples[i]; } if (eng / speexFrameSize < 3.f) { memcpy(samples, silenceFrame, speexFrameSize * sizeof(int16_t)); } where
2018 Mar 20
0
What is the status of the "Killing Undef and Spreading Poison" RFC?
> On 20 March 2018 at 09:39, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> Let me give you my view of the status: >> The proposal you mentioned was, I believe, well understood and accepted. >> Except for one bit, which was that it requires correct typing of load/store >> operations. That is, if you load an i32, it means
2020 Apr 07
7
Questions about vscale
Hi all, On Tue, 7 Apr 2020 at 11:04, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 7 Apr 2020 at 09:30, Kai Wang via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > LMUL = 1 LMUL = 2 LMUL = 4 LMUL = 8 > > int64_t | vscale x 1 x i64 | vscale x 2 x i64 | vscale x 4 x i64 | vscale x 8 x i64
2004 Feb 07
1
double define of __BIT_TYPES_DEFINED__
/klibc/klibc/include/bits32/bitsize/stdint.h:8: error: redefinition of `int8_t' /klibc/linux/include/linux/types.h:109: error: `int8_t' previously declared here The copy in stdint.h is not protected by: #ifndef __BIT_TYPES_DEFINED__ #define __BIT_TYPES_DEFINED__ #endif /* !(__BIT_TYPES_DEFINED__) */ ===== Jon Smirl jonsmirl@yahoo.com __________________________________ Do you Yahoo!?
2020 Mar 23
0
[PATCH nbdkit 1/3] include: Function indirection for PE DLL
From: Yifan Gu <gyf304@gmail.com> This patch adds in indirection for API functions, as PE DLL loader does not resolve undefined symbols. This patch only includes header changes. --- include/nbdkit-common.h | 133 +++++++++++++++++++++++++++++++++++++++- include/nbdkit-compat.h | 97 +++++++++++++++++++++++++++++ include/nbdkit-filter.h | 39 ++++++++++++ include/nbdkit-plugin.h | 27
2019 Sep 23
2
Re: [PATCH nbdkit] server: public: Add nbdkit_parse_* functions for safely parsing integers.
On Mon, Sep 23, 2019 at 12:05:11PM -0500, Eric Blake wrote: > > + int nbdkit_parse_long (const char *what, const char *str, long *r); > > + int nbdkit_parse_unsigned_long (const char *what, > > + const char *str, unsigned long *r); > > Do we really want to encourage the use of parse_long and > parse_unsigned_long? Those differ between
2004 Sep 10
2
1.0 candidate checked in
> OK, attempting one more convergence on all this, here's > what I did: > > 1. Reverted back to rev 1.5 of src/libFLAC/ia32/Makefile.am > 2. Applied Matt's last cleanup patch of 8 files. I did not > apply the patch to src/test_unit/main.c since it looks wrong. > main.c is supposed to include the local bitbuffer.h, not > src/libFLAC/private/bitbuffer.h; I think the
2001 Jul 16
0
No subject
openssh at openssh.com Dear openssh team ! When I try to configure openssh version 2.9p2 on an ALPHA OSF1 V4.0 I get lots of error messages of the following type What is missing fundamentally ? Could this be due to not using gcc ? How can I solve these problems ? best regards S. Hoefinger