[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #10 from Jakub Jelinek --- Fixed for 10.5 too.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:16bdaf29ff9df3c3c70ecc07bb37511d456d05c6 commit r10-11341-g16bdaf29ff9df3c3c70ecc07bb37511d456d05c6 Author: Jakub Jelinek Date: Mon Oct 24 17:53:16 2022 +0200 c, c++: Fix up excess precision handling of scalar_to_vector conversion [PR107358] As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess precision promotions (or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid diagnostics that say float vector + float involves truncation (on ia32 from long double to float). The following patch fixes that by calling scalar_to_vector on the operands before the excess precision promotions, let scalar_to_vector just do the diagnostics (it does e.g. fold_for_warn so it will fold EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then do the actual conversions using the excess precision promoted operands (so say if we have vector double + (float + float) we don't actually do vector double + (float) ((long double) float + (long double) float) but vector double + (double) ((long double) float + (long double) float) 2022-10-24 Jakub Jelinek PR c++/107358 gcc/c/ * c-typeck.c (build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/testsuite/ * c-c++-common/pr107358.c: New test. (cherry picked from commit 65e3274e363cb2c6bfe6b5e648916eb7696f7e2f)
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 11.4+/12.3+ in C too.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:57da0797a73f32c879bca77e121a4f55fcc57ce1 commit r11-10363-g57da0797a73f32c879bca77e121a4f55fcc57ce1 Author: Jakub Jelinek Date: Mon Oct 24 17:53:16 2022 +0200 c, c++: Fix up excess precision handling of scalar_to_vector conversion [PR107358] As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess precision promotions (or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid diagnostics that say float vector + float involves truncation (on ia32 from long double to float). The following patch fixes that by calling scalar_to_vector on the operands before the excess precision promotions, let scalar_to_vector just do the diagnostics (it does e.g. fold_for_warn so it will fold EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then do the actual conversions using the excess precision promoted operands (so say if we have vector double + (float + float) we don't actually do vector double + (float) ((long double) float + (long double) float) but vector double + (double) ((long double) float + (long double) float) 2022-10-24 Jakub Jelinek PR c++/107358 gcc/c/ * c-typeck.c (build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/testsuite/ * c-c++-common/pr107358.c: New test. (cherry picked from commit 65e3274e363cb2c6bfe6b5e648916eb7696f7e2f)
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:31f25cf4ef9a0a0ccc0b0f9158773c5a71e74cc5 commit r12-8889-g31f25cf4ef9a0a0ccc0b0f9158773c5a71e74cc5 Author: Jakub Jelinek Date: Mon Oct 24 17:53:16 2022 +0200 c, c++: Fix up excess precision handling of scalar_to_vector conversion [PR107358] As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess precision promotions (or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid diagnostics that say float vector + float involves truncation (on ia32 from long double to float). The following patch fixes that by calling scalar_to_vector on the operands before the excess precision promotions, let scalar_to_vector just do the diagnostics (it does e.g. fold_for_warn so it will fold EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then do the actual conversions using the excess precision promoted operands (so say if we have vector double + (float + float) we don't actually do vector double + (float) ((long double) float + (long double) float) but vector double + (double) ((long double) float + (long double) float) 2022-10-24 Jakub Jelinek PR c++/107358 gcc/c/ * c-typeck.cc (build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/testsuite/ * c-c++-common/pr107358.c: New test. (cherry picked from commit 65e3274e363cb2c6bfe6b5e648916eb7696f7e2f)
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #5 from Jakub Jelinek --- Should be fixed now on the trunk. I'll backport the C part later.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:65e3274e363cb2c6bfe6b5e648916eb7696f7e2f commit r13-3461-g65e3274e363cb2c6bfe6b5e648916eb7696f7e2f Author: Jakub Jelinek Date: Mon Oct 24 17:53:16 2022 +0200 c, c++: Fix up excess precision handling of scalar_to_vector conversion [PR107358] As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess precision promotions (or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid diagnostics that say float vector + float involves truncation (on ia32 from long double to float). The following patch fixes that by calling scalar_to_vector on the operands before the excess precision promotions, let scalar_to_vector just do the diagnostics (it does e.g. fold_for_warn so it will fold EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then do the actual conversions using the excess precision promoted operands (so say if we have vector double + (float + float) we don't actually do vector double + (float) ((long double) float + (long double) float) but vector double + (double) ((long double) float + (long double) float) 2022-10-24 Jakub Jelinek PR c++/107358 gcc/c/ * c-typeck.cc (build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/cp/ * typeck.cc (cp_build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/testsuite/ * c-c++-common/pr107358.c: New test. * g++.dg/cpp1y/pr68180.C: Remove -fexcess-precision=fast from dg-options.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #3 from Sergei Trofimovich --- (In reply to Jakub Jelinek from comment #2) > Created attachment 53757 [details] > gcc13-pr107358.patch > > Untested fix. The proposed patch fixes libjxl-0.7.0 build for me.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-10-22 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 53757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53757=edit gcc13-pr107358.patch Untested fix.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358
Jakub Jelinek changed:
What|Removed |Added
CC|jakub at redhat dot com|
--- Comment #1 from Jakub Jelinek ---
I think that is the preexisting C issue I've talked about in
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603265.html
typedef float __attribute__((vector_size (16))) float32x4_t;
float32x4_t foo(float32x4_t x, float y) { return x + y; }
where C also fails for years with -fexcess-precision=standard.
