[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[nacitar at gmail dot com]

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

Jacob McIntosh <nacitar at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nacitar at gmail dot com

--- Comment #29 from Jacob McIntosh <nacitar at gmail dot com> 2010-10-15 18:46:05 UTC ---
This bug is not invalid.


If you build with

g++ -std=c++0x -pthread -march=i386 whatever.cpp
A binary built in this way exhibits the bug the reporter mentions.

Also, on a 64-bit system

g++ -std=c++0x -pthread -m32 -march=i386 whatever.cpp
This also builds a binary with this issue.


The -march is what you guys missed to trigger this issue.

i486 works
i586 works
i686 works
pentium4 works
i386 exhibits the error mentioned by the reporter


Tested with g++ 4.4.3 on a 32-bit mandrake system, a 64-bit gentoo system, and
a 64-bit ubuntu system.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |

--- Comment #30 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-15 18:48:54 UTC ---
i386 does not have sync builtins.  I wonder if doing -march=i386 changes the
ABI ...

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu.org]

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

--- Comment #31 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-15 19:27:37 UTC ---
ah, I see ... IIRC execute_native_thread_method uses shared_ptr which uses
atomic builtins which are missing on i386

so yes, -march=i386 changes the ABI, you need to build libstdc++ with that
-march switch

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu.org]

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

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-15 19:37:46 UTC ---
I'm not sure -march=i386 explains the original report, since the OP said his
compiler command was:

$ g++ -std=c++0x -pthread thread.cc -o thread

Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile
with (implicit or explicit) march=i386 ?
If not, the library will think it can use builtins which aren't available.  I
seem to recall known issues arising from mismatches in -march options used when
building and using the library.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu.org]

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

--- Comment #33 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-15 19:45:22 UTC ---
hmm, I should check, but I'm not home right now ... the problem could be that
that the library only checks SYNC_HAVE_COMPARE_AND_SWAP t configure time, and
(I think) pre-defines _GLIBCXX_ATOMIC_BUILTINS in config.h, which causes the
library headers to think we have the sync builtins, even if the user later uses
-march=i386 which disables them.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[nacitar at gmail dot com]

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

--- Comment #34 from Jacob McIntosh <nacitar at gmail dot com> 2010-10-15 19:46:56 UTC ---
(In reply to comment #32)
> I'm not sure -march=i386 explains the original report, since the OP said his
> compiler command was:
> 
> $ g++ -std=c++0x -pthread thread.cc -o thread
> 
> Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile
> with (implicit or explicit) march=i386 ?
> If not, the library will think it can use builtins which aren't available.  I
> seem to recall known issues arising from mismatches in -march options used when
> building and using the library.

Maybe by default, his gcc installation/configuration builds i386 (or some other
arch that has the same problem even), and it didn't seem relevant to mention. 
I'm unsure how gcc determines its default, but that seems a likely scenario to
me.

And I can reproduce it by explicitly specifying i386, so I'm inclined to think
this is the case.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu.org]

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

