unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: <libc-alpha@sourceware.org>
Subject: Fix iconv build with GCC mainline
Date: Thu, 19 Aug 2021 16:56:19 +0000	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2108191655530.350860@digraph.polyomino.org.uk> (raw)

Current GCC mainline produces -Wstringop-overflow errors building some
iconv converters, as discussed at
<https://gcc.gnu.org/pipermail/gcc/2021-July/236943.html>.  Add an
__builtin_unreachable call as suggested so that GCC can see the case
that would involve a buffer overflow is unreachable; because the
unreachability depends on valid conversion state being passed into the
function from previous conversion steps, it's not something the
compiler can reasonably deduce on its own.

Tested with build-many-glibcs.py that, together with
<https://sourceware.org/pipermail/libc-alpha/2021-August/130244.html>,
it restores the glibc build for powerpc-linux-gnu.

diff --git a/iconv/loop.c b/iconv/loop.c
index 062cc1b868..560a5f6394 100644
--- a/iconv/loop.c
+++ b/iconv/loop.c
@@ -436,6 +436,12 @@ SINGLE(LOOPFCT) (struct __gconv_step *step,
     return __GCONV_FULL_OUTPUT;
 
   /*  Now add characters from the normal input buffer.  */
+  if (inlen >= MAX_NEEDED_INPUT)
+    /* Avoid a -Wstringop-overflow= warning when this loop is
+       unrolled.  The compiler cannot otherwise see that this is
+       unreachable because it depends on (state->__count & 7) not
+       being too large after a previous conversion step.  */
+    __builtin_unreachable ();
   do
     bytebuf[inlen++] = *inptr++;
   while (inlen < MAX_NEEDED_INPUT && inptr < inend);

-- 
Joseph S. Myers
joseph@codesourcery.com

             reply	other threads:[~2021-08-19 16:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19 16:56 Joseph Myers [this message]
2021-08-23 15:46 ` Ping Re: Fix iconv build with GCC mainline Joseph Myers
2021-08-23 16:09 ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.22.394.2108191655530.350860@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).