[Bug go/60406] New: reflect.go:test13reflect2 test failure

[Bug go/60406] New: reflect.go:test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406

            Bug ID: 60406
           Summary: reflect.go:test13reflect2 test failure
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: vogt at linux dot vnet.ibm.com

>From a email discussion between me (DV) and Ian Lance Taylor (IT):

DV: The bug shows up when running recover.go from the go testsuite
DV: in the function test13reflect2 (and test14reflect2).
DV:
DV: When panic is called, the deferred reflection function is invoked
DV: by calling the thunk function.  (See below for the assembly code
DV: on s390).  The call to __go_set_defer_retaddr is passed the address
DV: of a label that was generated originally right behind the call to
DV: makeFuncStub, and the fake jump is there to make sure the
DV: automatically generated label does not get deleted during
DV: compilation.  However, in the assembler code a different address
DV: is passed to __go_set_defer_retaddr that the target address of the
DV: fake jump:
DV:
DV: -- snip assembler code --
DV:   0000000080002490 <main.$thunk0>:
DV:     ...
DV:     8000249e:  larl  %r2,800024f4 <main.$thunk0+0x64> -------
DV:     800024a4:  brasl %r14,80002c48 <__go_set_defer_retaddr>  |
DV:     800024aa:  tmll  %r2,255                                 |
DV:     # fake jump                                              |
DV:     800024ae:  jne   80002500 <main.$thunk0+0x70> --------   |
DV:     800024b2:  ltgr  %r13,%r13                            |  |
DV:     ...                                                   |  |
DV:     # code that copies T5                                 |  |
DV:     800024de:  lghi  %r3,31                               |  |
DV:     800024e2:  mvc   0(256,%r2),0(%r1)                    |  |
DV:     800024e8:  la    %r2,256(%r2)                         |  |
DV:     800024ec:  la    %r1,256(%r1)                         |  |
DV:     800024f0:  brctg %r3,800024e2 <main.$thunk0+0x52>     |  |
DV:     # wrong position of split label                       |  |
DV:     800024f4:  mvc   0(256,%r2),0(%r1)            <-------|--
DV:     800024fa:  la    %r2,160(%r15)                        |
DV:     # call makeFuncStub                                   |
DV:     800024fe:  basr  %r14,%r13  <--- makeFuncStub         |
DV:     # original position of the label "retaddr"            |
DV:     80002500:  lghi  %r2,0                        <-------
DV:     ...
DV: -- snip --
DV:
DV: The code in libgo/runtime/go-recover.c:__go_can_recover tests
DV: whether the address passed to __go_set_defer_retaddr is in a
DV: certain range around the the real return address of makeFuncStub:
DV:
DV:   if (ret <= dret && ret + 16 >= dret)
DV:     return 1;
DV:
DV: In the above assembly language code the assumption that the defer
DV: retaddr will always end up in that range is violated.  Thus,
DV: __go_can_recover returns 0, the panic is not recovered and the test
DV: case fails.
DV:
DV: --
DV:
DV: There are two problems in the current code.  First, the assumption
DV: in __go_can_recover is too strict.  I think the "correct" test
DV: would be to check whether dret is inside the thunk function, i.e.
DV:
DV:   if (dret >= thunk_start && dret < thunk_end)
DV:     return 1;

IT: Yes.


DV: Except that thunk_start and thunk_end are not easily available at
DV: that place.


IT: Well, we could get thunk_start fairly easily: we could pass it to
IT: __go_set_defer_retaddr, just as we currently pass the return label.  I
IT: can't think of a reliable way for us to get thunk_end, though.


DV: Second, the code ("hack") in gcc/go/gofrontend/statementis.cc:build_thunk()
DV: simply does not work:
DV:
DV: -- snip --
DV:   // For a defer statement, start with a call to
DV:   // __go_set_defer_retaddr.  */
DV:   Label* retaddr_label = NULL;
DV:   if (may_call_recover)
DV:     {
DV:       retaddr_label = gogo->add_label_reference("retaddr", location,
false);
DV:       Expression* arg = Expression::make_label_addr(retaddr_label,
location);
DV:       Expression* call = Runtime::make_call(Runtime::SET_DEFER_RETADDR,
DV:                                             location, 1, arg);
DV:
DV:       // This is a hack to prevent the middle-end from deleting the
DV:       // label.
DV:       gogo->start_block(location);
DV:       gogo->add_statement(Statement::make_goto_statement(retaddr_label,
DV:                                                          location));
DV:       ...
DV:     }
DV:
DV:   ...
DV:
DV:   // If this is a defer statement, the label comes immediately after
DV:   // the call.
DV:   if (may_call_recover)
DV:     {
DV:       gogo->add_label_definition("retaddr", location);
DV:       ...
DV:     }
DV: -- snip --
DV:
DV: The address of the label "retaddr" is passed to
DV: __go_set_defer_retaddr and then a fake jump to that label is
DV: inserted after that (fake because __go_set_defer_retaddr always
DV: returns 0).  Although the fake jump does prevent the label of the
DV: jump target from being deleted, it does not help keeping the label
DV: at the passed address alive.  What actually happens is this:
DV:
DV:  * At first, the call and the jump both use the retaddr label.
DV:  * After the cprop1 pass, the cfgcleanup pass calls
DV:    try_forward_edges().
DV:  * try_forward_edges() decides that the edge described by the jump
DV:    can be forwarded to some other place.  So, it creates a new
DV:    label at the new jump target and redirects the jump there.
DV:    Then it tries to delete the label (cfgrtl.c:delete_insn()) and
DV:    notices it's a user generated label that cannot be deleted.
DV:    Instead, the label is replaced by a NOTE_DELETED_LABEL_NAME to
DV:    keep the address reference alive.  We now have _two_ labels,
DV:    the new, live one and the old deleted one.
DV:  * The following passes move the deleted label around the function
DV:    and it ends up in a more or less random location inside the
DV:    thunk function.  (Actually, where it ends up depends on the
DV:    amount of code that is needed to copy T5.  If T5 is small
DV:    enough that it can be copied without a loop, the test succeeds.)
DV:
DV: In other words, when the edge is forwarded, only jumps to the
DV: target label are forwarded but not simple references to the
DV: address of the label.  I'm not sure whether this is a Gcc bug or
DV: not.

IT: The design assumes that the thunk is very simple, which it normally
IT: is.  A simple thunk won't have any basic blocks so the problematic
IT: optimization won't kick in.  I think that assumption is failing in
IT: this case because the function argument is so large.  The large
IT: argument is introducing a loop and thus permitting basic block
IT: optimizations to occur.
IT:
IT: I suppose we could introduce yet another thunk, and pass along the
IT: pointer to the parameters, rather than expanding them.  That is
IT: getting pretty horrible, though.  It would be better to use
IT: thunk_start and thunk_end as you suggest above, if we can figure out
IT: how to do it.

--

DV: To get the thunk address and length, the correct approach is
DV: probably to utilize the DWARF info, ...

IT: To get the thunk address I would suggest just changing the Go
IT: frontend to pass it to __go_defer_set_retaddr.
IT:
IT: I have no particular suggestions for the thunk length.  There may
IT: be some relatively simple way to pick that up as well.

