[Bug c++/62063] New: g++ disregards template specialization and skips try/catch blocks

[Bug c++/62063] New: g++ disregards template specialization and skips try/catch blocks

[ferenc.geczi at ericsson dot com]

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

            Bug ID: 62063
           Summary: g++ disregards template specialization and skips
                    try/catch blocks
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ferenc.geczi at ericsson dot com

Created attachment 33276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33276&action=edit
Source code for reproducing the reported issue

g++ disregards that template specialization might happen in a different
compilation unit. 

When compiling the attached example:

With -O0, it eliminates a catch block since it can instantiate a template
resulting a non throwing method, but disregards the specialization in which an
exception is actually thrown. Adding the '-fnon-call-exceptions' flag this
doesn't happen, but that flag shouldn't be required. 

With -O2 and -O3 even the try block gets eliminated, but in that case the
'-fnon-call-exceptions' doesn't help.

Please see attachment:

$ g++-4.9 -O0 -Wall Client.cpp Test.cpp main.cpp && ./a.out
        Throwing exception
terminate called after throwing an instance of 'int'
Aborted

$ g++-4.9 -O0 -Wall -fnon-call-exceptions Client.cpp Test.cpp main.cpp &&
./a.out
        Throwing exception
        Exception handled!
        END

$ g++-4.9 -O2 -Wall Client.cpp Test.cpp main.cpp && ./a.out
        END

$ g++-4.9 -O3 -Wall Client.cpp Test.cpp main.cpp && ./a.out
        END

$ g++-4.9 -O2 -Wall -fnon-call-exceptions Client.cpp Test.cpp main.cpp &&
./a.out
        END

$ g++-4.9 -O3 -Wall -fnon-call-exceptions Client.cpp Test.cpp main.cpp &&
./a.out
        END

For comparison, clang++ works as expected with -O0, without the
-fnon-callexceptions. 
Although it has the same the behavior with higher optimization levels.

[Bug c++/62063] g++ disregards template specialization and skips try/catch blocks

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ferenc Géczi from comment #0)
> Created attachment 33276 [details]
> Source code for reproducing the reported issue
> 
> g++ disregards that template specialization might happen in a different
> compilation unit. 

How is the compiler supposed to know that?

If you don't declare a specialization before it would be needed the compiler
will not use it, and the program has undefined behaviour.

> For comparison, clang++ works as expected with -O0, without the
> -fnon-callexceptions. 
> Although it has the same the behavior with higher optimization levels.

That should tell you your expectation is wrong.
>From gcc-bugs-return-458040-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 08 15:05:24 2014
Return-Path: <gcc-bugs-return-458040-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3588 invoked by alias); 8 Aug 2014 15:05:24 -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 3536 invoked by uid 48); 8 Aug 2014 15:05:19 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
Date: Fri, 08 Aug 2014 15:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords: diagnostic, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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-52904-4-pK0MaA4abh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52904-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52904-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-08/txt/msg00537.txt.bz2
Content-length: 912

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to kugan from comment #9)
> Incorrect warning is gone from the latest trunk build. VRP is now able to
> detect the correct range. This bug can now be closed.

Since it was probably fixed by accident, it will get unfixed by accident again.
If you don't add the testcase to the regression testsuite, this will happen
again:

https://gcc.gnu.org/wiki/HowToPrepareATestcase

If you add a testcase pointing to this PR, when it fails people can come back
here and read the discussion.
>From gcc-bugs-return-458041-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 08 15:18:56 2014
Return-Path: <gcc-bugs-return-458041-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10108 invoked by alias); 8 Aug 2014 15:18:56 -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 10077 invoked by uid 48); 8 Aug 2014 15:18:51 -0000
From: "ferenc.geczi at ericsson dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62063] g++ disregards template specialization and skips try/catch blocks
Date: Fri, 08 Aug 2014 15:18: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: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ferenc.geczi at ericsson dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62063-4-Bgnb2dcNeu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62063-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62063-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-08/txt/msg00538.txt.bz2
Content-length: 1712

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

--- Comment #2 from Ferenc Géczi <ferenc.geczi at ericsson dot com> ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Ferenc Géczi from comment #0)
> > Created attachment 33276 [details]
> > Source code for reproducing the reported issue
> > 
> > g++ disregards that template specialization might happen in a different
> > compilation unit. 
> 
> How is the compiler supposed to know that?
> 
> If you don't declare a specialization before it would be needed the compiler
> will not use it, and the program has undefined behaviour.
> 
> > For comparison, clang++ works as expected with -O0, without the
> > -fnon-callexceptions. 
> > Although it has the same the behavior with higher optimization levels.
> 
> That should tell you your expectation is wrong.

