ICE in 4.8.2 with compound literal
Hello,
This ICE may have gotten lost in the noise of my own message.
https://gcc.gnu.org/ml/gcc-help/2014-11/msg00094.html
(The code snippet might be invalid C)
$ gcc -std=gnu99 -O3 -S test.c
test.c: In function 'main':
test.c:3:5: internal compiler error: in expand_expr_real_1, at expr.c:10540
int main() { return *(adds[0]); }
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to
your bugreport.
// /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -imultiarch x86_64-linux-gnu
test.c -quiet -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -O3
-std=gnu99 -o - -fstack-protector -Wformat -Wformat-security -frandom-seed=0
# 1 "test.c"
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.c"
union foo { struct { unsigned baz: 3, bar: 1; } bits; int value; };
int * const adds[] = {&(((union foo){.bits={ .bar = 0x1 }}).value)};
int main() { return *(adds[0]); }
Regards.
Re: ICE in 4.8.2 with compound literal
Hello Marek,
On 25/11/2014 09:47, Marek Polacek wrote:
On Tue, Nov 25, 2014 at 09:30:05AM +0100, Mason wrote:
This ICE may have gotten lost in the noise of my own message.
https://gcc.gnu.org/ml/gcc-help/2014-11/msg00094.html
(The code snippet might be invalid C)
$ gcc -std=gnu99 -O3 -S test.c
test.c: In function 'main':
test.c:3:5: internal compiler error: in expand_expr_real_1, at expr.c:10540
int main() { return *(adds[0]); }
^
I can reproduce the error. Please do...
Please submit a full bug report,
OK, I'm trying to read between the lines here. You want a *full* bug report,
that means you consider the initial report to be incomplete?
Seems I omitted the output of "gcc -v"
Was there other stuff missing?
I'll be sure to read https://gcc.gnu.org/bugs/ more closely.
this, and don't forget about:
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to
your bugreport.
I'm confused, because I did provide that part in the initial report.
(If you need to create a BZ account, please mail overseers and I'll
take care of that.)
Aaah, you want me to post the bug report to BZ, not here...
OK, I can do that. I've successfully created an account.
When you have a minute, can you take a look at my other message?
"Using Compound Literal + type-punning to initialize static const array"
You committed a patch that seems relevant just a few days ago. But the
documentation lead me to believe that the feature I was looking for had
been supported for a very long time (gcc 3.x at least)
Regards.
Re: ICE in 4.8.2 with compound literal
On 25/11/2014 10:27, Marek Polacek wrote:
On Tue, Nov 25, 2014 at 10:19:21AM +0100, Mason wrote:
Aaah, you want me to post the bug report to BZ, not here...
Yep - the snippet + command-line options you posted was enough to reproduce
the bug. The GCC mailing list is not for reporting bugs.
Gotcha.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64067
When you have a minute, can you take a look at my other message?
"Using Compound Literal + type-punning to initialize static const array"
You committed a patch that seems relevant just a few days ago. But the
documentation lead me to believe that the feature I was looking for had
been supported for a very long time (gcc 3.x at least)
I haven't read that in detail yet, but my patch just allowed the
initializing even for gnu99/gnu11 (formerly, it was only allowed in the
gnu89 mode).
Hmmm, then my test case incorrectly used gnu99.
Here's a simpler test case, using gnu89, producing the same error:
union foob { int val; struct { int X; } bits; };
static const int u = ((union foob) {.bits = { .X=42 }}).val;
$ gcc -std=gnu89 test.c
test.c:2:30: error: initializer element is not constant
static const int u = ((union foob) {.bits = { .X=42 }}).val;
Isn't this supposed to work? Or did I misunderstand the extension?
(Tell me if I should file a bug report.)
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-3
2
=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Regards.
__attribute__ aligned could be more efficient
Hello everyone,
Consider the following program.
#include
#include
struct foo1 { char s[80]; };
struct foo2 { char s[80]; } __attribute__ ((aligned (64)));
struct bar1 { struct foo1 f; int i; };
struct bar2 { struct foo2 f; int i; };
#define P(arg) printf("sizeof(" #arg ") = %u\n", (unsigned)sizeof(arg))
int main(void)
{
P(struct foo1);
P(struct foo2);
P(struct bar1); printf("offset=%u\n", (unsigned)offsetof(struct bar1, i));
P(struct bar2); printf("offset=%u\n", (unsigned)offsetof(struct bar2, i));
return 0;
}
$ gcc -O3 -Wall align.c
$ ./a.out
sizeof(struct foo1) = 80
sizeof(struct foo2) = 128
sizeof(struct bar1) = 84
offset=80
sizeof(struct bar2) = 192
offset=128
I didn't expect sizeof(struct bar2) to be 192.
gcc lays out bar2 like this:
foo2(80) padding(48) i(4) padding(60)
But it seems (to me) that gcc could fit the "int" field in the
first padding, to save space:
foo2(80) i(4) padding(44)
Is there a way to "cancel" the alignment request for foo2
in the bar2 definition? This doesn't work:
struct bar3 {
struct foo2 f __attribute__ ((aligned (4)));
int i;
} __attribute__ ((aligned (64)));
Regards.
Re: __attribute__ aligned could be more efficient
On 29/03/2015 17:35, Andreas Schwab wrote: > Mason wrote: > >> Consider the following program. [snip] > > This mailing list is about the development of gcc, for user questions > please use gcc-h...@gcc.gnu.org instead. Thanks, I will re-send my original message to gcc-help. Please be aware that the general tone of your answer could be perceived as somewhat aggressive and peremptory. Regards.
gcc generated memcpy calls symbol version
Hi, I've got a project here: https://github.com/wheybags/glibc_version_header which uses .symver directives to link to a specified version of glibc, so long as it's older than the version on your system. This works, but a problem I'm having is that gcc itself will sometimes insert calls to memcpy (or memmove, memset and memcmp), as documented here: https://gcc.gnu.org/onlinedocs/gcc/Standards.html When it does so, it doesn't respect the .symver directives, and uses the default version. Is there any way for me to force the version for these symbols aswell? I'm aware that I can disable the whole mechanism with -freestanding, but I don't want to cripple the optimiser. Regards, Tom Mason
Re: gcc generated memcpy calls symbol version
I'm not entirely sure I understand that issue. From what I understand, calls to a function in a shared library should always use the PLT? Also, I don't understand the purpose of applying hidden visibility to an extern symbol, But anyway, doesn't matter terribly much if I understand :p On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu wrote: > On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason wrote: > > Hi, > > I've got a project here: https://github.com/wheybags/ > glibc_version_header > > which uses .symver directives to link to a specified version of glibc, so > > long as it's older than the version on your system. > > This works, but a problem I'm having is that gcc itself will sometimes > > insert calls to memcpy (or memmove, memset and memcmp), as documented > here: > > https://gcc.gnu.org/onlinedocs/gcc/Standards.html > > When it does so, it doesn't respect the .symver directives, and uses the > > default version. > > Is there any way for me to force the version for these symbols aswell? > > I'm aware that I can disable the whole mechanism with -freestanding, but > I > > don't want to cripple the optimiser. > > I think this is related to: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 > > -- > H.J. >
Re: gcc generated memcpy calls symbol version
Actually, never mind, it's working fine: https://gist.github.com/wheybags/b7e4152daf76c72503e9e1f52f3dca3d and I have some other problem. On Fri, Jan 26, 2018 at 9:22 PM, H.J. Lu wrote: > On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason wrote: > > I'm not entirely sure I understand that issue. From what I understand, > calls > > to a function in a shared library should always use the PLT? > > Also, I don't understand the purpose of applying hidden visibility to an > > extern symbol, > > There is no need for PLT since hidden symbol is defined locally. But > GCC ignores hidden visibility for libcalls, like memcpy. If GCC treats > them like normal calls, your scheme and my testcase should work. > > > > But anyway, doesn't matter terribly much if I understand :p > > > > On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu wrote: > >> > >> On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason > wrote: > >> > Hi, > >> > I've got a project here: > >> > https://github.com/wheybags/glibc_version_header > >> > which uses .symver directives to link to a specified version of glibc, > >> > so > >> > long as it's older than the version on your system. > >> > This works, but a problem I'm having is that gcc itself will sometimes > >> > insert calls to memcpy (or memmove, memset and memcmp), as documented > >> > here: > >> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html > >> > When it does so, it doesn't respect the .symver directives, and uses > the > >> > default version. > >> > Is there any way for me to force the version for these symbols aswell? > >> > I'm aware that I can disable the whole mechanism with -freestanding, > but > >> > I > >> > don't want to cripple the optimiser. > >> > >> I think this is related to: > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 > >> > >> -- > >> H.J. > > > > > > > > -- > H.J. >
Re: gcc generated memcpy calls symbol version
Well, as I said, I was mistaken and the .symver directive does actually work for this, but the point of forcing the version is to provide a backwards compatible binary. If I compile with GCC on a modern system, it might generate a call to memcpy@GLIBC_2.14, so then that binary won't run on a system with glibc 2.13 installed. If I force it to an earlier version however, then it'll work just fine. On Jan 29, 2018 9:05 PM, "Andi Kleen" wrote: > Tom Mason writes: > > > Is there any way for me to force the version for these symbols aswell? > > It seems pointless because the ABI for these symbols will never change. > > -Andi >
(int *const) function parameter
Hello,
The following code is rejected by one compiler, while it is accepted by gcc
without any warning. Several people in comp.lang.c seem to think that it is a
bug in the first compiler which should ***not*** reject the program.
Message-ID:
http://groups.google.com/group/comp.lang.c/browse_frm/thread/2858a1c9ccdcd741
I'd like to ask what you think.
typedef int fun_t(int *p);
int foo1( int * p) { return *p; }
int foo2(const int * p) { return *p; }
int foo3( int *const p) { return *p; }
int foo4(const int *const p) { return *p; }
void zozo(void)
{
fun_t *fp;
fp = foo1;
fp = foo2; /* GCC WARNS */
fp = foo3;
fp = foo4; /* GCC WARNS */
}
(I run gcc 4.3.2 under cygwin.)
$ gcc -std=c89 -pedantic -Wall -Wextra -O2 -c mu2.c
mu2.c: In function 'zozo':
mu2.c:12: warning: assignment from incompatible pointer type
mu2.c:14: warning: assignment from incompatible pointer type
$ cc -c mu2.c
E "mu2.c",L12/C8(#416): foo2
|Type `int(const int * p)' ("mu2.c",L4/C5) can't be converted to type
`fun_t(*)'.
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).
E "mu2.c",L13/C8(#416): foo3
|Type `int(int *const p)' ("mu2.c",L5/C5) can't be converted to type
`fun_t(*)'.
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).
E "mu2.c",L14/C8(#416): foo4
|Type `int(const int *const p)' ("mu2.c",L6/C5) can't be converted to type
`fun_t(*)'.
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).
3 user errors No warnings
The relevant line is line 13 i.e. fp = foo3;
(cc's warnings are cosmetically different if I write fp = &foo3;)
E "mu2.c",L13/C8(#416):
|Type `int(*)(int *const p)' can't be converted to type `fun_t(*)'.
|(See also type `int(int *const p)' ("mu2.c",L5/C5)).
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).
In short, cc refuses to convert
an "int (*)(int *const)" pointer to an "int (*)(int *)" pointer.
Would you say this is a bug in cc?
--
Regards.
