https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #53 from postmas...@conky-be.bounceio.net ---
Created attachment 45108
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45108=edit
attachment-117920-1.eml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #52 from postmas...@conky-be.bounceio.net ---
Your email was bounced...
-
... because something went wrong between you and your recipient. Ugh!
What to do next?
Well, your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #51 from postmas...@conky-be.bounceio.net ---
Your email was bounced...
-
... because something went wrong between you and your recipient. Oh
no!
What to do next?
Well,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #50 from Jonathan Wakely ---
Author: redi
Date: Tue Nov 27 23:25:56 2018
New Revision: 266533
URL: https://gcc.gnu.org/viewcvs?rev=266533=gcc=rev
Log:
PR libstdc++/67843 set shared_ptr lock policy at build-time
This resolves a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #49 from Jonathan Wakely ---
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
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.
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=34224action=edit
config.log for compiler with the bug
Here is my config.log from cross compiler build.
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.
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
Alexander Varnin fenixk19 at mail dot ru changed:
What|Removed |Added
CC||fenixk19 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #41 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Damien Buhl (daminetreg) from comment #40)
I can also confirm the crash with gcc-4.8.1 for an arm platform.
You'll have to provide more information about your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
Damien Buhl (daminetreg) damien.buhl at lecbna dot org changed:
What|Removed |Added
CC|
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
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
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
$
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
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
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,
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
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
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
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:
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 ?
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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
--- 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.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- 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
--- 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
--
--- 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
--- 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)
--
--- 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,
--- 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=19580action=view)
preprocessor output generated by -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- 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=19581action=view)
assembly output generated by -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- 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=19582action=view)
output when running the test program through valgrind
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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,
--- 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.
--
--- 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
--- 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 ;)
--
53 matches
Mail list logo