Indeed. (In reply to Jonathan Wakely from comment #1)
> (In reply to Ferenc Géczi from comment #0)
> > Created attachment 33276 [details]
> > Source code for reproducing the reported issue
> > 
> > g++ disregards that template specialization might happen in a different
> > compilation unit. 
> 
> How is the compiler supposed to know that?
> 
> If you don't declare a specialization before it would be needed the compiler
> will not use it, and the program has undefined behaviour.
> 
> > For comparison, clang++ works as expected with -O0, without the
> > -fnon-callexceptions. 
> > Although it has the same the behavior with higher optimization levels.
> 
> That should tell you your expectation is wrong.


Thank you for the quick reply, and I apologize for the false alarm.
Now I found it in the standard. You are absolutely right.
>From gcc-bugs-return-458042-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 08 15:33:19 2014
Return-Path: <gcc-bugs-return-458042-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18221 invoked by alias); 8 Aug 2014 15:33:19 -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 18170 invoked by uid 48); 8 Aug 2014 15:33:12 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/62061] FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2
Date: Fri, 08 Aug 2014 15:33: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.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak 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:
Message-ID: <bug-62061-4-ZAaeHG0MUc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62061-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62061-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-08/txt/msg00539.txt.bz2
Content-length: 453

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
This ICE can be triggered also on x86_64 Fedora 20 by passing
-fno-use-linker-plugin to testsuite flags:

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

FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto
-fabi-version=2 (internal compiler error)
>From gcc-bugs-return-458043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 08 15:37:58 2014
Return-Path: <gcc-bugs-return-458043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21772 invoked by alias); 8 Aug 2014 15:37: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 21744 invoked by uid 48); 8 Aug 2014 15:37:55 -0000
From: "roger.ferrer at bsc dot es" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62064] New: Private inheritance and conversion function id in class member access
Date: Fri, 08 Aug 2014 15:37: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.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: roger.ferrer at bsc dot es
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-62064-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-08/txt/msg00540.txt.bz2
Content-length: 3239

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

            Bug ID: 62064
           Summary: Private inheritance and conversion function id in
                    class member access
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: roger.ferrer at bsc dot es

Hi,

the snippet below causes an access error in g++ 4.9.1 if the
conversion-function-id is referenced in a class-member access.

Intel C++ 14.0.2 and clang 3.3 accept it.

This problem can be worked around with -fno-access-control

(There is also some weirdness like 'struct A A::A' in the diagnostic messages
themselves, but I guess this would belong to another bug)

Should the code be ill-formed, then the "OK" case should be rejected as well.

// -- test.cc
struct A
{
    typedef int some_type;
    operator some_type();
};

struct  B : private A
{
    typedef bool some_type;
    void foo(B &r)
    {
        B *p;
        B o;

        A::operator A::some_type(); // OK

        o.A::operator A::some_type(); // ERR
        r.A::operator A::some_type(); // ERR
        p->A::operator A::some_type(); // ERR
        (*this).A::operator A::some_type(); // ERR
    }
};
// -- end of test.cc

$ g++ --version
g++ (Debian 4.9.1-1) 4.9.1
$ g++ -c test.cc
test.cc: In member function ‘void B::foo(B&)’:
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:18:23: error: within this context
         o.A::operator A::some_type(); // ERR
                       ^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
     typedef int some_type;
                 ^
test.cc:18:26: error: within this context
         o.A::operator A::some_type(); // ERR
                          ^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:19:23: error: within this context
         r.A::operator A::some_type(); // ERR
                       ^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
     typedef int some_type;
                 ^
test.cc:19:26: error: within this context
         r.A::operator A::some_type(); // ERR
                          ^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:20:24: error: within this context
         p->A::operator A::some_type(); // ERR
                        ^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
     typedef int some_type;
                 ^
test.cc:20:27: error: within this context
         p->A::operator A::some_type(); // ERR
                           ^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:21:29: error: within this context
         (*this).A::operator A::some_type(); // ERR
                             ^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
     typedef int some_type;
                 ^
test.cc:21:32: error: within this context
         (*this).A::operator A::some_type(); // ERR
                                ^

Kind regards,
>From gcc-bugs-return-458044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 08 15:50:13 2014
Return-Path: <gcc-bugs-return-458044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31120 invoked by alias); 8 Aug 2014 15:50:13 -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 31075 invoked by uid 48); 8 Aug 2014 15:50:09 -0000
From: "tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57612] add builtin to assert that expression does not have side effects
Date: Fri, 08 Aug 2014 15:50: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: tromey 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:
Message-ID: <bug-57612-4-iet2ysEzSz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57612-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57612-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/msg00541.txt.bz2
Content-length: 276

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

--- Comment #1 from Tom Tromey <tromey at gcc dot gnu.org> ---
You can see the thread here:

http://patchwork.ozlabs.org/patch/343858/

My proposed patch didn't handle C++, which seems like
something it probably should do.

[Bug c++/62063] g++ disregards template specialization and skips try/catch blocks

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Closing.