search for: longlong

Unsure what exactly the problem is, but when using 4.8-STABLE I was unable to compile MySQL (it failed during configure phase).. On further investigation, the following code segment when compiled with phtreads, results in a segmentation fault: #include <stdio.h> typedef long long longlong; main() { longlong ll=1; float f; FILE *file=fopen("conftestval", "w"); f = (float) ll; fprintf(file,"%g\n",f); close(file); exit (0); } If I roll back uthread_close.c to Revision 1.10.2.3, the above code segment works ok so I would assume that there is...

...ngw32 system i386, mingw32 status major 2 minor 5.0 year 2007 month 04 day 23 svn rev 41293 language R version.string R version 2.5.0 (2007-04-23) I understand this: > .Machine$integer.max [1] 2147483647 > .Machine$sizeof.longlong [1] 8 So how can I get a "longlong" (i.e., 64-bit = 8-byte integers) in my environment? Where is there no storage.mode of "longlong" or "int64"? I'm reading electrophysiology data with a time stamp that's in a 64-bit integer (it's a microsecond clock c...

...ikewise. * m4/inttypes-pri.m4: Likewise. * m4/inttypes.m4: Likewise. * m4/inttypes_h.m4: Likewise. * m4/isc-posix.m4: Likewise. * m4/lcmessage.m4: Likewise. * m4/lib-ld.m4: Likewise. * m4/lib-link.m4: Likewise. * m4/lib-prefix.m4: Likewise. * m4/lock.m4: Likewise. * m4/longdouble.m4: Likewise. * m4/longlong.m4: Likewise. * m4/nls.m4: Likewise. * m4/po.m4: Likewise. * m4/printf-posix.m4: Likewise. * m4/progtest.m4: Likewise. * m4/signed.m4: Likewise. * m4/size_max.m4: Likewise. * m4/stdint_h.m4: Likewise. * m4/uintmax_t.m4: Likewise. * m4/ulonglong.m4: Likewise. * m4/visibility.m4: Likewise. * m4/wchar...

Hi all Here is the egrep result : egrep "SIZEOF|LONGLONG" build_mipsel/rsync-2.6.3/config.h /* #undef HAVE_LONGLONG */ #define SIZEOF_INT 4 #define SIZEOF_LONG 4 #define SIZEOF_SHORT 2 and the HAVE_LONGLONG config.log result : rsync_cv_HAVE_LONGLONG=cross Is there a problem with this values ? Thanks a lot for your answer Best regards, Florian

4.8-stable as/of jun 9th (update scheduled) has gcc version, 2.95.4 i'm building mod_php3 (some local stuff needs a php3 processor) with mysql support. using the mysql323 client/server from ports. mysql (which i know i've built before on older stable's) reports gcc can't convert longlong to something or other... basicly saying i need a newer compiler. i'm installing gcc33 from ports, since it's the latest release according to gnu's site... but running 'make check' (which is still running) has been spitting out quite a few failures like, FAIL: SyncGlobal -O e...

On Thu, 23 May 2019 08:10:44 -0700 Linus Torvalds <torvalds at linux-foundation.org> wrote: > On Thu, May 23, 2019 at 7:00 AM Steven Rostedt <rostedt at goodmis.org> wrote: > > > > +# define roundup_64(x, y) ( \ > > +{ \ > > + typeof(y) __y = y;

...using "type overloading" by size. The most explicit case is perhaps "get_user()" and "put_user()", but this whole round_up thing is another example. Maybe we never really care about "char" and "short", and always want just the "int-vs-long-vs-longlong"? That would make the cases simpler (32 and 64). And maybe we never care about sign. But we could try to have some unified helper model like the above.. Linus

...t Independent Bitcode 1 ; ModuleID = 'gu.c' 2 target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32 -f64:64:64-v64:64:64-v128:128:128-a0:0:64-f192:32:32" 3 target triple = "ovm-none-linux" 4 5 %struct.foo = type { i4(char), i61(longlong), i30(int) } 6 7 @var = common global %struct.foo zeroinitializer ; <%struct.foo*> [#uses=0] Target Dependent Bitcode ARM 1 ; ModuleID = 'gu.mod.opt.arm.bc' 2 target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32 -f64:64:64-v64:64:64-v12...

On my Mac: str(.Machine) ... $ integer.max????????? : int 2147483647 ?$ sizeof.long????????? : int 8 ?$ sizeof.longlong????? : int 8 ?$ sizeof.longdouble??? : int 16 ?$ sizeof.pointer?????? : int 8 ????? On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise the same as on my Mac. ????? Am I correct that $ sizeof.long = 4 means 4 bytes = 32 bits? log2(.Machine$integer.max) = 31.? Then 8 bytes is...

Hi all ! I really appreciate rsync, so that I would like to make a package for the mips architecture, but I encounter a problem when trying to cross compile it : the configure script has been called using the following options : --with-gnu-ld \ --disable-largefiles \ --with-included-popt \ --with-rsh=ssh \ And when using the cross compiler, I get the following message : In file

.../intlmacosx.m4 @@ -103,13 +83,9 @@ /inttypes.m4 /inttypes-pri.m4 /ioctl.m4 -/i-ring.m4 -/isatty.m4 /isblank.m4 -/isc-posix.m4 /langinfo_h.m4 /largefile.m4 -/lchown.m4 /lcmessage.m4 /lib-ld.m4 /lib-link.m4 @@ -125,7 +101,6 @@ /locale-zh.m4 /localtime-buffer.m4 /lock.m4 -/longdouble.m4 /longlong.m4 /lseek.m4 /lstat.m4 @@ -143,7 +118,6 @@ /memmem.m4 /mempcpy.m4 /memrchr.m4 -/mgetgroups.m4 /minmax.m4 /mkdir.m4 /mkdtemp.m4 @@ -175,7 +149,6 @@ /pthread_rwlock_rdlock.m4 /pthread_sigmask.m4 /pthread-thread.m4 -/ptsname_r.m4 /putenv.m4 /quotearg.m4 /quote.m4 @@ -194,7 +167,6 @@ /sa...

...ding" by > size. The most explicit case is perhaps "get_user()" and "put_user()", > but this whole round_up thing is another example. > > Maybe we never really care about "char" and "short", and always want > just the "int-vs-long-vs-longlong"? That would make the cases simpler > (32 and 64). And maybe we never care about sign. But we could try to > have some unified helper model like the above.. It may be simpler and perhaps more robust if we keep the char and short cases. I'm fine with adding something like this for r...

...hread. >>> > >> We could leave the list out and create a Wiki or something with the >> results of our tests. >> >> >>> >re: unsigned short - I have adopted the convention to use the *NN_t >>> types after running into a problem with unsigned longlong (from a >>> very old program). It goes back many years - and maybe they have >>> finalized short to mean 16-bits - but I remember when short was >>> meant to help when moving from 16-bit to 32-bit and the "word" size >>> changed - i.e., int became 3...

...021 may be possible. > > I few notes inline below: > > On Sun, 19 Jan 2020, Spencer Graves wrote: > >> On my Mac: >> >> >> str(.Machine) >> ... >> $ integer.max????????? : int 2147483647 >> ?$ sizeof.long????????? : int 8 >> ?$ sizeof.longlong????? : int 8 >> ?$ sizeof.longdouble??? : int 16 >> ?$ sizeof.pointer?????? : int 8 >> >> >> ????? On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise >> the same as on my Mac. > One of many annoyances of Windows -- done for compatibility with...

Quite a complex fix in the end, see the comment in the second commit. Rich.

...gt; -/i-ring.m4 > -/isatty.m4 > /isblank.m4 > -/isc-posix.m4 > /langinfo_h.m4 > /largefile.m4 > -/lchown.m4 > /lcmessage.m4 > /lib-ld.m4 > /lib-link.m4 > @@ -125,7 +101,6 @@ > /locale-zh.m4 > /localtime-buffer.m4 > /lock.m4 > -/longdouble.m4 > /longlong.m4 > /lseek.m4 > /lstat.m4 > @@ -143,7 +118,6 @@ > /memmem.m4 > /mempcpy.m4 > /memrchr.m4 > -/mgetgroups.m4 > /minmax.m4 > /mkdir.m4 > /mkdtemp.m4 > @@ -175,7 +149,6 @@ > /pthread_rwlock_rdlock.m4 > /pthread_sigmask.m4 > /pthread-thread.m4 > -...

.../intlmacosx.m4 @@ -103,13 +74,9 @@ /inttypes.m4 /inttypes-pri.m4 /ioctl.m4 -/i-ring.m4 -/isatty.m4 /isblank.m4 -/isc-posix.m4 /langinfo_h.m4 /largefile.m4 -/lchown.m4 /lcmessage.m4 /lib-ld.m4 /lib-link.m4 @@ -125,7 +92,6 @@ /locale-zh.m4 /localtime-buffer.m4 /lock.m4 -/longdouble.m4 /longlong.m4 /lseek.m4 /lstat.m4 @@ -143,7 +109,6 @@ /memmem.m4 /mempcpy.m4 /memrchr.m4 -/mgetgroups.m4 /minmax.m4 /mkdir.m4 /mkdtemp.m4 @@ -175,26 +140,22 @@ /pthread_rwlock_rdlock.m4 /pthread_sigmask.m4 /pthread-thread.m4 -/ptsname_r.m4 /putenv.m4 /quotearg.m4 /quote.m4 /raise.m4 /rawmemchr...

Hi, Thanks for the information. Is it possible to compile LLVM 3.8 in FreeBSD 10.x and eventually use/run it on 8.4. Our production environment is running 8.4 and we cannot update it. Thanks, Sushil Pangeni On Wed, Jun 22, 2016 at 2:01 PM, Dimitry Andric <dimitry at andric.com> wrote: > You cannot build any llvm or clang releases after 3.4 on FreeBSD 8.x > natively, as it is not

...I doubt anything can happen for R 4.0.0 this year, but 2021 may be possible. I few notes inline below: On Sun, 19 Jan 2020, Spencer Graves wrote: > On my Mac: > > > str(.Machine) > ... > $ integer.max????????? : int 2147483647 > ?$ sizeof.long????????? : int 8 > ?$ sizeof.longlong????? : int 8 > ?$ sizeof.longdouble??? : int 16 > ?$ sizeof.pointer?????? : int 8 > > > ????? On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise > the same as on my Mac. One of many annoyances of Windows -- done for compatibility with ancient Window apps. > ????...

.....7f60faf --- /dev/null +++ b/daemon/.gitignore @@ -0,0 +1,29 @@ +build-aux +lib +link-warning.h +m4/00gnulib.m4 +m4/errno_h.m4 +m4/error.m4 +m4/exitfail.m4 +m4/extensions.m4 +m4/gnulib-common.m4 +m4/gnulib-comp.m4 +m4/gnulib-tool.m4 +m4/hash.m4 +m4/include_next.m4 +m4/inline.m4 +m4/inttostr.m4 +m4/longlong.m4 +m4/multiarch.m4 +m4/onceonly.m4 +m4/stdbool.m4 +m4/stdint.m4 +m4/stdlib_h.m4 +m4/strerror.m4 +m4/string_h.m4 +m4/unistd_h.m4 +m4/wchar.m4 +m4/wchar_t.m4 +m4/wint_t.m4 +m4/xalloc.m4 +tests diff --git a/daemon/Makefile.am b/daemon/Makefile.am index 0fec611..090338d 100644 --- a/daemon/Makefile.am...