Displaying 20 results from an estimated 1100 matches similar to: "[patch] compiler.h fix use of likely/unlikely"
2006 Jan 03
1
Bug#344832: (fwd) Re: Bug#344832: correct subject header
----- Forwarded message from General Stone <generalstone at gmx.net> -----
X-Original-To: maks at sternwelten.at
Date: Mon, 2 Jan 2006 14:59:03 +0100
From: General Stone <generalstone at gmx.net>
To: maximilian attems <maks at sternwelten.at>
Subject: Re: [Logcheck-devel] Bug#344832: correct subject header
On Mon, Jan 02, 2006 at 02:09:48PM +0100, maximilian attems wrote:
>
2005 Dec 17
2
[patch] fix defintion of struct statfs64
From: Steve Langasek <vorlon@debian.org>
Fix the definition of struct statfs64,
required for run-init to work on alpha.
verified to have no regressions on amd64.
Signed-off-by: maximilian attems <janitor@sternwelten.at>
Signed-off-by: Frederik Sch?ler <fschueler-guest@costa.debian.org>
--- klibc-1.1.1.orig/include/sys/vfs.h
+++ klibc-1.1.1/include/sys/vfs.h
@@ -32,17 +32,17
2006 Jan 31
1
[patch] Kbuild.klibc don't hardcode gcc version
sparc still needs gcc-3.3 for a working run-init.
belows makes use of the exported CC var.
Signed-off-by: maximilian attems <maks@sternwelten.at>
diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc
index 66e16e7..70e4071 100644
--- a/scripts/Kbuild.klibc
+++ b/scripts/Kbuild.klibc
@@ -72,7 +72,7 @@ KLIBCROSS := $(CROSS_COMPILE)
# binutils
KLIBCLD := $(KLIBCROSS)ld
2006 Feb 19
2
[patch] statfs64 sparc64 fix
From: Sjoerd Simons <sjoerd@spring.luon.net>
It seems that klibc uses __sparc64__ to determine if it's compiled in 64
bit mode on sparc, unfortunatly gcc doesn't define __sparc64__ :) It does
define __arch64__ though.
Signed-off-by: maximilian attems <maks@sternwelten.at>
--- klibc-1.2.2.orig/include/sys/vfs.h 2006-02-15 18:32:10.000000000 +0100
+++
2019 Nov 02
2
[PATCH nbdkit] server: Use GCC hints to move debug and error handling code out of hot paths.
For GCC only, define unlikely() macro. Use it on error paths to move
code out of the hot path.
In the server only, use the debug() macro (don't call nbdkit_debug
directly). This macro checks the verbose flag and moves the call to
nbdkit_debug out of the hot path.
---
server/connections.c | 11 ++++++-----
server/internal.h | 17 ++++++++++++++++-
server/plugins.c | 2 +-
2006 Apr 18
1
[patch] sparc build fix
add object rules so that the division, remainder and friends get
really build on sparc, patch from Fabio M. Di Nitto <fabbione@ubuntu.com>.
reworked to apply on latest git tree.
Signed-off-by: maximilian attems <maks@sternwelten.at>
---
Has been since long in the Debian and Ubuntu klibc.
diff --git a/klibc/arch/sparc/Makefile.inc b/klibc/arch/sparc/Makefile.inc
index
2019 Nov 02
1
[PATCH libnbd] lib: Use GCC hints to move debug and error handling code out of hot paths.
---
generator/generator | 6 +++---
lib/crypto.c | 2 +-
lib/internal.h | 14 +++++++++++++-
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/generator/generator b/generator/generator
index c2ff0db..eb3408d 100755
--- a/generator/generator
+++ b/generator/generator
@@ -4512,7 +4512,7 @@ let generate_lib_api_c () =
let value = match errcode with
| Some
2004 Sep 01
2
dedup and sort rules
A non-text attachment was scrubbed...
Name: parse_logcheck
Type: application/octet-stream
Size: 3860 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20040901/b1727d89/attachment.obj
2013 Apr 19
2
Preprocessor error when trying to build integer-only
Hi,
I was wondering how much worse FLAC performance would be if it was
compiled integer-only, but while trying to do so (by adding #define
FLAC__INTEGER_ONLY_LIBRARY 1 to config.h, just on x86_64-linux) I got
this error
> ./include/private/bitmath.h:134:5: error: operator '&&' has no left
> operand
bitmath.h:134 is the following line
> #if &&
2006 Aug 24
0
[patch] mkdir use and add usage
please pull
git://charm.itp.tuwien.ac.at/mattems/klibc/.git maks
commit b0c5c2b8ee60d91cb96541339c6be8108d0e2131
Author: maximilian attems <maks at sternwelten.at>
Date: Thu Aug 24 22:40:23 2006 +0200
[klibc] mkdir add usage
when printing errors about cli switches, point out the expected usage.
patches adds usage function and calls to it.
Signed-off-by: maximilian
2007 Apr 20
1
[LLVMdev] llvm-gcc make check
Is 'make check' supposed to work with llvm-gcc? I get the following:
autogen -T
/users/dag/projects/cascade/compiler/llvm-gcc/fixincludes/check.tpl
/users/dag/projects/cascade/compiler/llvm-gcc/fixincludes/inclhack.def
Your shell is '/bin/tcsh'. AutoGen will attempt to use 'sh'
/bin/sh ./check.sh
/users/dag/projects/cascade/compiler/llvm-gcc/fixincludes/tests/base
2004 Jul 07
0
[PATCH] __likely -> likely conversion
Hi hpa,
the following patch corrects the usage of '__likely', which has been
replaced by 'likely()' in recent kernels.
Plus it adds a missing include 'klibc/compiler.h' for sys/types.h as the
bitops on S/390 insist on using 'likely'.
Please apply.
THX,
Hannes
--
Dr. Hannes Reinecke hare@suse.de
SuSE Linux AG S390 & zSeries
Maxfeldstra?e 5 +49 911
2010 Mar 03
1
[LLVMdev] Problem with ALWAYS_INLINE
Using GCC 3.4.6 20060404 (Red Hat 3.4.6-11) I've had this problem with
the ALWAYS_INLINE directive in SelectionDAGISel.cpp:
/arm/scratch/egrimley/llvm.svn/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In function `bool CheckChildType(const unsigned char*, unsigned int&, llvm::SDValue, const llvm::TargetLowering&, unsigned int)':
2000 Jun 26
1
Re: [vorbis] bug in glibc 2.1.2 and older
Hello,
I have solved this problem in the splay mp3 decoder with this:
In the header:
#if (__GNUC__ < 2 || ( __GNUC__ == 2 && __GNUC_MINOR__ < 91 ) )
#warning "inline code disabled! (buggy egcs version)"
#undef __NO_MATH_INLINES
#define __NO_MATH_INLINES 1
#endif
#include <math.h>
In the makefile:
CXXFLAGS=@CXXFLAGS@ -fno-strength-reduce
(Opt level is 2)
and
2013 Jan 08
1
[PATCH][firmware] efi: Fix build with gnu-efi >= 3.0s
From: Matt Fleming <matt.fleming at intel.com>
For x86_64 versions of gnu-efi >= 3.0s GNU_EFI_USE_MS_ABI is enabled
which turns on the Microsoft ABI, allowing the compiler to do all the
work of interfacing with the EFI firmware instead of jumping through
uefi_call_wrapper().
Add support to turn this on in the gnu-efi headers, otherwise we'll
encounter undefined references to
2023 Feb 15
2
[libnbd PATCH v3 02/29] generator/C.ml: use space consistently in func. and func.-like macro calls
Apply the ideas in the previous patch to the C-language bindings
generator.
Signed-off-by: Laszlo Ersek <lersek at redhat.com>
---
generator/C.ml | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/generator/C.ml b/generator/C.ml
index f9171996dde0..07c924c48ccf 100644
--- a/generator/C.ml
+++ b/generator/C.ml
@@ -250,15 +250,15 @@ let
*)
2019 Nov 04
0
Re: [PATCH nbdkit] server: Use GCC hints to move debug and error handling code out of hot paths.
On 11/2/19 4:24 PM, Richard W.M. Jones wrote:
> For GCC only, define unlikely() macro. Use it on error paths to move
> code out of the hot path.
>
> In the server only, use the debug() macro (don't call nbdkit_debug
> directly). This macro checks the verbose flag and moves the call to
> nbdkit_debug out of the hot path.
> ---
> +++ b/server/internal.h
> @@ -45,6
2004 Jul 09
1
Bug#258427: logcheck/logtail didn't detect tampering logfile
Package: logcheck
wanted to work on #195935,
but found a less than funny issue, easy to reproduce:
* remove some lines in front of your logfile
* invoke logcheck
you'll get a big email with all not matching lines from that log.
not setting that to high priority because you are getting also the
newer loglines. don't know if i find time that weekend.
wanted to document it anyways.
a++
2004 Aug 31
1
[LLVMdev] More configure problems
>From: Jeff Cohen <jeffc at jolt-lang.org>
>Date: Mon, 30 Aug 2004 21:46:42 -0700
>FileParser.tab.c: In function `int Fileparse()':
>FileParser.tab.c:2043: error: syntax error before `goto'
>
>The offending lines bison generated are:
>
>/*----------------------------------------------------.
>| yyerrlab1 -- error raised explicitly by an action. |
2008 Mar 21
3
[LLVMdev] Just got bitten by accidentally using the wrong gcc
I recommend you don't parse version strings. In fact I switch the
check to use AC_COMPILE precisely for the reason that gcc --version is
totally unreliable and vendor specific. For example, what's the
regular expression that tells you what the GCC version is:
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5470)
(Aspen 5470.3)
Per the rest of this thread, you can't