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