[Bug c/61756] New: arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

[Bug c/61756] New: arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

[robertgjenssen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756

            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=33093&action=edit
sh script to build arm-none-eabi binutils, newlib and arm-none-eabi-gcc-4.10.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 <stdatomic.h>

static volatile atomic_flag guard = 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=c11 -O0 -g
-mcpu=arm7tdmi -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=c11 -O0 -g
-mcpu=arm7tdmi -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 ‘try_atomic_flag_test_and_set’:
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 <http://gcc.gnu.org/bugs.html> for instructions.

Here is tt.i:

# 1 "tt.c"
# 1 "/home/robj/TMP//"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "tt.c"
# 1
"/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomic.h"
1 3 4
# 29
"/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomic.h"
3 4
typedef enum
  {
    memory_order_relaxed = 0,
    memory_order_consume = 1,
    memory_order_acquire = 2,
    memory_order_release = 3,
    memory_order_acq_rel = 4,
    memory_order_seq_cst = 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/stdatomic.h"
3 4
typedef _Atomic struct
{

  _Bool __val;



} atomic_flag;
# 2 "tt.c" 2

static volatile atomic_flag guard = { 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: <gcc-bugs-return-455929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.gnu.org>
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: <bug-55561-4-gUzLztLvXP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55561-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55561-4@http.gcc.gnu.org/bugzilla/>
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?idU561

--- Comment #53 from Dmitry Vyukov <dvyukov at google dot com> ---
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.

[Bug target/61756] arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Target|                            |arm*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-07-09
                 CC|                            |ktkachov at gcc dot gnu.org
     Ever confirmed|0                           |1
      Known to fail|                            |4.10.0, 4.9.1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

Fails on 4.9 and 4.10 trunk.
4.8 doesn't accept this code:
  error: expected specifier-qualifier-list before 'int_least8_t'
 typedef _Atomic(int_least8_t)  atomic_int_least8_t;
         ^


-O0  -march=armv6 are the options needed to reproduce this.
Any architecture level at armv6 and below will cause this.

[Bug target/61756] arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I'll take it.

[Bug target/61756] arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Turns out this is a duplicate of 61713.
Moving the discussion there...

*** This bug has been marked as a duplicate of bug 61713 ***