[Bug lto/63409] New: [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[Bug lto/63409] New: [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[ubizjak at gmail dot com]

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

            Bug ID: 63409
           Summary: [5 Regression] FAIL: g++.dg/lto/pr63270
                    cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2
                    -Wno-odr -fno-linker-plugin
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com

This can be triggered on Fedora20 with:

make check-c++ RUNTESTFLAGS="--target_board=unix/-fno-use-linker-plugin
lto.exp=pr63270_?.C"

spawn -ignore SIGHUP /ssd/uros/gcc-build/gcc/testsuite/g++/../../xg++
-B/ssd/uros/gcc-build/gcc/testsuite/g++/../../ cp_lto_pr63270_0.o
cp_lto_pr63270_1.o -fno-diagnostics-show-caret -fdiagnostics-color=never
-nostdinc++
-I/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++
-I/home/uros/gcc-svn/trunk/libstdc++-v3/include/backward
-I/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -flto
-O2 -Wno-odr
-L/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fno-use-linker-plugin -o g++-dg-lto-pr63270-01.exe
cp_lto_pr63270_0.o: In function `v8::internal::fn1()':
pr63270_0.C:(.text+0xa): undefined reference to `v8::internal::B::B(int)'
pr63270_0.C:(.text+0x16): undefined reference to `v8::internal::B::B(int)'
pr63270_0.C:(.text+0x22): undefined reference to `v8::internal::A::A(int)'
pr63270_0.C:(.text+0x27): undefined reference to `v8::internal::G::m_fn1()'
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
cp_lto_pr63270_0.o: In function `v8::internal::fn1()':
pr63270_0.C:(.text+0xa): undefined reference to `v8::internal::B::B(int)'
pr63270_0.C:(.text+0x16): undefined reference to `v8::internal::B::B(int)'
pr63270_0.C:(.text+0x22): undefined reference to `v8::internal::A::A(int)'
pr63270_0.C:(.text+0x27): undefined reference to `v8::internal::G::m_fn1()'
collect2: error: ld returned 1 exit status

FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2
-Wno-odr
UNRESOLVED: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o execute
-flto -O2 -Wno-odr

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
   Target Milestone|---                         |5.0

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-30
                 CC|                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I get the same failure on x86_64-apple-darwin13 configured with

../work/configure --prefix=/opt/gcc/gcc4.10w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7

and tested with

make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"

AFAICT the test (r215451) never passed.

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

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

Martin Liška <mliska at suse dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mliska at suse dot cz

--- Comment #2 from Martin Liška <mliska at suse dot cz> ---
Mine. I will prepare the testcase to resolve missing references.
>From gcc-bugs-return-462921-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 11:11:34 2014
Return-Path: <gcc-bugs-return-462921-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16971 invoked by alias); 30 Sep 2014 11:11:34 -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 16919 invoked by uid 48); 30 Sep 2014 11:11:30 -0000
From: "mliska at suse dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/35545] tracer pass is run too late
Date: Tue, 30 Sep 2014 11:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.4.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: mliska at suse dot cz
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-35545-4-Bcff9kksn3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-35545-4@http.gcc.gnu.org/bugzilla/>
References: <bug-35545-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-09/txt/msg02755.txt.bz2
Content-length: 198

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

--- Comment #24 from Martin Liška <mliska at suse dot cz> ---
Hello Honza. I've been working on SPEC numbers, I will send it this evening.
>From gcc-bugs-return-462922-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 11:38:41 2014
Return-Path: <gcc-bugs-return-462922-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29566 invoked by alias); 30 Sep 2014 11:38:40 -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 29548 invoked by uid 48); 30 Sep 2014 11:38:35 -0000
From: "tomalk at mathematik dot uni-freiburg.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63414] New: template parse error using < operator
Date: Tue, 30 Sep 2014 11:38: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tomalk at mathematik dot uni-freiburg.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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63414-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-09/txt/msg02756.txt.bz2
Content-length: 406

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

            Bug ID: 63414
           Summary: template parse error using < operator
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tomalk at mathematik dot uni-freiburg.de

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Martin Liška from comment #4)
> Can you please verify for me that the following patch fixes the problem for
> your arch?

It works, but generates following warning:

WARNING: lto.exp does not support dg-lto-options in secondary source files
>From gcc-bugs-return-463189-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 13:37:33 2014
Return-Path: <gcc-bugs-return-463189-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8297 invoked by alias); 3 Oct 2014 13:37:32 -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 8275 invoked by uid 55); 3 Oct 2014 13:37:29 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63449] documentation of vector space overhead management
Date: Fri, 03 Oct 2014 13:37: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.9.1
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63449-4-eSlMgHJick@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63449-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63449-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/msg00210.txt.bz2
Content-length: 669

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Fri Oct  3 13:36:57 2014
New Revision: 215849

