Bug 2159428 - digikam builds fail with gcc 11.3.1-4 (target specific option mismatch)
Summary: digikam builds fail with gcc 11.3.1-4 (target specific option mismatch)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: gcc
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Marek Polacek
QA Contact: Václav Kadlčík
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-09 14:44 UTC by Václav Kadlčík
Modified: 2023-07-18 14:25 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-01-12 17:50:15 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
build.log (see #c2) (6.49 MB, text/plain)
2023-01-10 08:35 UTC, Václav Kadlčík
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 102059 0 P3 RESOLVED Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10") 2023-01-24 12:20:26 UTC
Red Hat Issue Tracker RHELPLAN-144538 0 None None None 2023-01-09 14:52:12 UTC

Internal Links: 1996330

Description Václav Kadlčík 2023-01-09 14:44:51 UTC
Description of problem:

digikam is still failing with 11.3.1-4:

/usr/include/eigen3/Eigen/src/Core/util/BlasUtil.h:227:46: error: inlining failed in call to 'always_inline' 'Eigen::internal::blas_data_mapper<double, long, 0, 0, 1>::storePacketBlock<double __vector(2), 4>(long, long, Eigen::internal::PacketBlock<double __vector(2), 4> const&) constvoid': target specific option mismatch

See https://koji.fedoraproject.org/koji/taskinfo?taskID=95750885

Found and pointed out by Orion Poplawski in bz2140266#c8.


Version-Release number of selected component (if applicable):

gcc-11.3.1-4.el9


Additional info:

bz2140266 but its fix seems not to help with digikam

Comment 1 Václav Kadlčík 2023-01-09 14:48:22 UTC
(In reply to Václav Kadlčík from comment #0)
...
> bz2140266 but its fix seems not to help with digikam

should have been "bz2140266 seems related but ..."

Comment 2 Václav Kadlčík 2023-01-10 08:32:04 UTC
Reproduced without Koji and without mock on a RHEL 9.2 build
with gcc-11.3.1-4.3.el9.ppc64le:

1. Install/enable the CodeReady (CRB) and EPEL repositories

2. Install packages according to attached rpms.txt

3. Prepare the sources:

     mkdir -p rpmbuild/SPECS rpmbuild/SOURCES
     wget -O rpmbuild/SPECS/digikam.spec \
       https://src.fedoraproject.org/rpms/digikam/raw/59a551c6c1b4a104452a8ab4124cca5c6444cd57/f/digikam.spec
     wget -O rpmbuild/SOURCES/digiKam-7.9.0.tar.xz \
       https://ftp.fi.muni.cz/pub/kde/stable/digikam/7.9.0/digiKam-7.9.0.tar.xz

4. Add dependencies if missing:

     dnf builddep -y rpmbuild/SPECS/digikam.spec 

5. Build and check:

     rpmbuild -ba rpmbuild/SPECS/digikam.spec |& tee build.log
     echo $?
     grep error: build.log

Comment 4 Václav Kadlčík 2023-01-10 08:35:46 UTC
Created attachment 1937047 [details]
build.log (see #c2)

Comment 5 Marek Polacek 2023-01-12 17:50:15 UTC
OK, so this error persists:

/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h: In function 'Eigen::internal::storeAccumulator<Eigen::internal::blas_data_mapper<double, long, 0, 0, 1>, long, double __vector(2), 2l>(long, long, Eigen::internal::blas_data_mapper<double, long, 0, 0, 1> const&, double __vector(2) const&, __vector_quad*)void':
/usr/include/eigen3/Eigen/src/Core/util/BlasUtil.h:227:46: error: inlining failed in call to 'always_inline' 'Eigen::internal::blas_data_mapper<double, long, 0, 0, 1>::storePacketBlock<double __vector(2), 4>(long, long, Eigen::internal::PacketBlock<double __vector(2), 4> const&) constvoid': target specific option mismatch

and I think that's because part of the fix was only applied to GCC 12:
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059#c34>:
"I don't think the r12-6219 commit qualifies for backporting."

This comment <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059#c35>
mentions a few workarounds.  Maybe disabling LTO on ppc64le would help as well.

So I don't think I can backport a fix for this one, sorry.


Note You need to log in before you can comment on or make changes to this bug.