--- Comment #35 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-15 20:06:55 UTC ---
(In reply to comment #34)
> (In reply to comment #32)
> > I'm not sure -march=i386 explains the original report, since the OP said his
> > compiler command was:
> > 
> > $ g++ -std=c++0x -pthread thread.cc -o thread
> > 
> > Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile
> > with (implicit or explicit) march=i386 ?
> > If not, the library will think it can use builtins which aren't available.  I
> > seem to recall known issues arising from mismatches in -march options used when
> > building and using the library.
> 
> Maybe by default, his gcc installation/configuration builds i386 (or some other
> arch that has the same problem even), and it didn't seem relevant to mention. 
> I'm unsure how gcc determines its default, but that seems a likely scenario to
> me.

But in that case the library would have been configured and built with the same
option, so every thing should match.

> And I can reproduce it by explicitly specifying i386, so I'm inclined to think
> this is the case.

Yes, but then you have a mismatch between the already built libstdc++.so and
the new objects you link to it.

I'm not saying you're wrong, just that it *should* to work if you configure and
build for the exact same target.  It's less surprising (though still not good)
if things fail when you mix'n'match, basically because i386 is crippled
compared to other x86 targets.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo.carlini at oracle dot com]

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

--- Comment #36 from Paolo Carlini <paolo.carlini at oracle dot com> 2010-10-15 23:41:54 UTC ---
(In reply to comment #32)
> Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile
> with (implicit or explicit) march=i386 ?

I'm jumping in just in case this point hasn't been clarified already: I added
to the front end the __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros, and indeed, are
sensitive to the *actual* command-line options: with -march=i386 are definitely
undefined.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu.org]

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

--- Comment #37 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-16 13:31:33 UTC ---

What I was thinking of is that bits/c++config.h defines the following based on
what was supported at the time the library is configured and built, not what is
supported later when users compile:

/* Define if builtin atomic operations for bool are supported on this host. */
#define _GLIBCXX_ATOMIC_BUILTINS_1 1

But I don't think <thread> depends on that. <future> and <atomic> do.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu.org]

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

--- Comment #38 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-16 15:54:16 UTC ---
I can confirm that this crash happens with GCC 4.4 when using -march=i386

But it isn't a problem with 4.5 and 4.6 because it fails to link

$ ~/gcc/4.5/bin/g++  -std=c++0x t.cc  -m32 -march=i386 -pthread
/tmp/ccxpaful.o: In function `__gnu_cxx::__exchange_and_add(int volatile*,
int)':
t.cc:(.text+0x3c): undefined reference to `__sync_fetch_and_add_4'
collect2: ld returned 1 exit status

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo.carlini at oracle dot com]

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

--- Comment #39 from Paolo Carlini <paolo.carlini at oracle dot com> 2010-10-17 09:56:52 UTC ---
I don't know exactly what we are doing in such headers but for sure if we have
facilities which rely vitally on atomic builtins either should be disabled
*completely* when the builtins are not actually available or the use of the
builtins should be moved to functions exported by the .so (and then at build
time either use as implementation details the atomic builtins or a slow fall
back, like we do for <string>, more or less)

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[damien.buhl at lecbna dot org]

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

Damien Buhl (daminetreg) <damien.buhl at lecbna dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |damien.buhl at lecbna dot org

--- Comment #40 from Damien Buhl (daminetreg) <damien.buhl at lecbna dot org> ---
I can also confirm the crash with gcc-4.8.1 for an arm platform. 

Everything compiles fine, but on the platform the support for atomics looks
like missing, because it dies with pure virtual method called.

Using boost::thread which uses boost::atomic and in this case implements atomic
self (not via the gcc compiler) is the only workaround I found without
recompiling the compiler with atomic support.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[fenixk19 at mail dot ru]

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

Alexander Varnin <fenixk19 at mail dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fenixk19 at mail dot ru

--- Comment #42 from Alexander Varnin <fenixk19 at mail dot ru> ---
I confirm an issue with G++ 4.8.2 and ARM platform.

The platform is Freescale IMX53. OS build with yocto system using these
instructions: https://github.com/Freescale/fsl-community-bsp-platform

uname -a:
Linux imx53qsb 2.6.35.3-gb51e9aa-dirty #34 PREEMPT Wed Dec 3 19:47:54 MSK 2014
armv7l GNU/Linux

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[fenixk19 at mail dot ru]

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

--- Comment #43 from Alexander Varnin <fenixk19 at mail dot ru> ---
And I also confirm that adding -latomic to build options fixes the issue.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[damien.buhl at lecbna dot org]

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

--- Comment #44 from Damien Buhl (daminetreg) <damien.buhl at lecbna dot org> ---
On a yocto built cross-toolchain adding -latomic didn't help. This may
be due to the yocto cross-toolchain built without the support for some
reason.

I'll explorate it in deeper details.

On 12/04/2014 01:52 PM, fenixk19 at mail dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
> 
> --- Comment #43 from Alexander Varnin <fenixk19 at mail dot ru> ---
> And I also confirm that adding -latomic to build options fixes the issue.
>

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[fenixk19 at mail dot ru]

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