[Bug go/60406] recover.go: test13reflect2 test failure

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|reflect.go:test13reflect2   |recover.go: test13reflect2
                   |test failure                |test failure

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Corrected Summary.
>From gcc-bugs-return-457907-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 06 17:07:02 2014
Return-Path: <gcc-bugs-return-457907-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19453 invoked by alias); 6 Aug 2014 17:07:01 -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 19316 invoked by uid 48); 6 Aug 2014 17:06:48 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/62023] [4.10 regression] 30_threads/condition_variable_any/50862.cc FAILs
Date: Wed, 06 Aug 2014 17:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62023-4-mGWpmQoM6J@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62023-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62023-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-08/txt/msg00404.txt.bz2
Content-length: 422

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb023

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Which means the __gthread_active_p() function in libgcc/gthr-posix.h is
> returning false

Looks like there's a Solaris-specific version of __gthread_active_p, but I
can't think why marking it as DECL_COMDAT would break things.  Let me know what
you find.

[Bug go/60406] recover.go: test13reflect2 test failure

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
It looks that a hack, mentioned in Comment #0 should use asm goto instead of
goto. The following test:

--cut here--
extern void foo (void *);

int test_bad (int p1, int p2)
{
  __label__ bla1;

  foo (&&bla1);
  goto bla1;
 bla1:
  return 0;
}

int test_good (int p1, int p2)
{
  __label__ bla2;

  foo (&&bla2);
  asm goto ("" :::: bla2);
 bla2:
  return 0;
}
--cut here--

results in (-O2):

test_good:
        subl    $28, %esp
        movl    $.L5, (%esp)
        call    foo
.L6:
.L5:
        xorl    %eax, %eax
        addl    $28, %esp
        ret

which is much better than:

test_bad:
.L2:
        subl    $28, %esp
        movl    $.L2, (%esp)
        call    foo
        xorl    %eax, %eax
        addl    $28, %esp
        ret

Also checked on alpha:

test_good:
        .frame $30,16,$26,0
        .mask 0x4000000,-16
$LFB1:
        .cfi_startproc
        ldah $29,0($27)         !gpdisp!4
        lda $29,0($29)          !gpdisp!4
$test_good..ng:
        lda $30,-16($30)
        .cfi_def_cfa_offset 16
        cpys $f31,$f31,$f31
        ldah $16,$L4($29)               !gprelhigh
        ldq $27,foo($29)                !literal!5
        stq $26,0($30)
        .cfi_offset 26, -16
        .prologue 1
        lda $16,$L4($16)                !gprellow
        jsr $26,($27),foo               !lituse_jsr!5
        ldah $29,0($26)         !gpdisp!6
        lda $29,0($29)          !gpdisp!6
        .align 3 #realign
$L5:
$L4:
        mov $31,$0
        ldq $26,0($30)
        lda $30,16($30)
        .cfi_restore 26
        .cfi_def_cfa_offset 0
        ret $31,($26),1

Please note, that the check will still need some tolerance due to various label
alignment requirements, additional instructions, etc:

  5c:   00 00 10 22     lda     a0,0(a0)
                        5c: GPRELLOW    .text+0x70              <- label loc
  60:   00 40 5b 6b     jsr     ra,(t12),64 <test_good+0x24>
                        60: LITUSE      .text+0x3
                        60: HINT        foo
  64:   00 00 ba 27     ldah    gp,0(ra)                        <- retaddr
                        64: GPDISP      .text+0x4
  68:   00 00 bd 23     lda     gp,0(gp)
  6c:   00 00 fe 2f     unop
  70:   00 04 ff 47     clr     v0
>From gcc-bugs-return-457943-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 07 09:18:23 2014
Return-Path: <gcc-bugs-return-457943-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23577 invoked by alias); 7 Aug 2014 09:18:22 -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 23533 invoked by uid 48); 7 Aug 2014 09:18:16 -0000
From: "finis at in dot tum.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62011] False Data Dependency in popcnt instruction
Date: Thu, 07 Aug 2014 09:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: finis at in dot tum.de
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: cc
Message-ID: <bug-62011-4-M4NzaAe2r9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62011-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62011-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-08/txt/msg00440.txt.bz2
Content-length: 782

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb011

finis at in dot tum.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |finis at in dot tum.de

--- Comment #4 from finis at in dot tum.de ---

> Not sure if we want to
> disable popcnt use completely.

No matter how to fix this, do not disable popcnt! Even with the false
dependency it is still the fastest instruction for popcounting. The false
dependency makes it slower, but it is still faster than a hand written version.

The easiest fix IMHO would be using xor %r %r on the output register. It seems
to work extremely well, as you can see in the answer of the linked SO question.

[Bug go/60406] recover.go: test13reflect2 test failure

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
Alternatively, since __go_set_defer_retaddr always returns 0, we can prevent
split of the label by enclosing it in asm volatiles:

extern int foo (void *);
extern void bar (void);

int test_1 (void)
{
  __label__ bla1;

  if (foo (&&bla1))
    goto bla1;

  asm volatile ("");
  bar ();
 bla1:
  asm volatile ("");

  return 0;
}

test_1:
        subl    $28, %esp
        movl    $.L2, (%esp)
        call    foo
        testl   %eax, %eax
        jne     .L2
        call    bar
.L2:
        xorl    %eax, %eax
        addl    $28, %esp
        ret

'goto label' can also be substituted with 'asm goto ("" :::: label)', but I
don't think this is necessary in the above case.
>From gcc-bugs-return-457955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 07 10:41:54 2014
Return-Path: <gcc-bugs-return-457955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20256 invoked by alias); 7 Aug 2014 10:41:53 -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 20216 invoked by uid 48); 7 Aug 2014 10:41:49 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/62047] New: --coverage segfault in libcilkrts
Date: Thu, 07 Aug 2014 10:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
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
Message-ID: <bug-62047-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-08/txt/msg00452.txt.bz2
Content-length: 3123

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb047

            Bug ID: 62047
           Summary: --coverage segfault in libcilkrts
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org

export CFLAGS=--coverage
export CXXFLAGS=--coverage
/path/to/configure --enable-languages=c,c++ --with-system-zlib --disable-nls
--disable-bootstrap
make -j 12

[...]

libtool: compile:  /tmp/gcc-bug/build/./gcc/xg++ -B/tmp/gcc-bug/build/./gcc/
-nostdinc++ -nostdinc++
-I/tmp/gcc-bug/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/tmp/gcc-bug/build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/data/repos/gcc/trunk/libstdc++-v3/libsupc++
-I/data/repos/gcc/trunk/libstdc++-v3/include/backward
-I/data/repos/gcc/trunk/libstdc++-v3/testsuite/util
-L/tmp/gcc-bug/build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-bug/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-bug/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-bug/inst/x86_64-unknown-linux-gnu/bin/
-B/tmp/gcc-bug/inst/x86_64-unknown-linux-gnu/lib/ -isystem
/tmp/gcc-bug/inst/x86_64-unknown-linux-gnu/include -isystem
/tmp/gcc-bug/inst/x86_64-unknown-linux-gnu/sys-include "-DPACKAGE_NAME=\"Cilk
Runtime Library\"" -DPACKAGE_TARNAME=\"cilk-runtime-library\"
-DPACKAGE_VERSION=\"2.0\" "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
-DPACKAGE_BUGREPORT=\"cilk@intel.com\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1
-DHAVE_ATTRIBUTE_VISIBILITY=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.
-I/data/repos/gcc/trunk/libcilkrts -I/data/repos/gcc/trunk/libcilkrts/include
-I/data/repos/gcc/trunk/libcilkrts/runtime
-I/data/repos/gcc/trunk/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1
-fcilkplus -g -O2 --coverage -D_GNU_SOURCE -MT cilk-abi-cilk-for.lo -MD -MP -MF
.deps/cilk-abi-cilk-for.Tpo -c
/data/repos/gcc/trunk/libcilkrts/runtime/cilk-abi-cilk-for.cpp  -fPIC -DPIC -o
.libs/cilk-abi-cilk-for.o
/data/repos/gcc/trunk/libcilkrts/runtime/cilk-abi-cilk-for.cpp:414:1: internal
compiler error: Segmentation fault
 } // end extern "C"
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:782: recipe for target 'cilk-abi-cilk-for.lo' failed
make[2]: *** [cilk-abi-cilk-for.lo] Error 1
make[2]: Leaving directory
'/tmp/gcc-bug/build/x86_64-unknown-linux-gnu/libcilkrts'
Makefile:10846: recipe for target 'all-target-libcilkrts' failed

