middle-end: Avoid calling targetm.c.bitint_type_info inside of gcc_assert [PR102989]

middle-end: Avoid calling targetm.c.bitint_type_info inside of gcc_assert [PR102989]

On Thu, Sep 07, 2023 at 10:36:02AM +0200, Thomas Schwinge wrote:
> Minor comment/question: are we doing away with the property that
> 'assert'-like "calls" must not have side effects?  Per 'gcc/system.h',
> this is "OK" for 'gcc_assert' for '#if ENABLE_ASSERT_CHECKING' or
> '#elif (GCC_VERSION >= 4005)' -- that is, GCC 4.5, which is always-true,
> thus the "offending" '#else' is never active.  However, it's different
> for standard 'assert' and 'gcc_checking_assert', so I'm not sure if
> that's a good property for 'gcc_assert' only?  For example, see also
> <https://gcc.gnu.org/PR6906> "warn about asserts with side effects", or
> recent <https://gcc.gnu.org/PR111144>
> "RFE: could -fanalyzer warn about assertions that have side effects?".

You're right, the
  #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
fallback definition is incompatible with the way I've used it, so for
--disable-checking built by non-GCC it would not work properly.

2023-09-07  Jakub Jelinek  <jakub@redhat.com>

	PR c/102989
	* expr.cc (expand_expr_real_1): Don't call targetm.c.bitint_type_info
	inside gcc_assert, as later code relies on it filling info variable.
	* gimple-fold.cc (clear_padding_bitint_needs_padding_p,
	clear_padding_type): Likewise.
	* varasm.cc (output_constant): Likewise.
	* fold-const.cc (native_encode_int, native_interpret_int): Likewise.
	* stor-layout.cc (finish_bitfield_representative, layout_type):
	Likewise.
	* gimple-lower-bitint.cc (bitint_precision_kind): Likewise.