ICE in 4.8.2 with compound literal

2014-11-25 Thread Mason
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

Re: ICE in 4.8.2 with compound literal

2014-11-25 Thread Mason
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

Re: ICE in 4.8.2 with compound literal

2014-11-25 Thread Mason
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

__attribute__ aligned could be more efficient

2015-03-29 Thread Mason
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)si

Re: __attribute__ aligned could be more efficient

2015-03-29 Thread Mason
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-h

gcc generated memcpy calls symbol version

2018-01-26 Thread Tom Mason
re 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

2018-01-26 Thread Tom Mason
: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

Re: gcc generated memcpy calls symbol version

2018-01-27 Thread Tom Mason
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 understa

Re: gcc generated memcpy calls symbol version

2018-01-30 Thread Tom Mason
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 see

(int *const) function parameter

2009-08-14 Thread Marc Mason
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/