Note that this is not the only file in libcilk that causes a segfault.

If I do a more minimal build (in particular without cilk) I still have issues
because libgcc_s depends on atexit, but at least the build can finish.

[Bug go/60406] recover.go: test13reflect2 test failure

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |boger at us dot ibm.com

--- Comment #5 from Ian Lance Taylor <ian at airs dot com> ---
*** Bug 63170 has been marked as a duplicate of this bug. ***

[Bug go/60406] recover.go: test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
I'll submit a fix for this problem as soon as I figure out what to do with the
patch.

[Bug go/60406] recover.go: test13reflect2 test failure

[boger at us dot ibm.com]

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

--- Comment #7 from boger at us dot ibm.com ---
I've built with Dominik's patches against trunk on ppc64le and have been trying
to run the gcc testsuite for go and libgo.

The recover.go testcase continues to fail in my build.  I did some debugging on
this and found that the problem occurs in ffi_callback when it calls
__go_makefunc_can_recover.  Based on the comments I think it should be called
with the program address for the most recent caller on the stack which is not
ffi, but instead it is called with the address for ffi_closer_helper_LINUX64. 
I suspect this is happening because runtime_callers is not returning the
complete set of callers.  This error leads to an incorrect setting of
__makefunc_can_recover in the __go_defer_stack structure so the test prints the
"missing recover" error.

[Bug go/60406] recover.go: test13reflect2 test failure

[boger at us dot ibm.com]

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

--- Comment #8 from boger at us dot ibm.com ---
Update on my previous work:

1) My previous update referred to a build that was done with the patches that
were submitted to gcc and patches that Dominik provided me for libffi.  I found
that if I only build with the gcc patches and don't use the libffi patches then
the recover.go testcase passes on ppc64le.

[Bug go/60406] recover.go: test13reflect2 test failure

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to boger from comment #9)
> On ppc64le, this works as expected but on ppc64(be) the code that is
> generated from this is not the address of the function but the address of
> the .opd entry that is used to call the function.  As a result the setting
> of the deferring function is incorrect and it does not appear as if it can
> recover because of the way __go_can_recover uses the deferring function's
> address to see if it is in the correct range.

On BE, a "function pointer" (unlike on LE or x64* or ...) always points to a
function's function descriptor (ie, the .opd entry) and not the code address. 
The function descriptor contains 3 64-bit doublewords.  The first doubleword is
the address of the function's code.  The second doubleword is the TOC value
that needs to be in r2 while we execute the function and the third doubleword
contains an environment pointer for languages such as Pascal and PL/1.

[Bug go/60406] recover.go: test13reflect2 test failure

[boger at us dot ibm.com]

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

--- Comment #11 from boger at us dot ibm.com ---
On ppc64 BE, the call to make_code_func_reference returns the function pointer
in the .opd and not the actual address of the function.  That is what causes
the failures with this patch
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00710.html
The information in this reply fixes the regressions from this patch on ppc64
BE:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02282.html

Essentially the change is to dereference the function pointer in
__go_set_defering_fn when building for ppc64 BE as follows:

+#if defined(__powerpc64__) && _CALL_ELF != 2
+    g->defer->__defering_fn = *(void **)defering_fn;
+#else
+    g->defer->__defering_fn = defering_fn;
+#endif

[Bug go/60406] recover.go: test13reflect2 test failure

[ian at airs dot com]

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

--- Comment #12 from Ian Lance Taylor <ian at airs dot com> ---
Created attachment 33644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33644&action=edit
possible patch

I'm not really happy with Dominik's patch because 1) it doesn't work when
configuring with --enable-sjlj-exceptions; 2) the current code almost always
works, even on S/390, but the patch forces us to do a lookup in the FDE table
every time we call recover.

I'd like to propose a different patch, that keeps the current code that almost
always works, does a quick exit when there is no defer in the call stack, and
does an unwind to check for a specific function in other cases.

Can people on systems for which the recover.go test currently fails please try
this patch and let me know whether it fixes the problem?  Thanks.

This is https://codereview.appspot.com/153950043 .

[Bug go/60406] recover.go: test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

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

--- Comment #14 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
> I'm not really happy with Dominik's patch because 1) it doesn't work when
> configuring with --enable-sjlj-exceptions;

Why is that important?

> 2) the current code almost always works, even on S/390, but the patch
> forces us to do a lookup in the FDE table every time we call recover.

The current code works unreliably as s390 uses memcopy to copy call arguments
to the stack.  The control flow introduced by the function call triggers basic
block reordering that may result in anything.

> I'd like to propose a different patch, that keeps the current code
> that almost always works, does a quick exit when there is no defer in
> the call stack, and does an unwind to check for a specific function
> in other cases.

I've not tested the patch yet, but see some potential problems:

* On systems that "use a leading underscore on symbol names", the test for
functions beginning with "__go_" or "_go_" would yield "true" from user
functions named "_go_..." (because the system adds one '_' and the patch strips
it).

* Wouldn't the new patch re-introduce the bug that

  func foo(n int) {
    if (n == 0) { recover(); } else { foo(0); }
  }
  func main() {
    defer foo(1)
    panic("...")
  }

  would recover although it should not?

* The code is even more expensive than the approach I had chosen because now it
needs to fetch a two level backtrace instead of just one level (and probably
each level is more expensive than the one _Unwind_FindEnclosingFunc()).

----


Digging deeper at the issue that causes Lynn's problems on Power surfaces more
problems with the current implementation of __go_can_recover() and the thunk,
also with the patch I've posted.  Here's a summary of all the problems I am
aware of (some new, some known, skipping the bugs introduced by the patch):

Problems with the current implementation only:
----------------------------------------------

1) Calculation of the label address in the thunk does not work if the basic
block reordering is done (that's the issue why this bug report was created)

2) The current checks for "return address + 16" may point into a different
function, allowing recover() in weird situations.

Problems with the current implementation and the proposed patch:
----------------------------------------------------------------

3) Quote from http://golang.org/ref/spec:

"The return value of recover is nil if any of the following conditions holds:
 ...
 *recover was not called directly by a deferred function."

According to the spec, the following code should recover the panic but does
not:

  func main() { defer foo(); panic("..."); }
  func foo() { defer bar(); }
  func bar() { recover(); }

