All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Arnd Bergmann <arnd@arndb.de>, Andi Kleen <ak@linux.intel.com>
Cc: Nicolas Pitre <nico@linaro.org>,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 5/7] [HACK] avoid gcc-8 ICE on LTO
Date: Fri, 02 Feb 2018 09:04:54 -0800	[thread overview]
Message-ID: <1517591094.7489.103.camel@perches.com> (raw)
In-Reply-To: <20180202162104.2300532-5-arnd@arndb.de>

On Fri, 2018-02-02 at 17:21 +0100, Arnd Bergmann wrote:
> I ran into a build error:
> 
> /git/arm-soc/net/sctp/sm_sideeffect.c: In function 'sctp_do_sm':
> /git/arm-soc/net/sctp/sm_sideeffect.c:1155:5: internal compiler error: Segmentation fault
>  int sctp_do_sm(struct net *net, enum sctp_event event_type,
>      ^
> 0xa42b7f crash_signal
> 
> The bug is fixed in mainline gcc now, but I carry this as I have
> not yet upgrade.
[]
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
[]
> @@ -1152,12 +1152,12 @@ static void sctp_cmd_send_asconf(struct sctp_association *asoc)
>   * If you want to understand all of lksctp, this is a
>   * good place to start.
>   */
> +typedef const char *(printfn_t)(union sctp_subtype);

This typedef is only used in this file twice.
Perhaps removing the typedef is clearer.

Given the debug_fn use is only in another
used-once macro, convert that debug_fn in
the macro too and avoid the unnecessary
variable initialization.

The debug_[pre|post]_[sfn|sfx] macros are
probably unnecessary indirections and could
be removed too but the code might read worse.

---
 net/sctp/sm_sideeffect.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index b71e7fb0a20a..5a6de0070b71 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1133,8 +1133,9 @@ static void sctp_cmd_send_asconf(struct sctp_association *asoc)
  * functionality there.
  */
 #define debug_pre_sfn() \
-	pr_debug("%s[pre-fn]: ep:%p, %s, %s, asoc:%p[%s], %s\n", __func__, \
-		 ep, sctp_evttype_tbl[event_type], (*debug_fn)(subtype),   \
+	pr_debug("%s[pre-fn]: ep:%p, %s, %s, asoc:%p[%s], %s\n",	\
+		 __func__, ep, sctp_evttype_tbl[event_type],		\
+		 (*table[event_type])(subtype),				\
 		 asoc, sctp_state_tbl[state], state_fn->name)
 
 #define debug_post_sfn() \
@@ -1157,11 +1158,9 @@ int sctp_do_sm(struct net *net, enum sctp_event event_type,
 	       struct sctp_endpoint *ep, struct sctp_association *asoc,
 	       void *event_arg, gfp_t gfp)
 {
-	typedef const char *(printfn_t)(union sctp_subtype);
-	static printfn_t *table[] = {
+	static const char *(*table[])(union sctp_subtype) = {
 		NULL, sctp_cname, sctp_tname, sctp_oname, sctp_pname,
 	};
-	printfn_t *debug_fn  __attribute__ ((unused)) = table[event_type];
 	const struct sctp_sm_table_entry *state_fn;
 	struct sctp_cmd_seq commands;
 	enum sctp_disposition status;

  reply	other threads:[~2018-02-02 17:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-02 16:15 [PATCH 0/7] LTO: hacks to build LTO-enabled randconfig kernels Arnd Bergmann
2018-02-02 16:15 ` Arnd Bergmann
2018-02-02 16:15 ` [PATCH 1/7] [HACK] lto: make config.gz symbol visible Arnd Bergmann
2018-02-02 16:15   ` Arnd Bergmann
2018-02-02 16:20 ` [PATCH 2/7] [HACK] x86: lto: always link in library files Arnd Bergmann
2018-02-02 16:21 ` [PATCH 3/7] [HACK] x86: crypto: fix link error with LTO Arnd Bergmann
2018-02-02 19:49   ` Nicolas Pitre
2018-02-02 22:18     ` Arnd Bergmann
2018-02-02 16:21 ` [PATCH 4/7] [HACK] lto: shut up some warnings Arnd Bergmann
2018-02-02 16:21 ` [PATCH 5/7] [HACK] avoid gcc-8 ICE on LTO Arnd Bergmann
2018-02-02 17:04   ` Joe Perches [this message]
2018-02-02 16:21 ` [PATCH 6/7] Kbuild: lto: clean build artifacts Arnd Bergmann
2018-02-02 16:21 ` [PATCH 7/7] Kbuild: lto: pass -m32/-m64 to to LDFINAL Arnd Bergmann
2018-02-02 18:41   ` Nicolas Pitre
2018-02-02 20:18     ` Arnd Bergmann
2018-02-02 20:38       ` Nicolas Pitre
2018-02-02 20:55         ` Arnd Bergmann
2018-02-02 21:17           ` Nicolas Pitre

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

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

  git send-email \
    --in-reply-to=1517591094.7489.103.camel@perches.com \
    --to=joe@perches.com \
    --cc=ak@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.