--- Comment #45 from Alexander Varnin <fenixk19 at mail dot ru> ---
(In reply to Damien Buhl (daminetreg) from comment #44)

While given test works properly with -latomic on my installation, my
application doesn't. It fails with segfault in approximately half of launches.
Core dump points to some thread execution code. I suppose, it is still broken
in some way.

Replacing std::thread in my code with pthread_* makes it work properly.

So I conclude, that this std::thread and atomic things is broken on my gcc
4.8.2 arm freescale imx53 yocto build.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[damien.buhl at lecbna dot org]

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

--- Comment #46 from Damien Buhl (daminetreg) <damien.buhl at lecbna dot org> ---
As a pretier alternative you can use boost::thread with boost::atomic as
backend as we did in a yocto cross toolchain with the same issue where latomic
also segfaulted.

Cheers

fenixk19 at mail dot ru <gcc-bugzilla@gcc.gnu.org> a écrit :

>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
>
>--- Comment #45 from Alexander Varnin <fenixk19 at mail dot ru> ---
>(In reply to Damien Buhl (daminetreg) from comment #44)
>
>While given test works properly with -latomic on my installation, my
>application doesn't. It fails with segfault in approximately half of launches.
>Core dump points to some thread execution code. I suppose, it is still broken
>in some way.
>
>Replacing std::thread in my code with pthread_* makes it work properly.
>
>So I conclude, that this std::thread and atomic things is broken on my gcc
>4.8.2 arm freescale imx53 yocto build.
>
>-- 
>You are receiving this mail because:
>You are on the CC list for the bug.
>From gcc-bugs-return-469518-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 05 02:20:21 2014
Return-Path: <gcc-bugs-return-469518-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19032 invoked by alias); 5 Dec 2014 02:20: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 19014 invoked by uid 89); 5 Dec 2014 02:20:18 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_DBL_ABUSE_REDIR,URIBL_DBL_REDIR autolearn=ham version=3.3.2
X-HELO: mail-yh0-f67.google.com
Received: from mail-yh0-f67.google.com (HELO mail-yh0-f67.google.com) (209.85.213.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 05 Dec 2014 02:20:17 +0000
Received: by mail-yh0-f67.google.com with SMTP id a41so2477919yho.10        for <gcc-bugs@gcc.gnu.org>; Thu, 04 Dec 2014 18:20:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr17736008yhg.126.1417746015619; Thu, 04 Dec 2014 18:20:15 -0800 (PST)
Received: by 10.170.162.85 with HTTP; Thu, 4 Dec 2014 18:20:15 -0800 (PST)
Date: Fri, 05 Dec 2014 02:20:00 -0000
Message-ID: <CAL3UPOdpTYGAtSBcGASTxYLG7xG7P34L2z4doW0z1sWYOn=7oQ@mail.gmail.com>
Subject: A problem of template implicit instantiation
From: Yu Sheng Oh <humbleoh@gmail.com>
To: gcc-bugs <gcc-bugs@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2014-12/txt/msg00525.txt.bz2
Content-length: 972

HI,

I have a piece of code at "http://goo.gl/r2ySE6"

Refer to the code, with option of "-O2 -std=c++1y", when we comment
out the statement "id<int>;" clang-3.4.1 compiles the code
successfully, but g++-4.9.0 compiles failed, where g++ complains that
"unresolved overloaded function type", which in turn implies that at
the point of calling compose function, id<int> is not instantiated.

"3. Unless a function template specialization has been explicitly
instantiated or explicitly specialized, *the function template
specialization is implicitly instantiated  when the specialization is
referenced in a context that requires a function definition to exist.*
"[temp.inst]

At the point of calling the compose function, the function definition
for id<int> is required, and so, id<int> should be implicitly
instantiated.

Based on my argument, it is a bug in g++-4.9.0, but I am not 100% sure
of it. Please advice.

PS: Yongwei Wu is credited for discovering the problem.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[damien.buhl at lecbna dot org]

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

--- Comment #47 from Damien Buhl (daminetreg) <damien.buhl at lecbna dot org> ---
So our GCC with the problem has been configured and built by yocto-poky the
following way :   

```  
Using built-in specs.  
COLLECT_GCC=arm-poky-linux-gnueabi-gcc-4.8.1  
COLLECT_LTO_WRAPPER=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.1/lto-wrapper 
Target: arm-poky-linux-gnueabi  
Configured with:
/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/work-shared/gcc-4.8.1-r0/gcc-4.8.1/configure
--build=i686-linux --host=i686-linux --target=arm-poky-linux-gnueabi
--prefix=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr
--exec_prefix=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr
--bindir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
--sbindir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
--libexecdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi
--datadir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share
--sysconfdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/etc
--sharedstatedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/com
--localstatedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/var
--libdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/lib/armv7a-vfp-neon-poky-linux-gnueabi
--includedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/include
--oldincludedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/include
--infodir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share/info
--mandir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux
--enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++
--enable-threads=posix --disable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-poky-linux-gnueabi- --without-local-prefix
--enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap
--disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu
--enable-linker-build-id --with-ppl=no --with-cloog=no
--enable-checking=release --enable-cheaders=c_global
--with-gxx-include-dir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500/usr/include/c++
--with-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500
--with-build-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500
--enable-poison-system-directories --disable-libunwind-exceptions
--with-mpfr=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr
--with-system-zlib --disable-nls  
Thread model: posix  
gcc version 4.8.1 (GCC)   
```  

We have now updated to 4.9.1, I'll tell you the bug still happens with 4.9.1.  

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

 --- Comment #45 from Alexander Varnin  --- 
 (In reply to Damien Buhl (daminetreg) from comment #44) 

 While given test works properly with -latomic on my installation, my 
 application doesn't. It fails with segfault in approximately half of launches. 
 Core dump points to some thread execution code. I suppose, it is still broken 
 in some way. 

 Replacing std::thread in my code with pthread_* makes it work properly. 

 So I conclude, that this std::thread and atomic things is broken on my gcc 
 4.8.2 arm freescale imx53 yocto build. 

 --  
 You are receiving this mail because: 
 You are on the CC list for the bug.
>From gcc-bugs-return-469762-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 08 15:56:53 2014
Return-Path: <gcc-bugs-return-469762-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12336 invoked by alias); 8 Dec 2014 15:56: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 12307 invoked by uid 48); 8 Dec 2014 15:56:47 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
Date: Mon, 08 Dec 2014 15:56: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.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktkachov 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-64225-4-glSpY0Y2jR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64225-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64225-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-12/txt/msg00769.txt.bz2
Content-length: 638

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #6)
> fold-const.c has a comment in the relevant case that says:
>  /* Canonicalize x*x as pow(x,2.0), which is expanded as x*x.  */

