Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1794094
| Summary: | gcc-10.0.1-0.4.fc32: internal compiler error: in nothrow_spec_p, at cp/except.c:1247 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Miro Hrončok <mhroncok> | ||||
| Component: | gcc | Assignee: | Tom Hughes <tom> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | a.alvarezayllon, aoliva, avi.kivity, cstratak, dmalcolm, fweimer, jakub, jason, jwakely, kdudka, law, mhroncok, mpolacek, msebor, nickc, ppisar, sipoyare, tom, vitaly | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gcc-10.0.1-0.6.fc32 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-01-28 09:35:57 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1750908, 1785415, 1792464, 1794011, 1794065, 1794285, 1794291, 1794292, 1794294, 1794295, 1794297, 1794336 | ||||||
| Attachments: |
|
||||||
I can reproduce this but I really need to know how to get python's build system to tell me the actual compile command it is using so I can create preprocessed source to report it - do you know how to do that? Oh hang on it has already saved it! This is an ICE from gcc building with gcc 10 and persists with annobin disabled. I will attach the preprocessed source... Created attachment 1654648 [details] Preprocessed source Building gcc-10.0.1-0.4.fc32.x86_64 this ICEs: /usr/libexec/gcc/x86_64-redhat-linux/10/cc1plus -quiet -I /home/thh/rpm/BUILD/pyosmium-2.15.3/lib -I /usr/include/python3.8 -D_GNU_SOURCE -D _FILE_OFFSET_BITS=64 -D _LARGEFILE_SOURCE -D _replication_EXPORTS -D _FORTIFY_SOURCE=2 -D _GLIBCXX_ASSERTIONS -D VERSION_INFO="2.15.3" -D NDEBUG /home/thh/rpm/BUILD/pyosmium-2.15.3/lib/replication.cc -quiet -dumpbase replication.cc -m64 -mtune=generic -march=x86-64 -auxbase-strip CMakeFiles/_replication.dir/lib/replication.cc.o -g -grecord-gcc-switches -O2 -O2 -Wall -Werror=format-security -std=c++11 -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full -fPIC -fvisibility=hidden -flto -fno-fat-lto-objects -iplugindir=/usr/lib/gcc/x86_64-redhat-linux/10/plugin -o /dev/null -frandom-seed=0 -fdump-noaddr In file included from /usr/include/pybind11/cast.h:13, from /usr/include/pybind11/attr.h:13, from /usr/include/pybind11/pybind11.h:44, from /home/thh/rpm/BUILD/pyosmium-2.15.3/lib/replication.cc:1: /usr/include/pybind11/pybind11.h: In constructor ‘pybind11::class_<type_, options>::class_(pybind11::handle, bool)’: /usr/include/pybind11/pybind11.h:1058:5: internal compiler error: in nothrow_spec_p, at cp/except.c:1247 1058 | PYBIND11_OBJECT(class_, generic_type, PyType_Check) | ^~~~~~~~~~~~~~~ Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions. Which is a regression introduced within the last week for those who don't want to dig into GCC bugzilla. *** Bug 1794394 has been marked as a duplicate of this bug. *** *** Bug 1794410 has been marked as a duplicate of this bug. *** |
pyosmium fails to build with Python 3.9.0a2. -- Build files have been written to: /builddir/build/BUILD/pyosmium-2.15.3/build/temp.linux-x86_64-3.9 Scanning dependencies of target _replication Scanning dependencies of target _osmium [ 6%] Building CXX object CMakeFiles/_replication.dir/lib/replication.cc.o [ 13%] Building CXX object CMakeFiles/_osmium.dir/lib/osmium.cc.o *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event | Plugins PLUGIN_FINISH_UNIT | annobin: Generate final annotations PLUGIN_START_UNIT | annobin: Generate global annotations PLUGIN_ALL_PASSES_START | annobin: Generate per-function annotations PLUGIN_ALL_PASSES_END | annobin: Register per-function end symbol In file included from /usr/include/pybind11/cast.h:13, from /usr/include/pybind11/attr.h:13, from /usr/include/pybind11/pybind11.h:44, from /builddir/build/BUILD/pyosmium-2.15.3/lib/replication.cc:1: /usr/include/pybind11/pybind11.h: In constructor ‘pybind11::class_<type_, options>::class_(pybind11::handle, bool)’: /usr/include/pybind11/pybind11.h:1058:5: internal compiler error: in nothrow_spec_p, at cp/except.c:1247 1058 | PYBIND11_OBJECT(class_, generic_type, PyType_Check) | ^~~~~~~~~~~~~~~ This seems like and error unrelated to Python 3.9 but rather gcc 10. Is still blocks the Python 3.9 rebuild. Let's watch https://koschei.fedoraproject.org/package/pyosmium?collection=f32 to see if it will happen in regular Fedora as well. For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01172927-pyosmium/ For all our attempts to build pyosmium with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/pyosmium/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Let us know here if you have any questions. Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.