URL: https://gcc.gnu.org/viewcvs?rev!5849&root=gcc&view=rev
Log:
    PR libstdc++/63449
    * doc/xml/manual/containers.xml: Remove outdated section.
    * doc/html/*: Regenerate.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/doc/html/index.html
    trunk/libstdc++-v3/doc/html/manual/containers.html
    trunk/libstdc++-v3/doc/html/manual/index.html
    trunk/libstdc++-v3/doc/html/manual/std_contents.html
    trunk/libstdc++-v3/doc/xml/manual/containers.xml

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-*-*                  |x86_64-*-*,
                   |                            |i386-pc-solaris2.1[01],
                   |                            |sparc-sun-solaris2.1[01]
                 CC|                            |ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> ---
Same failure on both i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01].

  Rainer

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

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

--- Comment #7 from Martin Liška <mliska at suse dot cz> ---
Yeah, sorry for wrong dg argument. There's new version that should work
correctly. If not regression will be seen, I will commit the patch.
>From gcc-bugs-return-463383-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 06 16:19:15 2014
Return-Path: <gcc-bugs-return-463383-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11458 invoked by alias); 6 Oct 2014 16:19: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 11406 invoked by uid 48); 6 Oct 2014 16:19:11 -0000
From: "mliska at suse dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
Date: Mon, 06 Oct 2014 16:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mliska at suse dot cz
X-Bugzilla-Status: NEW
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-63409-4-1ZIFLvlVVO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63409-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63409-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/msg00404.txt.bz2
Content-length: 231

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

--- Comment #8 from Martin Liška <mliska at suse dot cz> ---
Created attachment 33653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33653&action=edit
Fix patch2
>From gcc-bugs-return-463384-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 06 16:27:22 2014
Return-Path: <gcc-bugs-return-463384-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15256 invoked by alias); 6 Oct 2014 16:27: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 15199 invoked by uid 48); 6 Oct 2014 16:27:18 -0000
From: "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60406] recover.go: test13reflect2 test failure
Date: Mon, 06 Oct 2014 16:27: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 airs dot com
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-ECeKU5RHeK@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/msg00405.txt.bz2
Content-length: 3798

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

--- Comment #16 from Ian Lance Taylor <ian at airs dot 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?

It's not very important but it's still a point to consider.  Some targets
default to SJLJ exceptions, albeit not very important ones.


>> 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.

Sure, I understand, and it can obviously cause a false negative: some cases
that should recover will fail to do so.  However, I don't see any way that it
can ever cause a false positive: I don't see any way that it can cause recover
to succeed when it should not.


> * 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).

Yes.  We are already going to have trouble on such systems.  Really the library
needs to learn which systems use a leading underscore and which do not.  This
is actually available as __USER_LABEL_PREFIX__, and we should use that.


> * 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'll have to figure out why.


> * 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.  In the normal
case, where recover is permitted and the existing code works, we save the FDE
lookup.


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

It's a potential problem but I'm not too worried about it.


> "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.

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.  In your example, the defer of bar
happens after the call to panic.  The reason Go works this way is to that the
deferred function foo can itself call a function that panics and recovers
without that function being confused by the earlier panic, one that it may not
know anything about.


> 4) __go_can_recover assumes that any call through libffi is allowed
> to recover.

Thanks for the example.  Does your patch fix this problem?

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Martin Liška from comment #8)
> Created attachment 33653 [details]
> Fix patch2

Yes, this patch works for me.
>From gcc-bugs-return-463421-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 07:23:25 2014
Return-Path: <gcc-bugs-return-463421-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19618 invoked by alias); 7 Oct 2014 07:23:25 -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 19554 invoked by uid 55); 7 Oct 2014 07:23:19 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
Date: Tue, 07 Oct 2014 07:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: diagnostic, lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61886-4-uibUm7mdxP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61886-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61886-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/msg00442.txt.bz2
Content-length: 1146

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

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 6 Oct 2014, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?ida886
>
> --- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
> Hi,
> this patch implements the lowring.  Each call with warn attribute triggers code
> in cgraphunit that inserts call to bulitin_warning/error that is output at
> expansion time.
>
> Do we have way to define bulitin that is not user accessible?
>
> Also we do not have way to define LOOPING_CONST bulitin, so I am simply forcing
> the flag in cgraphunit.c that is somewhat ugly.

But this also means that when attaching the attribute to pure/const
functions which result becomes unused and thus the call gets DCEd
will still emit the warning/error.  Similar if the function gets
inlined (formerly no warning/error).

I think you need an alternate lowering for the first case at least,
like passing through the return value.  Not sure how to deal with the 2nd
case.

That said, I don't think this is the way to go to implement the
attribute.

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

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

--- Comment #10 from Martin Liška <mliska at suse dot cz> ---
Fixed in r215967.
>From gcc-bugs-return-463424-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 08:57:11 2014
Return-Path: <gcc-bugs-return-463424-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21482 invoked by alias); 7 Oct 2014 08:57:11 -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 21450 invoked by uid 48); 7 Oct 2014 08:57:07 -0000
From: "ai.azuma at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()
Date: Tue, 07 Oct 2014 08:57: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.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ai.azuma 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: cc
Message-ID: <bug-62258-4-D5ue8usMvb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62258-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62258-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/msg00445.txt.bz2
Content-length: 671

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

Ai Azuma <ai.azuma at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ai.azuma at gmail dot com

--- Comment #4 from Ai Azuma <ai.azuma at gmail dot com> ---
PR61643 shares the root cause with this PR. The behavior of the test case in
PR61643 completely agrees with the analysis in Comment 2, and the proposed
patch makes the test case in PR61643 work properly.

I confirmed that this bug was reproduced with 4.8.4 20140925, 4.9.2 20140924
and 5.0.0 20140928.

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.