Note that this is also also "broken" in Golang (well, at least in the old
version that comes with Ubuntu).  This may be an effect of imprecise wording of
the spec.

4) __go_can_recover assumes that any call through libffi is allowed to recover.
 Quote from the sources:

  "/* If the function calling recover was created by reflect.MakeFunc,
      then RETADDR will be somewhere in libffi.  Our caller is
      permitted to recover if it was called from libffi.  */"

This violates the specification.  An example that recovers the panic in a
nested function but should not:

--snip--
package main
import "reflect"

func main() {
  // generate foo() and bar()
  fn := reflect.ValueOf(interface{}(&foo)).Elem()
  val := reflect.MakeFunc(fn.Type(), recover_reflect1)
  fn.Set(val)
  fn = reflect.ValueOf(interface{}(&bar)).Elem()
  val = reflect.MakeFunc(fn.Type(), recover_reflect2)
  fn.Set(val)

  defer foo()
  panic("...")
}

var foo func()
func recover_reflect1(args []reflect.Value) (results []reflect.Value) {
  bar()
  return results
}

var bar func()
func recover_reflect2(args []reflect.Value) (results []reflect.Value) {
  recover()
  return results
}
--snip--

Actually, I think this may also happen if bar is not a function created through
reflection but any foreign language function

 * from a stripped object file
   (no name in the backtrace is guessed as "called by libffi"),
 * if the name begins with "[_]ffi_"

(But perhaps it's impossible to construct such an example.)

[Bug go/60406] recover.go: test13reflect2 test failure

[boger at us dot ibm.com]

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

--- Comment #15 from boger at us dot ibm.com ---
The testcase recover.go continues to fail on both ppc64 LE & BE with the new
patch https://codereview.appspot.com/153950043.

[Bug go/60406] recover.go: test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

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

--- Comment #17 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
>> * Wouldn't the new patch re-introduce the bug that
>>
>>   func foo(n int) {
>>     if (n == 0) { recover(); } else { foo(0); }
>>   }
>>   func main() {
>>     defer foo(1)
>>     panic("...")
>>   }
>> 
>>   would recover although it should not?
>
> Hmmm, I hadn't fully internalized that issue.  Your new
> withoutRecoverRecursive test doesn't fail for me on x86_64.

I think you have implicitly fixed this issue by splitting functions that call
recover() into two parts (i.e. main.foo and main.foo$recover).  So recursive
calls originate from the ...$recover function and never match the return
address check.  Well, maybe it was only a problem with tail recursion, i.e.

  func foo(n int) int {
    if (n == 0) { recover(); return 0; }
    return foo(0)
  }

Would be optimized to a loop, removing the function call, and then the return
address check would trigger.  That's not possible with two function approach. 
But if there's another criterion to allow recover that simply depends on the
caller's name the problem might reappear.

>> * The code is even more expensive than the approach I had chosen because
>> now it needs to fetch a two level backtrace instead of just one level
>> (and probably each level is more expensive than the one 
>> _Unwind_FindEnclosingFunc()).
>
> Yes, but the expensive case only happens in the rare cases where
> either recover should not work or when the existing code has a
> false negative.

Hm, so the patch penalises platforms that cannot deal with the 16 byte window?

>>   func main() { defer foo(); panic("..."); }
>>   func foo() { defer bar(); }
>>   func bar() { recover(); }
>
> In this case, the call to recover in bar is supposed to return nil;
> it should not recover the panic.  If you read the paragraph before
> the one you quote, you will see that recover only returns non-nil
> if it was called by a function that was deferred before the call to
> panic.

I've read it but cannot see anything that would disallow recovery in this
situation.  What exactly do you mean?

>> 4) __go_can_recover assumes that any call through libffi is allowed
>> to recover.
>
> Thanks for the example.  Does your patch fix this problem?

No, I just became aware of the problem when reviewing the code last week.

[Bug go/60406] recover.go: test13reflect2 test failure

[ian at airs dot com]

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

--- Comment #18 from Ian Lance Taylor <ian at airs dot com> ---
> Well, maybe it was only a problem with tail recursion, ....

Note that because Go programs expect predictable results from runtime.Callers
and other stack backtracing functions, the Go frontend disables tail recursion
(go_langhook_post_options in gcc/go/go-lang.c).


> Hm, so the patch penalises platforms that cannot deal with the 16 byte window?

Yes, but, recall that on your system almost all tests pass using the code that
is in the tree today, before your patch.  The only tests that fail are the very
challenging ones in recover.go, that stress test the panic/recover mechanism
but are in no way representative of real code.  The normal tests all works
fine.  So while there is a penalty, it is one that only occurs in rare cases.


>>>   func main() { defer foo(); panic("..."); }
>>>   func foo() { defer bar(); }
>>>   func bar() { recover(); }
>>
>> In this case, the call to recover in bar is supposed to return nil;
>> it should not recover the panic.  If you read the paragraph before
>> the one you quote, you will see that recover only returns non-nil
>> if it was called by a function that was deferred before the call to
>> panic.
>
>I've read it but cannot see anything that would disallow recovery in this
> situation.  What exactly do you mean?

The spec says "Suppose a function G defers a function D that calls recover and
a panic occurs in a function on the same goroutine in which G is executing." 
The order is 1) G defers D; 2) a panic occurs.  In your example above, this
applies to main defers foo and then a panic occurs.  It does not apply to foo
defers bar, because there is no panic after foo defers bar (the panic has
already occurred--that is why we are executing foo).  Since there is no panic,
the recover in bar returns nil.

The recover.go file tests this pattern in, e.g., test1WithClosures.

[Bug go/60406] recover.go: test13reflect2 test failure

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33644|0                           |1
        is obsolete|                            |

--- Comment #19 from Ian Lance Taylor <ian at airs dot com> ---
Created attachment 33661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33661&action=edit
possible patch 2

Here is a new possible patch.  This time I tested it on a PPC GNU/Linux
machine.  The problem was a mishandling of the stack walk when using MakeFunc
with FFI closures.  This passes on both x86_64 and PPC.  It also address
Dominik's case in which there is a spurious recover when one MakeFunc function
calls another.

Please review this patch and let me know if this fails on your system.  Thanks.

[Bug go/60406] recover.go: test13reflect2 test failure

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to boger from comment #20)
> The latest patch worked on ppc64 for LE & BE.  That is, the testcase
> recover.go now works and no new regressions were introduced.

Also works on alpha [1] without new regressions.

[1] https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg00840.html
>From gcc-bugs-return-463514-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 05:53:16 2014
Return-Path: <gcc-bugs-return-463514-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13192 invoked by alias); 8 Oct 2014 05:53:15 -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 13147 invoked by uid 48); 8 Oct 2014 05:53:12 -0000
From: "ville.voutilainen at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63362] The c++11 triviality-traits need front-end help
Date: Wed, 08 Oct 2014 05:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ville.voutilainen at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63362-4-xCT3kETiLN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63362-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63362-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00535.txt.bz2
Content-length: 4424

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

--- Comment #22 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Created attachment 33664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33664&action=edit
Preprocessed source for is_trivially_copy_constructible tests

This test fails the static_assert for TType (which is a trivial type),
PODType and DelDef, and it would be expected that all those static_asserts
succeed. Then, the compiler segfaults, trace:

