From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25916 invoked by alias); 9 Jul 2014 07:30:55 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 25838 invoked by uid 48); 9 Jul 2014 07:30:47 -0000 From: "robertgjenssen at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/61756] New: arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag Date: Wed, 09 Jul 2014 07:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: robertgjenssen at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00519.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61756 Bug ID: 61756 Summary: arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: robertgjenssen at gmail dot com Created attachment 33093 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D33093&action=3Dedit sh script to build arm-none-eabi binutils, newlib and arm-none-eabi-gcc-4.1= 0.0 1. uname -a: Linux morgawr 3.15.3-200.fc20.x86_64 #1 SMP Tue Jul 1 16:18:00 UTC 2014 x86= _64 x86_64 x86_64 GNU/Linux 2. Construct an arm-none-eabi-gcc toolchain with the attached script, build-arm-toolchain.sh 3. Compile the following code (tt.c): #include static volatile atomic_flag guard =3D ATOMIC_FLAG_INIT; void try_atomic_flag_test_and_set(void) { atomic_flag_test_and_set(&guard); } with: arm-toolchain/bin/arm-none-eabi-gcc-4.10.0 -c -o obj/tt.o -std=3Dc11 -O0 -g -mcpu=3Darm7tdmi -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -save-temps tt.c and get: $ arm-toolchain/bin/arm-none-eabi-gcc-4.10.0 -c -o obj/tt.o -std=3Dc11 -O0 = -g -mcpu=3Darm7tdmi -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -save-temps tt.c In file included from tt.c:3:0: tt.c: In function =E2=80=98try_atomic_flag_test_and_set=E2=80=99: tt.c:9:3: internal compiler error: in emit_move_insn, at expr.c:3575 atomic_flag_test_and_set(&guard); ^ 0x7074a3 emit_move_insn(rtx_def*, rtx_def*) ../../gcc-4.10-20140706/gcc/expr.c:3574 0x8d3d74 expand_atomic_test_and_set(rtx_def*, rtx_def*, memmodel) ../../gcc-4.10-20140706/gcc/optabs.c:7355 0x60f094 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc-4.10-20140706/gcc/builtins.c:6739 0x700b62 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc-4.10-20140706/gcc/expr.c:10344 0x62d48f expand_expr ../../gcc-4.10-20140706/gcc/expr.h:451 0x62d48f expand_call_stmt ../../gcc-4.10-20140706/gcc/cfgexpand.c:2307 0x62d48f expand_gimple_stmt_1 ../../gcc-4.10-20140706/gcc/cfgexpand.c:3202 0x62d48f expand_gimple_stmt ../../gcc-4.10-20140706/gcc/cfgexpand.c:3354 0x62e4bd expand_gimple_basic_block ../../gcc-4.10-20140706/gcc/cfgexpand.c:5192 0x62ff8d execute ../../gcc-4.10-20140706/gcc/cfgexpand.c:5799 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Here is tt.i: # 1 "tt.c" # 1 "/home/robj/TMP//" # 1 "" # 1 "" # 1 "tt.c" # 1 "/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomi= c.h" 1 3 4 # 29 "/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomi= c.h" 3 4 typedef enum { memory_order_relaxed =3D 0, memory_order_consume =3D 1, memory_order_acquire =3D 2, memory_order_release =3D 3, memory_order_acq_rel =3D 4, memory_order_seq_cst =3D 5 } memory_order; typedef _Atomic _Bool atomic_bool; typedef _Atomic char atomic_char; typedef _Atomic signed char atomic_schar; typedef _Atomic unsigned char atomic_uchar; typedef _Atomic short atomic_short; typedef _Atomic unsigned short atomic_ushort; typedef _Atomic int atomic_int; typedef _Atomic unsigned int atomic_uint; typedef _Atomic long atomic_long; typedef _Atomic unsigned long atomic_ulong; typedef _Atomic long long atomic_llong; typedef _Atomic unsigned long long atomic_ullong; typedef _Atomic short unsigned int atomic_char16_t; typedef _Atomic long unsigned int atomic_char32_t; typedef _Atomic unsigned int atomic_wchar_t; typedef _Atomic signed char atomic_int_least8_t; typedef _Atomic unsigned char atomic_uint_least8_t; typedef _Atomic short int atomic_int_least16_t; typedef _Atomic short unsigned int atomic_uint_least16_t; typedef _Atomic long int atomic_int_least32_t; typedef _Atomic long unsigned int atomic_uint_least32_t; typedef _Atomic long long int atomic_int_least64_t; typedef _Atomic long long unsigned int atomic_uint_least64_t; typedef _Atomic int atomic_int_fast8_t; typedef _Atomic unsigned int atomic_uint_fast8_t; typedef _Atomic int atomic_int_fast16_t; typedef _Atomic unsigned int atomic_uint_fast16_t; typedef _Atomic int atomic_int_fast32_t; typedef _Atomic unsigned int atomic_uint_fast32_t; typedef _Atomic long long int atomic_int_fast64_t; typedef _Atomic long long unsigned int atomic_uint_fast64_t; typedef _Atomic int atomic_intptr_t; typedef _Atomic unsigned int atomic_uintptr_t; typedef _Atomic unsigned int atomic_size_t; typedef _Atomic int atomic_ptrdiff_t; typedef _Atomic long long int atomic_intmax_t; typedef _Atomic long long unsigned int atomic_uintmax_t; # 232 "/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomi= c.h" 3 4 typedef _Atomic struct { _Bool __val; } atomic_flag; # 2 "tt.c" 2 static volatile atomic_flag guard =3D { 0 }; void try_atomic_flag_test_and_set(void) { __atomic_test_and_set ((&guard), 5); } >>From gcc-bugs-return-455929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 09 07:36:40 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 31256 invoked by alias); 9 Jul 2014 07:36:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 30727 invoked by uid 48); 9 Jul 2014 07:36:33 -0000 From: "dvyukov at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp Date: Wed, 09 Jul 2014 07:36:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dvyukov at google dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00520.txt.bz2 Content-length: 1162 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #53 from Dmitry Vyukov --- If we instrument libgomp with tsan, this can introduce lots of extraneous synchronization which is useful only for verification of libgomp itself, but harmful for libgomp users (as it will lead to false positives). What can be useful (but not top priority if nobody complains) is to insert some manual annotations for tsan into libgomp. I don't know enough about libgomp internals and have not used libgomp+tsan, so don't know what exactly they must do. But potentially they can do: 1. Tell tsan about accesses to user memory. I.e. if libgomp still accesses some user memory in some cases, then can tell tsan about that. 2. Tell tsan about precise synchronization model for user. E.g. I suspect that interactions with scheduler in parallel for construct synchronize all user threads (if the scheduler calls pthread_mutex_lock/unlock); this synchronization can lead to false positives in user programs. We can suppress that synchronization and instead tell tsan what is the documented synchronization guarantees for user. 3. Improve reports.