[Bug c++/105289] [11/12 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 Patrick Palka changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #4 from Patrick Palka --- (In reply to Michael Steinberg from comment #2) > Created attachment 52851 [details] > Working modified partial specialization > > After the related issue was pointed out, it too made me curious whether my > code is valid, that is whether the partial specialization is truly more > specialized than the primary template. > So I modified the specialization so that Arg is at least as constrained as > in the primary template - et voila, the ICE is gone and the code is accepted. > This makes me believe that the classification 'ice-on-valid-code' may not be > true after all? I suppose ice-on-invalid-code might be the more convenient classification since after the above patch we now just reject the original testcase instead of crashing. This way the question of validity is left entirely to PR86193.
[Bug c++/105289] [11/12 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:288e4c64f6b4806358aabc9b99b2fba72bf04bf6 commit r12-8256-g288e4c64f6b4806358aabc9b99b2fba72bf04bf6 Author: Patrick Palka Date: Mon Apr 25 21:46:56 2022 -0400 c++: partial ordering with dependent NTTP type [PR105289] Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing on (respectively) two testcases that we used to accept in C++17 mode since r8-1437-g3da557ec145823. Both testcases declare a partial specialization of a primary template that has an NTTP with dependent type, and the validity of these partial specializations is unclear and the subject of PR86193 / CWG 455. So for now, this minimal patch just aims to fix the crash in the second testcase. During deduction, when checking whether the type of an NTTP uses still-undeduced parameters, we were incorrectly substituting into the previously substituted type instead of into its original type. In passing this patch also downgrades the "not more specialized" diagnostic from a permerror to a pedwarn. PR c++/105289 PR c++/86193 gcc/cp/ChangeLog: * pt.cc (process_partial_specialization): Downgrade "partial specialization isn't more specialized" diagnostic from permerror to an on-by-default pedwarn. (unify) : When substituting into the NTTP type a second time, use the original type not the substituted type. gcc/testsuite/ChangeLog: * g++.dg/template/partial-specialization11.C: New test. * g++.dg/template/partial-specialization12.C: New test.
[Bug c++/105289] [11/12 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 --- Comment #2 from Michael Steinberg --- Created attachment 52851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52851=edit Working modified partial specialization After the related issue was pointed out, it too made me curious whether my code is valid, that is whether the partial specialization is truly more specialized than the primary template. So I modified the specialization so that Arg is at least as constrained as in the primary template - et voila, the ICE is gone and the code is accepted. This makes me believe that the classification 'ice-on-valid-code' may not be true after all?
[Bug c++/105289] [11/12 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/105289] [11/12 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 Patrick Palka changed: What|Removed |Added Known to fail||11.2.0, 12.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |11.4 Last reconfirmed||2022-04-18 Ever confirmed|0 |1 Summary|[11 Regression] ICE on |[11/12 Regression] ICE on |partial specialization |partial specialization Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code CC||ppalka at gcc dot gnu.org Known to work||10.3.0, 9.4.0 --- Comment #1 from Patrick Palka --- Confirmed, started with r11-6483-ge2e2f3f2c9400f.
