https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110677
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Martin Jambor <jamb...@gcc.gnu.org>: https://gcc.gnu.org/g:84e122c34834d9dea189c10fe0bf60c4d1a99fae commit r14-3224-g84e122c34834d9dea189c10fe0bf60c4d1a99fae Author: Martin Jambor <mjam...@suse.cz> Date: Tue Aug 15 17:13:44 2023 +0200 Fortran: Avoid accessing gfc_charlen when not looking at BT_CHARACTER (PR 110677) This patch addresses an issue uncovered by the undefined behavior sanitizer. In function resolve_structure_cons in resolve.cc there is a test starting with: if (cons->expr->ts.type == BT_CHARACTER && comp->ts.u.cl && comp->ts.u.cl->length && comp->ts.u.cl->length->expr_type == EXPR_CONSTANT and UBSAN complained of loads from comp->ts.u.cl->length->expr_type of integer value 1818451807 which is outside of the value range expr_t enum. If I understand the code correctly it the entire load was unwanted because comp->ts.type in those cases is BT_CLASS and not BT_CHARACTER. This patch simply adds a check to make sure it is only accessed in those cases. During review, Harald Anlauf noticed that length types also need to be checked and so I added also checks that he suggested to the condition. Co-authored-by: Harald Anlauf <anl...@gmx.de> gcc/fortran/ChangeLog: 2023-08-14 Martin Jambor <mjam...@suse.cz> PR fortran/110677 * resolve.cc (resolve_structure_cons): Check comp->ts is character type before accessing stuff through comp->ts.u.cl.