[ville@localhost is_trivially_copy_constructible]$ g++ -v -save-temps
--std=c++11 -I ../../util/ -c value.cc
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local --enable-languages=c,c++
Thread model: posix
gcc version 5.0.0 20141008 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-I' '../../util/' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -E -quiet -v -I
../../util/ -D_GNU_SOURCE value.cc -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -o value.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ../../util/

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-I' '../../util/' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -fpreprocessed
value.ii -quiet -dumpbase value.cc -mtune=generic -march=x86-64 -auxbase value
-std=c++11 -version -o value.s
GNU C++ (GCC) version 5.0.0 20141008 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 5.0.0 20141008 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 5.0.0 20141008 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 5.0.0 20141008 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7d1439b3948ab95e7d138f746bcfda79
value.cc: In function ‘void test01()’:
value.cc:40:3: error: static assertion failed: 
   static_assert(test_category<is_trivially_copy_constructible, 
   ^
value.cc:42:3: error: static assertion failed: 
   static_assert(test_category<is_trivially_copy_constructible, 
   ^
value.cc:48:3: error: static assertion failed: 
   static_assert(test_category<is_trivially_copy_constructible, 
   ^
g++: internal compiler error: Segmentation fault (program cc1plus)
0x40c49c execute
    ../../gcc/gcc.c:2908
0x40c789 do_spec_1
    ../../gcc/gcc.c:4724
0x40f189 process_brace_body
    ../../gcc/gcc.c:6007
0x40f189 handle_braces
    ../../gcc/gcc.c:5921
0x40d2e7 do_spec_1
    ../../gcc/gcc.c:5378
0x40f189 process_brace_body
    ../../gcc/gcc.c:6007
0x40f189 handle_braces
    ../../gcc/gcc.c:5921
0x40d2e7 do_spec_1
    ../../gcc/gcc.c:5378
0x40cc13 do_spec_1
    ../../gcc/gcc.c:5493
0x40f189 process_brace_body
    ../../gcc/gcc.c:6007
0x40f189 handle_braces
    ../../gcc/gcc.c:5921
0x40d2e7 do_spec_1
    ../../gcc/gcc.c:5378
0x40f189 process_brace_body
    ../../gcc/gcc.c:6007
0x40f189 handle_braces
    ../../gcc/gcc.c:5921
0x40d2e7 do_spec_1
    ../../gcc/gcc.c:5378
0x40f189 process_brace_body
    ../../gcc/gcc.c:6007
0x40f189 handle_braces
    ../../gcc/gcc.c:5921
0x40d2e7 do_spec_1
    ../../gcc/gcc.c:5378
0x40f189 process_brace_body
    ../../gcc/gcc.c:6007
0x40f189 handle_braces
    ../../gcc/gcc.c:5921
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.
>From gcc-bugs-return-463515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 05:58:48 2014
Return-Path: <gcc-bugs-return-463515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19022 invoked by alias); 8 Oct 2014 05:58:48 -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 18977 invoked by uid 48); 8 Oct 2014 05:58:45 -0000
From: "ak at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63472] transaction_atomic within while loop causes ICE
Date: Wed, 08 Oct 2014 05:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical
X-Bugzilla-Who: ak at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-63472-4-1HDeI9DWQX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63472-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63472-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-10/txt/msg00536.txt.bz2
Content-length: 768

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc472

--- Comment #4 from ak at gcc dot gnu.org ---
Reduced test cases for all three crashes. I suspect multiple have a similar
root cause (except perhaps for the expand_expr_addr_expr_1 one)

It looks like the transaction code messes up cfgloops.

copy_bbs:

(illegal code due to goto into transaction?)

g_56[];
fn1() {
  int *p_79;
  if (g_56[7])
    __transaction_atomic {
    lbl_196:
      *p_79 = 1;
    }
  else
    goto lbl_196;
}


expand_expr_addr_expr_1:

struct {
  unsigned : 7;
  signed f6 : 4
} g_35;
safe_rshift_func_uint16_t_u_s() {}

func_28() {
  __transaction_atomic { safe_rshift_func_uint16_t_u_s(g_35.f6); }
}

copy_loops:

func_65() {
  __transaction_atomic {
    for (;;)
      func_65();
  }
}

[Bug go/60406] recover.go: test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

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

--- Comment #22 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
>> Hm, so the patch penalises platforms that cannot deal with the
>> 16 byte window?

> Yes, but, recall that on your system almost all tests pass using the
> code that is in the tree today, before your patch.

But they really only succeed "by accident".  The call for any platform might
introduce control flow into the thunk and trigger the problem in any of the
test cases.

> The spec says "Suppose a function G defers a function D that calls
> recover and a panic occurs in a function on the same goroutine in
> which G is executing."  The order is 1) G defers D; 2) a panic occurs.
> ...

I'd still not understand it that way, but from other documentation the
intention is "clear".  Maybe another bullet could be added to the list
below:

  "The return value of recover is nil if ...

    ...
    * defer was called when the panic already existed"

[Bug go/60406] recover.go: test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

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

--- Comment #24 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
> --snip--
> -    g->defer->__retaddr = retaddr;
> +    g->defer->__retaddr = __builtin_extract_return_addr (retaddr);
> --snip--

We need to double check whether this would break Sparc.

[Bug go/60406] recover.go: test13reflect2 test failure

[ian at airs dot com]

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

--- Comment #25 from Ian Lance Taylor <ian at airs dot com> ---
(In reply to Dominik Vogt from comment #22)
> >> Hm, so the patch penalises platforms that cannot deal with the
> >> 16 byte window?
> 
> > Yes, but, recall that on your system almost all tests pass using the
> > code that is in the tree today, before your patch.
> 
> But they really only succeed "by accident".  The call for any platform might
> introduce control flow into the thunk and trigger the problem in any of the
> test cases.

Yes, I understand that.

You suggested that my patch penalized all cases where we have a control flow
problem, because it will do a more costly unwind step.  That is true.  However,
in practice, the case arises very rarely.  We know that the code in the thunk
is always very simple:

    if (__go_set_defer_retaddr (&&L))
      goto L;
    real_function(args);
  L:

The compiler is not going to start randomly throwing additional control flow
statements into that function.  The cases where it does do that are the cases
where args is very large, so that it uses a block copy to copy them onto the
stack.  But that essentially never happens.  The args here are the args in
"defer real_function(args)".  90% of the time there are no arguments at all. 
9.9% of the time it's just a couple of pointer/scalar arguments.  In real code
nobody ever calls defer with large arguments, because it's just a strange way
to write; people write a function closure instead.  The only code in the
standard library that calls defer with a large argument is the recover.go test,
to make sure that it works.

It's necessary to handle all cases correctly.  But there is nothing wrong with
using an efficient mechanism when it works, as long as we can correctly fall
back to a more expensive mechanism when it fails.  I believe that my patch does
that.

If you like, we can incorporate your patch too, as long as it is only an
addition to the existing code.  Before calling runtime_callers, we can call
_Unwind_FindEnclosingFunction.  Then we need only go on to the runtime_callers
code if _Unwind_FindEnclosingFunction returns NULL, or in the cases where
d->__makefunc_can_recover is true.

[Bug go/60406] recover.go: test13reflect2 test failure

[ian at airs dot com]

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

--- Comment #26 from Ian Lance Taylor <ian at airs dot com> ---
(In reply to Dominik Vogt from comment #23)
> 
> 1) We need to call __builtin_extract_return_address(retaddr) in
> __go_set_defer_retaddr() too.  (On s390 (31 bit) this is necessary to remove
> the most significant bit of the address which indicates the addressing mode.)
> 
> I.e.
> 
> --snip--
> -    g->defer->__retaddr = retaddr;
> +    g->defer->__retaddr = __builtin_extract_return_addr (retaddr);
> --snip--

Will do.


> 2) The new patch does not compile for me:
> 
> --
> In file included from ../../../libgo/runtime/go-check-interface.c:8:0:
> ../../../libgo/runtime/go-panic.h:43:13: error: conflicting types for
> ‘__go_makefunc_can_recover’
>  extern void __go_makefunc_can_recover (void *retaddr);
>              ^
> In file included from ../../../libgo/runtime/go-check-interface.c:7:0:
> ../../../libgo/runtime/runtime.h:845:9: note: previous declaration of
> ‘__go_makefunc_can_recover’ was here
>  void    __go_makefunc_can_recover (const void *);
>          ^
> --
> 
> In runtime.h, __go_makefunc_can_recover still has a "const" argument:
> 
> --snip--
> -void    __go_makefunc_can_recover (const void *);
> +void    __go_makefunc_can_recover (void *);
> --snip--

I think that must be a local change in your tree.  In my tree runtime.h does
not declare __go_makefunc_can_recover.


> 3) Couldn't this be written more efficiently by passing a flag?
> 
> +  /* If we are called from __go_makefunc_can_recover, then we need to
> +     look one level higher.  */
> +  if (locs[0].function.len > 0
> +      && __builtin_strcmp ((const char *) locs[0].function.str,
> +			   "__go_makefunc_can_recover") == 0)
> 
> E.g.
> 
>   _Bool __go_can_recover (void *retaddr, _Bool
> called_by_makefunc_can_recover)
>   {
>     ...
>     if (called_by_makefunc_can_recover)
>       { do something }
>     else
>       { do something else }
>     ...
>   }

