Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 2011-12-10 02:21, Gleb Kurtsou wrote: Please find test case and test results attached. (gcc-test1.shar.txt) The long story short: only gcc-4.2 is affected, gcc 3.4, 4.4 and 4.6 are ok. clang is ok. (test-cc.txt) Nearly all of the workarounds I used in original test doesn't work in this test case (see #ifdef BAD_FIX in sources). gcc 4.2 fails even with -O1, it has nothing to do with -fno-omit-frame-pointer, finline-functions, etc. (test-cflags.txt) Compile with -DFIX1 to work around problem (replace struct assignment with memcpy): % make test XFLAGS=-O2 -DFIX1 rm -f gcc-test1 src1.o src2.o src3.o cc -O2 -DFIX1 -g -std=gnu99 -c src1.c cc -O2 -DFIX1 -g -std=gnu99 -c src2.c cc -O2 -DFIX1 -g -std=gnu99 -c src3.c cc -O2 -DFIX1 -g -std=gnu99-o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 ok Happy hacking! Hi Gleb, I did some bisecting, and I found the exact gcc trunk revision that fixes this bug: http://gcc.gnu.org/viewcvs?view=revisionrevision=119760 So far the good news, now the bad news: this revision is actually a merge from gcc's mem-ssa branch! The full diff is almost 10,000 lines... Also, although it's still under GPLv2, the diff doesn't apply cleanly to our version. :( ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 2011-12-08, at 17:53, Nathan Whitehorn wrote: On 12/08/11 03:01, Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478_mtx_unlock_spin_flags c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. I think that's a good idea. Even though we have managed to trigger this only in rare cases, the problem is real and the code generated is broken i.e. leads to corruption and panics. Rafal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
Hi, On Fri, Dec 9, 2011 at 10:15 AM, Rafal Jaworowski r...@semihalf.com wrote: On 2011-12-08, at 17:53, Nathan Whitehorn wrote: On 12/08/11 03:01, Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478_mtx_unlock_spin_flags c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlr r0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. I think that's a good idea. Even though we have managed to trigger this only in rare cases, the problem is real and the code generated is broken i.e. leads to corruption and panics. How can you make any conclusion without having seen a single line of code actually triggering the problem ? That sounds very irresponsible... - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (09/12/2011 16:15), Rafal Jaworowski wrote: On 2011-12-08, at 17:53, Nathan Whitehorn wrote: On 12/08/11 03:01, Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478_mtx_unlock_spin_flags c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. I think that's a good idea. Even though we have managed to trigger this only in rare cases, the problem is real and the code generated is broken i.e. leads to corruption and panics. -fno-omit-frame-pointer is there for kernel debugger to be able to generate backtraces. Hacking long abandoned gcc version won't get us far either. IMO we'd better concentrate on external toolchain support and clang. I wasn't able to come up with a small test case for the problem month ago, I'll try again once I have free time. Rafal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 9 Dec 2011 17:51, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Fri, Dec 9, 2011 at 10:15 AM, Rafal Jaworowski r...@semihalf.com wrote: On 2011-12-08, at 17:53, Nathan Whitehorn wrote: On 12/08/11 03:01, Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478_mtx_unlock_spin_flags c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. I think that's a good idea. Even though we have managed to trigger this only in rare cases, the problem is real and the code generated is broken i.e. leads to corruption and panics. How can you make any conclusion without having seen a single line of code actually triggering the problem ? That sounds very irresponsible... However, if he's right it's very clever. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Fri, Dec 9, 2011 at 1:15 PM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: -fno-omit-frame-pointer is there for kernel debugger to be able to generate backtraces. It's also needed by the DTrace stack() action, hwpmc callchain capture and stack(9). Disabling it as anything other than a very short-term bandaid is a non-starter. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
Please find test case and test results attached. (gcc-test1.shar.txt)
The long story short: only gcc-4.2 is affected, gcc 3.4, 4.4 and 4.6 are
ok. clang is ok. (test-cc.txt)
Nearly all of the workarounds I used in original test doesn't work in
this test case (see #ifdef BAD_FIX in sources).
gcc 4.2 fails even with -O1, it has nothing to do with
-fno-omit-frame-pointer, finline-functions, etc. (test-cflags.txt)
Compile with -DFIX1 to work around problem (replace struct assignment
with memcpy):
% make test XFLAGS=-O2 -DFIX1
rm -f gcc-test1 src1.o src2.o src3.o
cc -O2 -DFIX1 -g -std=gnu99 -c src1.c
cc -O2 -DFIX1 -g -std=gnu99 -c src2.c
cc -O2 -DFIX1 -g -std=gnu99 -c src3.c
cc -O2 -DFIX1 -g -std=gnu99-o gcc-test1 src1.o src2.o src3.o
/home/gleb/projects/gcc-test1/gcc-test1
ok
Happy hacking!
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# Makefile
# array.h
# debug.h
# hdr1.h
# src1.c
# src2.c
# src3.c
#
echo x - Makefile
sed 's/^X//' Makefile 'b67911656ef5d18c4ae36cb6741b7965'
XPROG= gcc-test1
XSRCS= src1.c src2.c src3.c hdr1.h
XNO_MAN=
X
XXFLAGS?=-O2 -fno-omit-frame-pointer
X
X#WARNS=6
X#NO_WERROR=
X
XSSP_CFLAGS=
XDEBUG_FLAGS= -g
XCSTD= gnu99
X
XCFLAGS= ${XFLAGS}
X
X.PHONY: test
Xtest: clean ${PROG}
X ${.OBJDIR}/${PROG}
X
X.include bsd.prog.mk
b67911656ef5d18c4ae36cb6741b7965
echo x - array.h
sed 's/^X//' array.h '3ff8e27b821109f0551768c5e1b6bc0d'
X#include debug.h
X
X#define ARRAY_HEAD(name, type, capacity) \
X struct name { \
X size_t arr_count; \
X struct type arr_items[capacity];\
X }
X
X#define ARRAY_INIT(head) do { \
X (head)-arr_count = 0; \
X} while (0)
X
X#define ARRAY_CAPACITY(head) \
X (sizeof((head)-arr_items) / sizeof((head)-arr_items[0]))
X
X#define ARRAY_COUNT(head) (head)-arr_count
X
X#ifdef FIX1
X
X#define ARRAY_INSERT_TAIL(head, elm) do { \
X ASSERT(ARRAY_COUNT((head)) ARRAY_CAPACITY((head))); \
X memcpy((head)-arr_items[(head)-arr_count++], (elm), sizeof(elm)); \
X} while (0)
X
X#else
X
X#define ARRAY_INSERT_TAIL(head, elm) do { \
X ASSERT(ARRAY_COUNT((head)) ARRAY_CAPACITY((head))); \
X (head)-arr_items[(head)-arr_count++] = (elm); \
X} while (0)
X
X#endif
X
X#define ARRAY_FOREACH(var, head) \
X for ((var) = (head)-arr_items[0]; \
X (var) (head)-arr_items[0] + (head)-arr_count; \
X (var)++)
3ff8e27b821109f0551768c5e1b6bc0d
echo x - debug.h
sed 's/^X//' debug.h '0483bb2079adc3936e07b79b224930aa'
X#ifndef XXX_DEBUG_H
X#define XXX_DEBUG_H
X
X#include stdarg.h
X
X#define ASSERT(cond) \
X (__predict_false(cond) ? (void)0 : \
X debug_assert(#cond, __FILE__, __LINE__, __func__))
X
Xvoid debug_assert(const char *msg, const char *file, int line,
Xconst char *func);
X
X#endif
0483bb2079adc3936e07b79b224930aa
echo x - hdr1.h
sed 's/^X//' hdr1.h '023696bd679b9970bb745000978348c8'
X#include stdbool.h
X
X#include array.h
X#include debug.h
X
Xtypedef union {
X struct {
X boolflag1:1;
X boolflag2:1;
X boolflag3:1;
X boolflag4:1;
X boolflag5:1;
X boolflag6:1;
X boolflag7:1;
X boolflag8:1;
X boolflag9:1;
X boolflag10:1;
X };
X uint32_tbits;
X} xflags_t;
X
Xstruct session {
X xflags_t flags;
X struct sockaddr_in addr;
X};
X
Xstruct dummy1 {
X int a, b, c;
X void *ptr;
X};
X
XARRAY_HEAD(addr_list, sockaddr_in, 2);
X
Xstruct addr_list;
X
Xvoid test_fail(void *arg1, void *arg2,
Xvoid *arg3, const void *arg4,
Xconst struct addr_list *addr_list,
Xconst void *arg5);
X
Xbool test_run(struct session *sess);
023696bd679b9970bb745000978348c8
echo x - src1.c
sed 's/^X//' src1.c 'd76eceed15fcbc6c2cf5da795270acb3'
X#include sys/param.h
X#include sys/socket.h
X#include netinet/in.h
X
X#include stdio.h
X#include stdlib.h
X#include string.h
X
X#include hdr1.h
X
Xstatic void test_set_dummy(struct dummy1 *arg1, void *arg2);
X
Xbool
Xtest_run(struct session *sess)
X{
X struct dummy1 d1 __unused;
X struct addr_list tmp_addr_list;
X struct
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 2011-12-07, at 21:28, Arnaud Lacombe wrote: Hi, On Sat, Nov 19, 2011 at 5:01 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 this PR seems highly irrelevant, the cause has been identified to a commit made in mid-2010, that's 3 years older than gcc in base. I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. at least, can you share the testcase and miscompilation details ? I believe we suffer from a very similar issue on PowerPC as well, we'll provide detailed information shortly. Rafal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (08/12/2011 10:01), Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478 _mtx_unlock_spin_flags c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Adding -finline-functions fixed/masked issue for me. Unfortunately building kernel with -finline-functions is not supported. You can try tweaking conf/files to change build options for this file only. Issue not sra-related, but sra is also known to be buggy in gcc 4.2. Regards, Piotr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478 _mtx_unlock_spin_flags c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Regards, Piotr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 12/08/11 03:01, Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478_mtx_unlock_spin_flags c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sat, 19 Nov 2011 12:01:50 +0200 Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Thanks, Gleb. ___ It should take about ten times less time than this thread took already to isolate _short_ test case demonstrating the problem, yet nothing of the sort has shown up yet from anyone involved. Am I missing something? -- Alexander Kabaev signature.asc Description: PGP signature
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
Hi, On Sat, Nov 19, 2011 at 5:01 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 this PR seems highly irrelevant, the cause has been identified to a commit made in mid-2010, that's 3 years older than gcc in base. I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. at least, can you share the testcase and miscompilation details ? Thanks, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sat, 19 Nov 2011 12:01:50 +0200 Gleb Kurtsou gleb.kurt...@gmail.com mentioned: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Hi! I'm not sure this is relevant to your case, but our base gcc used to have a bug with strict aliasing, which was fixed only in a GPLv3 version of it. That's why we have -fno-strict-aliasing in default CFALGS. So you might try to build using -fno-strict-aliasing. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpuO922JsvHw.pgp Description: PGP signature
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (02/12/2011 01:56), Stanislav Sedov wrote: On Sat, 19 Nov 2011 12:01:50 +0200 Gleb Kurtsou gleb.kurt...@gmail.com mentioned: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Hi! I'm not sure this is relevant to your case, but our base gcc used to have a bug with strict aliasing, which was fixed only in a GPLv3 version of it. That's why we have -fno-strict-aliasing in default CFALGS. So you might try to build using -fno-strict-aliasing. I always have -fno-strict-aliasing, the whole idea of misusing undefined behaviour to perform optimization is crazy. I guess it seemed evident to me so I've skipped the flag above. Besides gcc was barking with aliasing warnings on 3rd party party code in my case, I had to change warnings flags to run tests without -fno-strict-aliasing. I've dropped -fno-omit-frame-pointer, async unwind tables are ok for userland. Another work around was adding -finline-functions. Kernel and modules won't build with -finline-functions. So we are just lucky not to catch it. Thanks, Gleb. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (19/11/2011 09:11), m...@freebsd.org wrote: On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On (19/11/2011 07:26), m...@freebsd.org wrote: On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. How small are the structs? gcc has an optimization for structs that are no larger than a register, but it's buggy in 4.2 and we disabled it at $WORK. I can dig up the patch if this is the problem. struct sockaddr_in in this particular test. 16 bytes. Register size structs are rather common, e.g. struct in_addr. I could test the patch. Adding -finline-functions seems to fix the issue for me. I can't find the thing I'm thinking of. The only potentially relevant patch I see in our gcc sources is this: It could be related but doesn't fix bug I observe. I've installed fresh 9.0-RC2 virtual machine and reran tests in clean environment. Do you plan committing it? Index: opts.c === --- opts.c(.../vendor.branches/freebsd/stable/7/src/contrib/gcc/opts.c) (revision 211574) +++ opts.c(.../head/src/contrib/gcc/opts.c) (revision 211574) @@ -457,11 +457,7 @@ flag_tree_dse = 1; flag_tree_ter = 1; flag_tree_live_range_split = 1; + /** + * 7dot1MERGE: tree-sra in gcc 4.2.x is buggy and + * breaks bitfield structs. + */ + flag_tree_sra = 0; - flag_tree_sra = 1; flag_tree_copyrename = 1; flag_tree_fre = 1; flag_tree_copy_prop = 1; Thanks, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (20/11/2011 01:57), Alexander Best wrote: On Sat Nov 19 11, Gleb Kurtsou wrote: On (19/11/2011 12:25), Alexander Best wrote: On Sat Nov 19 11, Gleb Kurtsou wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy does the issue also come up with '-fno-builtin' in addition to those flags? is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist when using -O1 and -O3? -O0 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -Os -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -O -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O1 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-builtin -fno-strict-aliasing -- BAD -O3 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK!! -O3 -fno-inline-functions -fno-unswitch-loops -fno-gcse-after-reload -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O3 -fno-inline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -finline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK btw: for any optimisation -O1, -fno-strict-aliasing isn't needed, since it gets added automatically (see sys/conf/kern.pre.mk). For kernel builds. I'm building 3rd party software with base system compiler. On the other hand kernel and modules are built with -O2 -fno-omit-frame-pointer.. cheers. alex So, it's -finline-functions that makes it work. But I'm afraid it just masks the real problem. The rest of CFLAGS is warnings and includes: -D_GNU_SOURCE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wno-write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -Wstrict-aliasing=2 -Wno-error=strict-aliasing cheers. alex I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Thanks, Gleb. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sun Nov 20 11, Gleb Kurtsou wrote: On (20/11/2011 01:57), Alexander Best wrote: On Sat Nov 19 11, Gleb Kurtsou wrote: On (19/11/2011 12:25), Alexander Best wrote: On Sat Nov 19 11, Gleb Kurtsou wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy does the issue also come up with '-fno-builtin' in addition to those flags? is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist when using -O1 and -O3? -O0 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -Os -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -O -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O1 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-builtin -fno-strict-aliasing -- BAD -O3 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK!! -O3 -fno-inline-functions -fno-unswitch-loops -fno-gcse-after-reload -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O3 -fno-inline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -finline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK btw: for any optimisation -O1, -fno-strict-aliasing isn't needed, since it gets added automatically (see sys/conf/kern.pre.mk). For kernel builds. I'm building 3rd party software with base system compiler. On the other hand kernel and modules are built with -O2 -fno-omit-frame-pointer.. right. was was i thinking. ;) sorry for the noise. cheers. alex cheers. alex So, it's -finline-functions that makes it work. But I'm afraid it just masks the real problem. The rest of CFLAGS is warnings and includes: -D_GNU_SOURCE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wno-write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -Wstrict-aliasing=2 -Wno-error=strict-aliasing cheers. alex I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Thanks, Gleb. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sun, Nov 20, 2011 at 10:24 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On (19/11/2011 09:11), m...@freebsd.org wrote: On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On (19/11/2011 07:26), m...@freebsd.org wrote: On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. How small are the structs? gcc has an optimization for structs that are no larger than a register, but it's buggy in 4.2 and we disabled it at $WORK. I can dig up the patch if this is the problem. struct sockaddr_in in this particular test. 16 bytes. Register size structs are rather common, e.g. struct in_addr. I could test the patch. Adding -finline-functions seems to fix the issue for me. I can't find the thing I'm thinking of. The only potentially relevant patch I see in our gcc sources is this: It could be related but doesn't fix bug I observe. I've installed fresh 9.0-RC2 virtual machine and reran tests in clean environment. Do you plan committing it? We probably should, but I haven't heard that anyone else has had a problem with this. I'm sure when I do the next FreeBSD merge at $WORK I'll re-remember it and probably commit it then. Thanks, matthew Index: opts.c === --- opts.c (.../vendor.branches/freebsd/stable/7/src/contrib/gcc/opts.c) (revision 211574) +++ opts.c (.../head/src/contrib/gcc/opts.c) (revision 211574) @@ -457,11 +457,7 @@ flag_tree_dse = 1; flag_tree_ter = 1; flag_tree_live_range_split = 1; + /** + * 7dot1MERGE: tree-sra in gcc 4.2.x is buggy and + * breaks bitfield structs. + */ + flag_tree_sra = 0; - flag_tree_sra = 1; flag_tree_copyrename = 1; flag_tree_fre = 1; flag_tree_copy_prop = 1; Thanks, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sat Nov 19 11, Gleb Kurtsou wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy does the issue also come up with '-fno-builtin' in addition to those flags? is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist when using -O1 and -O3? cheers. alex I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Thanks, Gleb. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (19/11/2011 12:25), Alexander Best wrote: On Sat Nov 19 11, Gleb Kurtsou wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy does the issue also come up with '-fno-builtin' in addition to those flags? is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist when using -O1 and -O3? -O0 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -Os -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -O -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O1 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-builtin -fno-strict-aliasing -- BAD -O3 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK!! -O3 -fno-inline-functions -fno-unswitch-loops -fno-gcse-after-reload -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O3 -fno-inline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -finline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK So, it's -finline-functions that makes it work. But I'm afraid it just masks the real problem. The rest of CFLAGS is warnings and includes: -D_GNU_SOURCE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wno-write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -Wstrict-aliasing=2 -Wno-error=strict-aliasing cheers. alex I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Thanks, Gleb. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. How small are the structs? gcc has an optimization for structs that are no larger than a register, but it's buggy in 4.2 and we disabled it at $WORK. I can dig up the patch if this is the problem. Thanks, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On (19/11/2011 07:26), m...@freebsd.org wrote: On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. How small are the structs? gcc has an optimization for structs that are no larger than a register, but it's buggy in 4.2 and we disabled it at $WORK. I can dig up the patch if this is the problem. struct sockaddr_in in this particular test. 16 bytes. Register size structs are rather common, e.g. struct in_addr. I could test the patch. Adding -finline-functions seems to fix the issue for me. Thanks, Gleb. Thanks, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On (19/11/2011 07:26), m...@freebsd.org wrote: On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. How small are the structs? gcc has an optimization for structs that are no larger than a register, but it's buggy in 4.2 and we disabled it at $WORK. I can dig up the patch if this is the problem. struct sockaddr_in in this particular test. 16 bytes. Register size structs are rather common, e.g. struct in_addr. I could test the patch. Adding -finline-functions seems to fix the issue for me. I can't find the thing I'm thinking of. The only potentially relevant patch I see in our gcc sources is this: Index: opts.c === --- opts.c (.../vendor.branches/freebsd/stable/7/src/contrib/gcc/opts.c) (revision 211574) +++ opts.c (.../head/src/contrib/gcc/opts.c) (revision 211574) @@ -457,11 +457,7 @@ flag_tree_dse = 1; flag_tree_ter = 1; flag_tree_live_range_split = 1; + /** + * 7dot1MERGE: tree-sra in gcc 4.2.x is buggy and + * breaks bitfield structs. + */ + flag_tree_sra = 0; - flag_tree_sra = 1; flag_tree_copyrename = 1; flag_tree_fre = 1; flag_tree_copy_prop = 1; Thanks, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On Sat Nov 19 11, Gleb Kurtsou wrote: On (19/11/2011 12:25), Alexander Best wrote: On Sat Nov 19 11, Gleb Kurtsou wrote: Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy does the issue also come up with '-fno-builtin' in addition to those flags? is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist when using -O1 and -O3? -O0 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -Os -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -O -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O1 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-builtin -fno-strict-aliasing -- BAD -O3 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK!! -O3 -fno-inline-functions -fno-unswitch-loops -fno-gcse-after-reload -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O3 -fno-inline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -finline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK btw: for any optimisation -O1, -fno-strict-aliasing isn't needed, since it gets added automatically (see sys/conf/kern.pre.mk). cheers. alex So, it's -finline-functions that makes it work. But I'm afraid it just masks the real problem. The rest of CFLAGS is warnings and includes: -D_GNU_SOURCE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wno-write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -Wstrict-aliasing=2 -Wno-error=strict-aliasing cheers. alex I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Thanks, Gleb. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