I think this comment is misleading.
In builtins.c the expand_builtin_mathfn_2 handles the expansion of pow and I
don't see any code to expand pow (x, 2.0) as x * x. It tries to use the pow
optab, so unless the backend explicitly expands the case in such a manner, it
will not be converted to x*x.

Is there some other place in the compiler that plays a role here?

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[fenixk19 at mail dot ru]

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

--- Comment #48 from Alexander Varnin <fenixk19 at mail dot ru> ---
Created attachment 34224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34224&action=edit
config.log for compiler with the bug

Here is my config.log from cross compiler build.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu.org]

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

--- Comment #49 from Jonathan Wakely <redi at gcc dot gnu.org> ---
std::thread no longer uses shared_ptr on trunk, so no longer depends on atomics
and doesn't break if you mix objects compiled with and without native atomics,
e.g. mixing objects built for i386 with objects built for i686, or mixing
objects built for armv5 with objects built for armv7.

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #28 from paolo dot carlini at oracle dot com  2010-01-16 10:10 -------
Feedback not forthcoming.


-- 

paolo dot carlini at oracle dot com changed:

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


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #27 from phil at nwl dot cc  2010-01-16 01:08 -------
(In reply to comment #26)
> Hey, I'm telling you the way we all library maintainers (like me) and users
> check the library: they all fetch everything (either mainline or 4_4-branch, or
> whatever) via svn, make, make check. Now you want to do something else, you
> want to check the compiler + library you have already installed, but your
> obviously missing the testsuite, because you didn't build it yourself. Now, you
> are on your own, because I have no idea how and where to fetch only the
> testsuite of the specific GCC you are running on the specific Linux you are
> running, and then adjust everything to run it with your already installed
> compiler, this is not the normal way we do those tests.
> 
> To repeat, the point was checking that your Linux and your hardware are sane,
> because I told you already that we know **for sure** that on current (and no so
> current) machines and Ubuntu, OpenSUSE, Fedora, whatever, that snippet works
> perfectly fine and *much* more than it, a whole testsuite.
> 
> So, it's up to you, I'll keep this open: if over the nest month or so you
> provide the testresults you get for either your specific GCC, current
> 4_4-branch, or current mainline on your OS + hardware, we can hope to make
> progress on your issue, otherwise nobody will commit suicide, and the issue
> will be simply closed for lack of meaningful feedback from submitter.

It's ok man, no offense here. I really didn't want to stomp on any feet.

All I'm trying to do is to figure out why I'm having this problem and how to
fix it. Abusing this bug tracker for a little conversation was a pleasure to
me, getting you upset wasn't my intention. My apologies for that.

So I will just do as you say and try to fix my distribution (or bug it's
maintainers) instead of getting into your way. Anyway, thanks a lot for your
help so far.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #26 from paolo dot carlini at oracle dot com  2010-01-16 00:05 -------
Hey, I'm telling you the way we all library maintainers (like me) and users
check the library: they all fetch everything (either mainline or 4_4-branch, or
whatever) via svn, make, make check. Now you want to do something else, you
want to check the compiler + library you have already installed, but your
obviously missing the testsuite, because you didn't build it yourself. Now, you
are on your own, because I have no idea how and where to fetch only the
testsuite of the specific GCC you are running on the specific Linux you are
running, and then adjust everything to run it with your already installed
compiler, this is not the normal way we do those tests.

To repeat, the point was checking that your Linux and your hardware are sane,
because I told you already that we know **for sure** that on current (and no so
current) machines and Ubuntu, OpenSUSE, Fedora, whatever, that snippet works
perfectly fine and *much* more than it, a whole testsuite.

So, it's up to you, I'll keep this open: if over the nest month or so you
provide the testresults you get for either your specific GCC, current
4_4-branch, or current mainline on your OS + hardware, we can hope to make
progress on your issue, otherwise nobody will commit suicide, and the issue
will be simply closed for lack of meaningful feedback from submitter.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #25 from phil at nwl dot cc  2010-01-15 23:49 -------
(In reply to comment #24)
> (In reply to comment #23)
> > What we want to do is to run the libstdc++ testsuite with my
> > distribution-provided g++, in order to see whether it's generally broken or
> > not, right?
> 
> Wrong. You can't use one compiler (older, by the way), with a newer libstdc++.
> 
> > And what I'm criticising here is that I have to compile *anything* of the
> > gcc-sources in order to run the testsuite. I see no sense in building any
> > binaries at all, since I already have all binaries (executables as well as
> > libraries) in order to run the tests?!
> 
> You don't, you *need* a complete new GCC.

Ok. So what's the point in doing this, then?


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #24 from paolo dot carlini at oracle dot com  2010-01-15 23:07 -------
(In reply to comment #23)
> What we want to do is to run the libstdc++ testsuite with my
> distribution-provided g++, in order to see whether it's generally broken or
> not, right?

Wrong. You can't use one compiler (older, by the way), with a newer libstdc++.

> And what I'm criticising here is that I have to compile *anything* of the
> gcc-sources in order to run the testsuite. I see no sense in building any
> binaries at all, since I already have all binaries (executables as well as
> libraries) in order to run the tests?!

You don't, you *need* a complete new GCC.



-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #23 from phil at nwl dot cc  2010-01-15 22:32 -------
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #18)
> > > Just build everything with default configure options, then go inside the
> > > libstdc++-v3 *build* dir and type 'make check'.
> > 
> > Ah, hmm. Well, having to compile everything in order to run the tests using an
> > external compiler is a bit of a bummer, isn't it?
> 
> Maybe there is a communication problem here: I meant, *the whole GCC*,

Yes, it seems so.

> normally, with no special options, to keep things simple. If you want, you can
> exclude java, which normally takes a while, and fortran, and objective c, the
> languages you don't need in other terms: just pass --enable-languages=c++ and
> nothing else.

What we want to do is to run the libstdc++ testsuite with my
distribution-provided g++, in order to see whether it's generally broken or
not, right?

And what I'm criticising here is that I have to compile *anything* of the
gcc-sources in order to run the testsuite. I see no sense in building any
binaries at all, since I already have all binaries (executables as well as
libraries) in order to run the tests?!


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #22 from paolo dot carlini at oracle dot com  2010-01-15 22:15 -------
(In reply to comment #21)
> (In reply to comment #18)
> > Just build everything with default configure options, then go inside the
> > libstdc++-v3 *build* dir and type 'make check'.
> 
> Ah, hmm. Well, having to compile everything in order to run the tests using an
> external compiler is a bit of a bummer, isn't it?

Maybe there is a communication problem here: I meant, *the whole GCC*,
normally, with no special options, to keep things simple. If you want, you can
exclude java, which normally takes a while, and fortran, and objective c, the
languages you don't need in other terms: just pass --enable-languages=c++ and
nothing else.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #21 from phil at nwl dot cc  2010-01-15 22:07 -------
(In reply to comment #18)
> Just build everything with default configure options, then go inside the
> libstdc++-v3 *build* dir and type 'make check'.

Ah, hmm. Well, having to compile everything in order to run the tests using an
external compiler is a bit of a bummer, isn't it?

Compiling will take some time on this X40, so please be patient. :)


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #20 from paolo dot carlini at oracle dot com  2010-01-15 02:05 -------
Normally should look, for your i686 target, like the final part of this:

  http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01263.html

(please disregard the 23_containers failures, it's a temporary problem, will go
away soon)


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #19 from paolo dot carlini at oracle dot com  2010-01-15 02:02 -------
(we are not particularly interested in the g++ testresults, that this the
results for the C++ front-end proper, we are interested in the library results)


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #18 from paolo dot carlini at oracle dot com  2010-01-15 02:00 -------
Just build everything with default configure options, then go inside the
libstdc++-v3 *build* dir and type 'make check'.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #17 from phil at nwl dot cc  2010-01-15 01:55 -------
(In reply to comment #16)
> (output files g++.{log,sum} follow as attachments)

Mkay, bugzilla doesn't like the big logs. Meanwhile, take these:
- http://nwl.cc/~n0-1/g++.log
- http://nwl.cc/~n0-1/g++.sum


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #16 from phil at nwl dot cc  2010-01-15 01:49 -------
(In reply to comment #14)
> I'll give the testsuite a try, but this will take some time (svn checkout is
> still running).
> 

Oh boy, here it comes. I hope I've done the right thing, as there is little
documentation about how to run the testsuite ('make check-g++' seems not to
work for testing out-of-tree-binaries).

What I did:
- checkout svn://gcc.gnu.org/svn/gcc/trunk
- cd $checkout/gcc && runtest --tool g++ --srcdir ./testsuite
(output files g++.{log,sum} follow as attachments)

I'll appreciate instructions if this was all useless. :)


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #15 from paolo dot carlini at oracle dot com  2010-01-14 01:58 -------
(In reply to comment #14)
> Believe it or not, "nuty" is actually the hostname of the system in question.
> ;)
> 
> The distribution is Arch Linux.

Believe it or not, I don't know Arch Linux either ;)


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #14 from phil at nwl dot cc  2010-01-14 01:13 -------
(In reply to comment #12)
> Before anything else, you should make sure your system is otherwise sane, I
> don't know "Linux nuty" and I have no idea if it's affected by specific issues.

Believe it or not, "nuty" is actually the hostname of the system in question.
;)

The distribution is Arch Linux.

> Thus, first, I would suggest you to run the testsuite, which among many other
> things includes lots of tests of the <thread> facilities, which should all pass
> on x86 and x86_64 linux, see the gcc-testresults mailing list. If <thread> were
> broken as seriously as you are reporting on the main Linux distros, we would
> definitely know by now, because the testsuite tests *much* more than your
> snippet.

I'll give the testsuite a try, but this will take some time (svn checkout is
still running).


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu dot org]

------- Comment #13 from redi at gcc dot gnu dot org  2010-01-13 23:34 -------
(In reply to comment #9)
> But note that I can't reproduce it on x86_64 and -m32

It is possible to build a non-multilib 32-bit-only compiler on x86_64 - HJ gave
Benjamin the right configure commands recently.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2010-01-13 23:09 -------
Before anything else, you should make sure your system is otherwise sane, I
don't know "Linux nuty" and I have no idea if it's affected by specific issues.
Thus, first, I would suggest you to run the testsuite, which among many other
things includes lots of tests of the <thread> facilities, which should all pass
on x86 and x86_64 linux, see the gcc-testresults mailing list. If <thread> were
broken as seriously as you are reporting on the main Linux distros, we would
definitely know by now, because the testsuite tests *much* more than your
snippet.




-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #11 from phil at nwl dot cc  2010-01-13 22:52 -------
(In reply to comment #9)
> But note that I can't reproduce it on x86_64 and -m32
> 

Was told that, too. So what can I do to support you? What additional
information should I provide? I could probably setup some shell access to the
faulty machine (have to setup some dyndns first, though).


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2010-01-13 22:39 -------
But note that I can't reproduce it on x86_64 and -m32


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #10 from paolo dot carlini at oracle dot com  2010-01-13 22:40 -------
-m64 (the default) is also fine, of course.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #8 from phil at nwl dot cc  2010-01-13 22:37 -------
(In reply to comment #4)
> I cannot reproduce the problem in current 4_4-branch and mainline. Jon does it
> make any sense to you? 
> 

It seems like this bug exists only on x86 machines, but I don't have any x86_64
machine with gcc-4.4 available to verify that.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #7 from phil at nwl dot cc  2010-01-13 22:34 -------
(In reply to comment #6)
> does the g++ binary, gcc (GCC) 4.4.2 20091208 (prerelease), match the shared
> library, /usr/lib/libstdc++.so.6.0.13?
>

Yes, it does. The executable is linked against libstdc++.so.6, being a symlink
to libstdc++.so.6.0.13.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu dot org]

------- Comment #6 from redi at gcc dot gnu dot org  2010-01-13 21:37 -------
does the g++ binary, gcc (GCC) 4.4.2 20091208 (prerelease), match the shared
library, /usr/lib/libstdc++.so.6.0.13?


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[redi at gcc dot gnu dot org]

------- Comment #5 from redi at gcc dot gnu dot org  2010-01-13 21:33 -------
It would be a lot easier to view the attachments if they were labelled as text
files, but no, I can't see how this can happen.


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2010-01-13 20:40 -------
I cannot reproduce the problem in current 4_4-branch and mainline. Jon does it
make any sense to you? 


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely dot gcc at gmail dot
                   |                            |com
      Known to work|                            |4.4.3 4.5.0


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #3 from phil at nwl dot cc  2010-01-13 20:23 -------
Created an attachment (id=19582)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19582&action=view)
output when running the test program through valgrind


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #2 from phil at nwl dot cc  2010-01-13 20:23 -------
Created an attachment (id=19581)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19581&action=view)
assembly output generated by -save-temps


-- 


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

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[phil at nwl dot cc]

------- Comment #1 from phil at nwl dot cc  2010-01-13 20:22 -------
Created an attachment (id=19580)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19580&action=view)
preprocessor output generated by -save-temps


-- 


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