https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> --- Created attachment 51150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51150&action=edit patch This is what I bootstrapped & tested on x86_64-unknown-linux-gnu. It causes FAIL: g++.dg/warn/Wparentheses-22.C -std=gnu++14 correct warning (test for warnings, line 104) FAIL: g++.dg/warn/Wparentheses-22.C -std=gnu++14 correct warning (test for warnings, line 33) ... FAIL: g++.dg/warn/Wparentheses-23.C -std=gnu++14 (test for warnings, line 117) FAIL: g++.dg/warn/Wparentheses-23.C -std=gnu++14 (test for warnings, line 118) ... interfering with the intent to warn about code like if (a = b) // { dg-warning "assignment" "correct warning" } foo (0); where a and b are aggregates convertible to bool. We end up generating something that acts as a valid "fix" for the diagnostic: if ((a = b), a) similarly we'd beforehand not diagnose the case of an empty aggregate assignment not wrapped in parentheses. Adjusting the warning code to also look for the COMPOUND_EXPR case wouldn't be valid if we'd not somehow mark those "fake" COMPOUND_EXPRs in a special way. Not sure what to do here. Maybe simply ignore the lost diagnostic and XFAIL the testcase or adjust it to have a second member in the aggregate used.