Yes, but I would rather do that later if it seems useful.  It seems silly to
change the compiler to always pass an extra argument that will always be false.
 Introducing a new function called by both __go_can_recover and
__go_makefunc_can_recover changes the stack layout depending on the compiler's
inlining choices, so must be treated with care.  And it's worth remembering
that this case never ever happens outside of tests.  It only happens when
somebody constructs a function using reflect.MakeFunc and then defers a call to
that function.  That is a bizarre way to code and I am confident that
absolutely no real Go code does it.  Making that case slightly less efficient
is not important.


> 4) With the suggested changes from 1 and 2 above:
> 
> s390x (64 bit):
> 
> * PASS: test/recover.go
> * the test from #4 in my earlier posting works as expected
> * my private defer/recover/panic testsuite works as expected
> 
> s390 (31 bit):
> 
> * PASS: test/recover.go
> * the test from #4 in my earlier posting works as expected
> * my private defer/recover/panic testsuite works as expected

Thanks for testing.


> 5) I find the assumption in the loop at the end of __go_can_recover() that
> if a caller's name begins with "__go_" that means the panic can be
> recovered, a bit hairy.  Even if it is with the current libgo, an unrelated
> change elsewhere could break this logic.

I agree that it's imperfect.  However, it's fairly difficult to construct a
case that causes the wrong thing to happen.  No Go function can ever start with
__go.  Very little code in libgo calls a function written in Go; it's easy to
find such code because it must call __go_set_closure (the defer thunks are a
special case that are known to have no closure).  So it can only happen if
somebody writes a Go function that calls recover, and then passes it to C code,
and that C code names a function starting with "__go_" and then calls the Go
function.  And this has to happen from a deferred function called while there
is a panic in progress.  The result will be that the function called by the C
code will incorrectly recover the panic.
>From gcc-bugs-return-463563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 13:51:04 2014
Return-Path: <gcc-bugs-return-463563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29377 invoked by alias); 8 Oct 2014 13:51:04 -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 29351 invoked by uid 48); 8 Oct 2014 13:51:00 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63485] New: [5 Regression] ICE: canonical types differ for identical types A<const wchar_t [3]>::type and const char_type [3]
Date: Wed, 08 Oct 2014 13:51: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
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
Message-ID: <bug-63485-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00584.txt.bz2
Content-length: 4634

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

            Bug ID: 63485
           Summary: [5 Regression] ICE: canonical types differ for
                    identical types A<const wchar_t [3]>::type and const
                    char_type [3]
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

Running the Boost testsuite shows:

markus@x4 /tmp % cat date_time_format_parser.ii
template <typename C> struct A
{
  typedef C type;
};
template <class> class B
{
};
template <class Range> void as_literal (Range &);
template <typename> struct C
{
  typedef wchar_t char_type;
  const char_type on_full_year_placeholder[3];
  void
  on_extended_iso_date ()
  {
    B<A<wchar_t const[3]>::type> a;
    as_literal (on_full_year_placeholder);
  }
};
template <typename> struct date_time_format_parser_callback : C<wchar_t>
{
};
template <typename BaseT> struct D
{
  typedef typename BaseT::char_type char_type;
  char_type
  parse (const char_type *, const char_type *,
         typename BaseT::callback_type p3)
  {
    p3.on_extended_iso_date ();
  }
};
struct F
{
  typedef date_time_format_parser_callback<wchar_t> callback_type;
  typedef wchar_t char_type;
};
template <typename CharT, typename ParserT, typename CallbackT>
void
parse_format (CharT *p1, ParserT p2, CallbackT p3)
{
  CharT p = p2.parse (&p, p1, p3);
}
template <typename CharT>
void
parse_date_time_format (const CharT *, const CharT *p2,
                        date_time_format_parser_callback<CharT> &p3)
{
  D<F> b;
  parse_format (p2, b, p3);
}
template void
parse_date_time_format (const wchar_t *, const wchar_t *,
                        date_time_format_parser_callback<wchar_t> &);



markus@x4 /tmp % g++ -c -w -O0 date_time_format_parser.ii
date_time_format_parser.ii: In instantiation of ‘void C<
<template-parameter-1-1> >::on_extended_iso_date() [with
<template-parameter-1-1> = wchar_t]’:
date_time_format_parser.ii:30:5:   required from ‘D<BaseT>::char_type
D<BaseT>::parse(const char_type*, const char_type*, typename
BaseT::callback_type) [with BaseT = F; D<BaseT>::char_type = wchar_t; typename
BaseT::callback_type = date_time_format_parser_callback<wchar_t>]’
date_time_format_parser.ii:42:33:   required from ‘void parse_format(CharT*,
ParserT, CallbackT) [with CharT = const wchar_t; ParserT = D<F>; CallbackT =
date_time_format_parser_callback<wchar_t>]’
date_time_format_parser.ii:50:16:   required from ‘void
parse_date_time_format(const CharT*, const CharT*,
date_time_format_parser_callback<CharT>&) [with CharT = wchar_t]’
date_time_format_parser.ii:54:68:   required from here
date_time_format_parser.ii:17:16: internal compiler error: canonical types
differ for identical types A<const wchar_t [3]>::type and const char_type [3]
{aka A<const wchar_t [3]>::type}
     as_literal (on_full_year_placeholder);
                ^
