Defining symvers without using asm()
Hi.
from the ld.info manual:
""" [...] the ability to bind a symbol to a version node in the source
file where the symbol is defined instead of in the versioning script.
This was done mainly to reduce the burden on the library maintainer.
You can do this by putting something like:
__asm__(".symver original_foo,foo@VERS_1.1");
in the C source file. This renames the function `original_foo' to
be an alias for `foo' bound to the version node `VERS_1.1'. """
But how does one actually specify such a rename within a version linker
script, outside of the .c file?
verify_gimple fails for git-1.6.4.1
Hi,
Compiling git 1.6.4.1 with the gcc trunk
Using built-in specs.
Target: x86_64-suse-linux Configured with: ../configure
--prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=yes
--with-gxx-include-dir=/usr/include/c++/4.5 enable-ssp
--disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' disable-libgcj
--disable-libmudflap --with-slibdir=/lib64 with-system-zlib
--enable-__cxa_atexit enable-libstdcxx-allocator=new
--disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.5
--enable-linux-futex --without-system-libunwind
--with-arch-32=i586 with-tune=generic
--build=x86_64-suse-linux
Thread model: posix
gcc version 4.5.0 20090820 (experimental) [trunk revision
150958] (SUSE Linux)
yields a gimple error ("internal compiler error: verify_gimple failed").
Reproducible: Always
Steps to Reproduce:
1. Grab git-1.6.4.1 via tarball from git-scm.com or via git://
2. `make builtin-grep.o`
Actual Results:
builtin-grep.c: In function ‘cmd_grep’:
builtin-grep.c:669:5: error: type mismatch in address expression
struct option[] *
struct option[41] *
options.0 = &options;
builtin-grep.c:669:5: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
> Hi,
>
> The following program segfaults when compiled with gcc
> but runs fine when compiled with g++ or icc (the intel C compiler)
>
> #include
> struct Hello {
> char world[20];
> };
> struct Hello s(){
> struct Hello r;
> r.world[0]='H';
> r.world[1]='\0';
> return r;
> }
>
> int main(){
> printf("%s\n",s().world);
> }
>
> Assigning s() to a variable and then using the variable avoids the segfault.
Had you compiled with -Wall would you have noticed:
e.c:13: warning: format ‘%s’ expects type ‘char *’, but
argument 2 has type ‘char[20]’
And when there is a type mismatch, a crash is pretty likely.
Not that I can say why gcc does not convert it to char* but g++ does.
Now what happens? The following augmented snippet shows it:
---<8---
#include
#include
#include
struct Hello {
char world[20];
};
struct Hello s(void)
{
struct Hello r;
strcpy(r.world, "Hello");
return r;
}
static void dump(const char *fmt, ...)
{
va_list argp;
va_start(argp, fmt);
char *p = va_arg(argp, char *);
printf("%p\n", p);
va_end(argp);
}
int main(void)
{
dump("", s().world);
return 0;
}
--->8---
I get 0x6c6c6548, which is obviously part of the string Hello. So
passing a char[20] into a varargs function seems not to convert it to
char* when done through a non-visibile temporary (the result of s()
is hidden on the stack of main).
Re: A bug?
On Tuesday 2008-12-16 18:01, Sebastian Redl wrote:
> Michel Van den Bergh wrote:
>> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
>> (Intel core2 duo)
>> I get
>>
>> stest.c: In function ‘main’:
>> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 has
>> type ‘char[20]’
>>
> The C++ standard says in 5.2.2p7: "The lvalue-to-rvalue, array-to-pointer, and
> function-to-pointer standard conversions are performed on the argument
> expression."
>
> The C standard says no such thing; only integer promotions are performed. (See
> 6.5.2.2 of the C99 final draft.)
But what about
char t[20];
printf("%s\n", t);
typeof(t) is char[20], and if no promotion is performed,
how come it is converted to char* in C?
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
On Tuesday 2008-12-16 18:43, Michel Van den Bergh wrote:
> Andrew Haley wrote:
>> Andrew Thomas Pinski wrote:
>>
>> > C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
>> > arrays in C++98. Also this code is still undefined C99 but will most
>> > likely become valid C1x.
>>
>> Ah, it's an rvalue array. Good point.
>>
> Ok now I understand. I assume this behaviour is not triggered often as in C it
> is
> not so common to have an array which is an rvalue.
Is not this a use of an rvalue array too?:
#include
int main(void)
{
printf("%p\n", (struct { char x[20]; }){{"Hello"}}.x);
}
This one actually works fine. So maybe it's really limited to
the case where a function returning a struct is involved.
Compiler turns off warnings unexpectedly
Hi,
I have here an (attached) testcase which unexpectedly turns off
warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
test.c: In function ‘pam_sm_authenticate’:
test.c:6: warning: implicit declaration of function ‘undef’
What I would have expected:
test.c: In function ‘pam_sm_authenticate’:
test.c:6: warning: implicit declaration of function ‘undef’
test.c: In function ‘pam_sm_authenticate’:
test.c:11: warning: implicit declaration of function ‘undef2’
Compiler in use:
openSUSE 11.1
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) #include
int pam_sm_authenticate(pam_handle_t *pamh, int flags,
int argc, const char **argv)
{
undef();
}
void f2(void)
{
undef2();
}
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "/usr/include/security/pam_modules.h" 1 3 4
# 17 "/usr/include/security/pam_modules.h" 3 4
# 1 "/usr/include/security/_pam_types.h" 1 3 4
# 18 "/usr/include/security/_pam_types.h" 3 4
typedef struct pam_handle pam_handle_t;
# 170 "/usr/include/security/_pam_types.h" 3 4
extern int __attribute__((__nonnull__ (1)))
pam_set_item(pam_handle_t *pamh, int item_type, const void *item);
extern int __attribute__((__nonnull__ (1)))
pam_get_item(const pam_handle_t *pamh, int item_type, const void **item);
extern const char *
pam_strerror(pam_handle_t *pamh, int errnum);
extern int __attribute__((__nonnull__ (1,2)))
pam_putenv(pam_handle_t *pamh, const char *name_value);
extern const char * __attribute__((__nonnull__ (1,2)))
pam_getenv(pam_handle_t *pamh, const char *name);
extern char ** __attribute__((__nonnull__ (1)))
pam_getenvlist(pam_handle_t *pamh);
# 216 "/usr/include/security/_pam_types.h" 3 4
extern int pam_fail_delay(pam_handle_t *pamh, unsigned int musec_delay);
# 247 "/usr/include/security/_pam_types.h" 3 4
struct pam_message {
int msg_style;
const char *msg;
};
# 272 "/usr/include/security/_pam_types.h" 3 4
struct pam_response {
char *resp;
int resp_retcode;
};
struct pam_conv {
int (*conv)(int num_msg, const struct pam_message **msg,
struct pam_response **resp, void *appdata_ptr);
void *appdata_ptr;
};
struct pam_xauth_data {
int namelen;
char *name;
int datalen;
char *data;
};
# 18 "/usr/include/security/pam_modules.h" 2 3 4
extern int __attribute__((__nonnull__ (1,2)))
pam_set_data(pam_handle_t *pamh, const char *module_data_name, void *data,
void (*cleanup)(pam_handle_t *pamh, void *data,
int error_status));
extern int __attribute__((__nonnull__ (1,2,3)))
pam_get_data(const pam_handle_t *pamh, const char *module_data_name,
const void **data);
extern int __attribute__((__nonnull__ (1,2)))
pam_get_user(pam_handle_t *pamh, const char **user, const char *prompt);
# 70 "/usr/include/security/pam_modules.h" 3 4
extern int pam_sm_authenticate(pam_handle_t *pamh, int flags,
int argc, const char **argv);
extern int pam_sm_setcred(pam_handle_t *pamh, int flags,
int argc, const char **argv);
extern int pam_sm_acct_mgmt(pam_handle_t *pamh, int flags,
int argc, const char **argv);
extern int pam_sm_open_session(pam_handle_t *pamh, int flags,
int argc, const char **argv);
extern int pam_sm_close_session(pam_handle_t *pamh, int flags,
int argc, const char **argv);
extern int pam_sm_chauthtok(pam_handle_t *pamh, int flags,
int argc, const char **argv);
# 134 "/usr/include/security/pam_modules.h" 3 4
# 1 "/usr/include/security/_pam_compat.h" 1 3 4
# 135 "/usr/include/security/pam_modules.h" 2 3 4
# 2 "test.c" 2
int pam_sm_authenticate(pam_handle_t *pamh, int flags,
int argc, const char **argv)
{
undef();
}
void f2(void)
{
undef2();
}
Re: Compiler turns off warnings unexpectedly
On Thursday 2009-01-01 03:05, Andrew Pinski wrote: >On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt wrote: >> Hi, >> >> >> I have here an (attached) testcase which unexpectedly turns off >> warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives: >> >> test.c: In function 'pam_sm_authenticate': >> test.c:6: warning: implicit declaration of function 'undef' > >This works on the trunk but fails on the 4.3 branch. gcc 4.1 also produces the expected output (implicit declaration undef2), so it seems like a recent regression.
uint64_t alignof odditity on x86
Hi,
I noticed that __alignof__(uint64_t) will return 8, while
__alignof__(struct { uint64_t x; }) will give only 4. This
run on a typical 32-bit x86 CPU (GCC config below).
What I am wondering about is why GCC was coded to give different
alignments here. If aligning a single uint64_t to a boundary of 8 for
whatever reason there may be (performance?), not doing so when it is
inside a struct appears to be a discrepancy.
---
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)
openSUSE 11.1 i586.
GCC feature req: warn when bitops exceed type size (was: conntrack untracked match is broken)
Hi gcc list, I am forwarding below's bugreport here(*), to implicitly make aware of a feature that I deem important to have in a future gcc. (*) should have posted to bugzilla instead? Don't feel like setting up a bugmenot tho.. -- Forwarded message -- Date: Mon, 29 Jun 2009 14:34:10 From: Patrick McHardy To: Jan Engelhardt Cc: Netfilter Developer Mailing List , Philip Craig Subject: Re: conntrack untracked match is broken (kernel patch) >On Monday 2009-06-22 08:31, Philip Craig wrote: >>The problem is that state_mask in 'struct xt_conntrack_mtinfo1' is >>only 8 bit, but XT_CONNTRACK_STATE_UNTRACKED == 256. >>Unfortunately, gcc doesn't warn about this for '|=', only for '='. [i.e. uint8_t x = 0; x |= 256; ] > >I smell a gcc-missing-feature there.
Re: GCC feature req: warn when bitops exceed type size (was: conntrack untracked match is broken)
On Monday 2009-06-29 16:09, Manuel López-Ibáñez wrote: >2009/6/29 Richard Guenther wrote: >> On Mon, Jun 29, 2009 at 3:10 PM, Jan Engelhardt wrote: >>> Hi gcc list, >>> >>> >>> I am forwarding below's bugreport here(*), to implicitly make aware >>> of a feature that I deem important to have in a future gcc. >>> >> >> -Wconversion should say >> >> t.c:4: warning: conversion to ‘unsigned char’ from ‘int’ may alter its value I added -Wconversion to the Linux kernel's global cflags (KBUILD_CFLAGS) just to see what would happen. As I expected, I get swamped with warnings, like "conversion to int from unsigned int". All legitimate in themselves, I would have preferred an option (or even no option at all, given that the "large integer implicitly truncated to unsigned type" warning is shown without any -W flags) that only flags up truncation problems with literals.