0x6b6ebe comptypes(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/typeck.c:1407
0x6b4ffd structural_comptypes
        ../../gcc/gcc/cp/typeck.c:1341
0x6b6e77 comptypes(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/typeck.c:1399
0x6d1c51 ocp_convert(tree_node*, tree_node*, int, int, int)
        ../../gcc/gcc/cp/cvt.c:686
0x57baf8 convert_like_real
        ../../gcc/gcc/cp/call.c:6471
0x57832c build_over_call
        ../../gcc/gcc/cp/call.c:7209
0x587911 build_new_function_call(tree_node*, vec<tree_node*, va_gc,
vl_embed>**, bool, int)
        ../../gcc/gcc/cp/call.c:4072
0x7060b4 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
        ../../gcc/gcc/cp/semantics.c:2366
0x5fb7c6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
        ../../gcc/gcc/cp/pt.c:15095
0x5db9d6 tsubst_expr
        ../../gcc/gcc/cp/pt.c:14272
0x5dbb1f tsubst_expr
        ../../gcc/gcc/cp/pt.c:13683
0x5db34b tsubst_expr
        ../../gcc/gcc/cp/pt.c:13669
0x5dc7e0 tsubst_expr
        ../../gcc/gcc/cp/pt.c:13855
0x5d9a7d instantiate_decl(tree_node*, int, bool)
        ../../gcc/gcc/cp/pt.c:20231
0x620192 instantiate_pending_templates(int)
        ../../gcc/gcc/cp/pt.c:20347
0x65d4d4 cp_write_global_declarations()
        ../../gcc/gcc/cp/decl2.c:4367
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.
>From gcc-bugs-return-463565-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 13:58:58 2014
Return-Path: <gcc-bugs-return-463565-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9270 invoked by alias); 8 Oct 2014 13:58:58 -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 9234 invoked by uid 55); 8 Oct 2014 13:58:54 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63483] Scheduler performs Invalid move of aliased memory reference
Date: Wed, 08 Oct 2014 13:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ubizjak at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63483-4-JvLJIJRU3C@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00586.txt.bz2
Content-length: 5115

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 8 Oct 2014, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
> 
> --- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
> (In reply to Richard Biener from comment #5)
> > The bug is clearly in
> > 
> > "
> > > Btw, if the mem is MEM_READONLY_P how can it be part of
> > > a {un}aligned_store sequence?
> > 
> > This flag is copied from the original memory operand of the store by
> > alpha_set_memflags to all memory operands in the expanded sequence."
> > 
> > and thus should be fixed there.  What is the "original" memory reference
> > here?  It seems for the read-modify-write you should use the target MEM
> > but somehow a source MEM gets used?  Or rather you should not use either
> > MEMs flags for _all_ MEMs in the sequence but properly distinguish between
> > MEMs generated for the load of the source and MEMs generated for the store
> > to the destination.
> 
> No, this is wrong conclusion. I have new insight into this problem.
> 
> Please consider following test:
> 
> --cut here--
> static char *a;
> static int *b;
> 
> void foo (void)
> {
>   a[1] = 1;
>   b[2] = 1;
> }
> 
> int bar (void)
> {
>   return a && b;
> }
> --cut here--
> 
> (e.g. changing "static char *b" to "static int *b". This way, the problematic
> insn is generated as "native" read:
> 
> (insn 15 14 16 2 (set (reg/f:DI 78)
>         (mem/u/f/c:DI (lo_sum:DI (reg:DI 79)
>                 (symbol_ref:DI ("b") [flags 0x6]  <var_decl 0x2b1d67f5e090 b>))
> [2 b+0 S8 A64])) rmw1.c:7 -1
>      (nil))
> 
> and this is again moved over
> 
> (insn 13 12 14 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72)
>                     (const_int 1 [0x1]))
>                 (const_int -8 [0xfffffffffffffff8])) [0  S8 A64])
>         (reg:DI 77)) rmw1.c:6 -1
>      (nil))
> 
> (note that there is no "/u" suffix on the *store* of "a".)
> 
> With this testcase, we have following sequence before sched1 pass:
> 
>     5: r73:DI=high(`a')
>     6: r72:DI=[r73:DI+low(`a')]
>       REG_DEAD r73:DI
>     7: r74:QI=0x1
>     8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
>     9: r75:DI=r72:DI+0x1
>    10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
>    11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
>       REG_DEAD r75:DI
>       REG_DEAD r74:QI
>       REG_EQUAL 0x1<<r75:DI<<0x3
>    12: r77:DI=r77:DI|r76:DI
>       REG_DEAD r76:DI
>    13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
>       REG_DEAD r77:DI
>       REG_DEAD r72:DI
>    14: r79:DI=high(`b')
>    15: r78:DI=[r79:DI+low(`b')]
>       REG_DEAD r79:DI
>    16: r80:SI=0x1
>    17: [r78:DI+0x8]=r80:SI
>       REG_DEAD r80:SI
>       REG_DEAD r78:DI
> 
> and sched1 moves (insn 15) all the way up, past (insn 13):
> 
>     5: r73:DI=high(`a')
>    14: r79:DI=high(`b')
>     7: r74:QI=0x1
>     6: r72:DI=[r73:DI+low(`a')]
>       REG_DEAD r73:DI
>    16: r80:SI=0x1
>    15: r78:DI=[r79:DI+low(`b')]
>       REG_DEAD r79:DI
>     9: r75:DI=r72:DI+0x1
>     8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
>    11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
>       REG_DEAD r75:DI
>       REG_DEAD r74:QI
>       REG_EQUAL 0x1<<r75:DI<<0x3
>    10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
>    12: r77:DI=r77:DI|r76:DI
>       REG_DEAD r76:DI
>    13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
>       REG_DEAD r77:DI
>       REG_DEAD r72:DI
>    17: [r78:DI+0x8]=r80:SI
>       REG_DEAD r80:SI
>       REG_DEAD r78:DI
>    20: NOTE_INSN_DELETED
> 
> (this particular sequence won't end in a failure, but the insn shouldn't be
> moved past possibly aliasing (insn 13) anyway.
> 
> Patched compiler results in:
> 
>     5: r73:DI=high(`a')
>     7: r74:QI=0x1
>    14: r79:DI=high(`b')
>     6: r72:DI=[r73:DI+low(`a')]
>       REG_DEAD r73:DI
>    16: r80:SI=0x1
>     9: r75:DI=r72:DI+0x1
>     8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
>    11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
>       REG_DEAD r75:DI
>       REG_DEAD r74:QI
>       REG_EQUAL 0x1<<r75:DI<<0x3
>    10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
>    12: r77:DI=r77:DI|r76:DI
>       REG_DEAD r76:DI
>    13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
>       REG_DEAD r77:DI
>       REG_DEAD r72:DI
>    15: r78:DI=[r79:DI+low(`b')]
>       REG_DEAD r79:DI
>    17: [r78:DI+0x8]=r80:SI
>       REG_DEAD r80:SI
>       REG_DEAD r78:DI
> 
> As shown, the code further down in true_dependence_1 function blocks the move,
> since the read is detected as aliased with the preceding store involving AND
> alignment.
> 
> There is nothing that can be done in target-dependant code, since the "native"
> read from "b" gets marked as "unchanging" by the generic middle-end code.

Where is that done?  It looks bogus to me.

> Please reconsider the "component" setting. There is nothing that can be fixed
> in target-dependent code.

I'm not sure - copying MEM flags to all MEMs from a single source seems
possibly wrong.
>From gcc-bugs-return-463564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 13:58:15 2014
Return-Path: <gcc-bugs-return-463564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8466 invoked by alias); 8 Oct 2014 13:58:14 -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 8435 invoked by uid 48); 8 Oct 2014 13:58:10 -0000
From: "mira.suk at centrum dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63486] New: Magic Statics lock guard does not include registration into atexit handler
Date: Wed, 08 Oct 2014 13:58: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.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mira.suk at centrum dot cz
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
Message-ID: <bug-63486-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00585.txt.bz2
Content-length: 13969

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

            Bug ID: 63486
           Summary: Magic Statics lock guard does not include registration
                    into atexit handler
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mira.suk at centrum dot cz

void test()
{                                                                              
  static std::string x;
}

If I'm reading assembly right _cxa_atexit handler is not called inside lock
which could result in static variable being destructed multiple times.

Is compiled into following with -g3

   |0x401312 <test()>       push   %rbp                                        
                                                                        │
   │0x401313 <test()+1>     mov    %rsp,%rbp                                   
                                                                        │
   │0x401316 <test()+4>     push   %r12                                        
                                                                        │
   │0x401318 <test()+6>     push   %rbx                                        
                                                                        │
   |0x401319 <test()+7>     lea    0x202e10(%rip),%rax        # 0x604130
<_ZGVZ4testvE1x>                                                              
│
   │0x401320 <test()+14>    movzbl (%rax),%eax                                 
                                                                        │
   │0x401323 <test()+17>    test   %al,%al                                     
                                                                        │
   │0x401325 <test()+19>    jne    0x401398 <test()+134>                       
                                                                               
        │
   │0x401327 <test()+21>    lea    0x202e02(%rip),%rdi        # 0x604130
<_ZGVZ4testvE1x>                                                               
               │
   │0x40132e <test()+28>    callq  0x400c40 <__cxa_guard_acquire@plt>          
                                                                               
        │
   │0x401333 <test()+33>    test   %eax,%eax                                   
                                                                               
        │
   │0x401335 <test()+35>    setne  %al                                         
                                                                               
        │
   │0x401338 <test()+38>    test   %al,%al                                     
                                                                               
        │
   │0x40133a <test()+40>    je     0x401398 <test()+134>                       
                                                                               
        │
   │0x40133c <test()+42>    mov    $0x0,%r12d                                  
                                                                               
        │
   │0x401342 <test()+48>    lea    0x202dff(%rip),%rdi        # 0x604148
<_ZZ4testvE1x>                                                                 
               │
   │0x401349 <test()+55>    callq  0x400c20 <_ZNSsC1Ev@plt>                    
                                                                               
        │
   │0x40134e <test()+60>    lea    0x202ddb(%rip),%rdi        # 0x604130
<_ZGVZ4testvE1x>                                                               
               │
   │0x401355 <test()+67>    callq  0x400cb0 <__cxa_guard_release@plt>          
                                                                               
        │
   │0x40135a <test()+72>    lea    0x202d87(%rip),%rdx        # 0x6040e8       
                                                                               
        │
   │0x401361 <test()+79>    lea    0x202de0(%rip),%rsi        # 0x604148
<_ZZ4testvE1x>                                                                 
               │
   │0x401368 <test()+86>    mov    0x202c81(%rip),%rax        # 0x603ff0       
                                                                               
        │
   │0x40136f <test()+93>    mov    %rax,%rdi                                   
                                                                               
        │
   │0x401372 <test()+96>    callq  0x400ef1 <__cxa_atexit(void (*)(void*),
void*, void*)>                                                                 
             │
   │0x401377 <test()+101>   jmp    0x401398 <test()+134>                       
                                                                               
        │
   │0x401379 <test()+103>   mov    %rax,%rbx                                   
                                                                               
        │
   │0x40137c <test()+106>   test   %r12b,%r12b                                 
                                                                               
        │
   │0x40137f <test()+109>   jne    0x40138d <test()+123>                       
                                                                               
        │
   │0x401381 <test()+111>   lea    0x202da8(%rip),%rdi        # 0x604130
<_ZGVZ4testvE1x>                                                               
               │
   │0x401388 <test()+118>   callq  0x400d10 <__cxa_guard_abort@plt>            
                                                                               
        │
   │0x40138d <test()+123>   mov    %rbx,%rax                                   
                                                                               
        │
   │0x401390 <test()+126>   mov    %rax,%rdi                                   
                                                                               
        │
   │0x401393 <test()+129>   callq  0x400d70 <_Unwind_Resume@plt>               
                                                                               
        │
   │0x401398 <test()+134>   pop    %rbx                                        
                                                                               
        │
   │0x401399 <test()+135>   pop    %r12                                        
                                                                               
        │
   │0x40139b <test()+137>   pop    %rbp                                        
                                                                               
        │
>From gcc-bugs-return-463566-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 14:03:49 2014
Return-Path: <gcc-bugs-return-463566-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16921 invoked by alias); 8 Oct 2014 14:03:49 -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 16882 invoked by uid 55); 8 Oct 2014 14:03:46 -0000
From: "ian at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60406] recover.go: test13reflect2 test failure
Date: Wed, 08 Oct 2014 14:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ian at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60406-4-bfj85PJtQh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60406-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60406-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-10/txt/msg00587.txt.bz2
Content-length: 641

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`406

--- Comment #27 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Wed Oct  8 14:03:13 2014
New Revision: 216003

URL: https://gcc.gnu.org/viewcvs?rev!6003&root=gcc&view=rev
Log:
    PR go/60406
runtime: Check callers in can_recover if return address    doesn't match.

Also use __builtin_extract_return_address and tighten up the
checks in FFI code.

Fixes PR 60406.

Modified:
    trunk/libgo/go/reflect/makefunc_ffi_c.c
    trunk/libgo/runtime/go-defer.c
    trunk/libgo/runtime/go-panic.h
    trunk/libgo/runtime/go-recover.c
    trunk/libgo/runtime/panic.c

[Bug go/60406] recover.go: test13reflect2 test failure

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

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

--- Comment #28 from Ian Lance Taylor <ian at airs dot com> ---
Fixed on trunk.

[Bug go/60406] recover.go: test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

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

--- Comment #29 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Thanks!

> It's necessary to handle all cases correctly.  But there is nothing wrong
> with using an efficient mechanism when it works, as long as we can correctly
> fall back to a more expensive mechanism when it fails.  I believe that my
> patch does that.

I'm fine with that.  But couldn't this also happen when copying multiple
arguments to the stack?  E.g. if you have an array A and call the function with
something like

  defer(foo(A[0], A[1], ... A[N])

gcc could turn that into a loop for a sufficiently large N?  This may be also
an unlikely case, but a test for this wouldn't hurt either.

> If you like, we can incorporate your patch too, as long as it is only an
> addition to the existing code.  Before calling runtime_callers, we can call
> _Unwind_FindEnclosingFunction.  Then we need only go on to the
> runtime_callers code if _Unwind_FindEnclosingFunction returns NULL, or in the
> cases where d->__makefunc_can_recover is true.

Given that my patch fails to work with indirect function pointers (Power) that
does not seem to be very helpful.