public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] genmultilib: Fix sanity check
@ 2022-11-21 11:59 Christophe Lyon
  2022-11-21 12:17 ` Jakub Jelinek
  0 siblings, 1 reply; 4+ messages in thread
From: Christophe Lyon @ 2022-11-21 11:59 UTC (permalink / raw)
  To: gcc-patches; +Cc: jakub, Christophe Lyon

My previous patch to add a sanity check to genmultilib actually
checked the number of dirnames with the number of "sets of options"
rather than the number of options, thus breaking the build on some
targets.

To avoid duplicating once more the loop that constructs the sed
patterns, this patch checks that the current dirname/osdirname is not
empty in the existing loops.

Are there targets where:
if [ "$1" != "${opt}" ]; then
is "legally" executed with an empty $1? (and thus where this patch
would incorrectly trigger an error?)

Sorry for the breakage. Tested on aarch64 by adding an option to
t-aarch64 and no corresponding dirname, and on x86_64.

OK for trunk?

gcc/ChangeLog:

	* genmultilib: Fix options and dirnames/osdirnames sanity
          check.
---
 gcc/genmultilib | 22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/gcc/genmultilib b/gcc/genmultilib
index b5f372c8358..c0c271eddd6 100644
--- a/gcc/genmultilib
+++ b/gcc/genmultilib
@@ -141,20 +141,6 @@ multiarch=$9
 multilib_reuse=${10}
 enable_multilib=${11}
 
-# Sanity check: make sure we have as many dirnames as options
-if [ -n "${dirnames}" ]; then
-    set x $options
-    nboptions=$#
-    set x $dirnames
-    nbdirnames=$#
-    if [ $nbdirnames -ne $nboptions ]; then
-	echo 1>&2 "Error calling $0: Number of dirnames ($nbdirnames) does not match number of options ($nboptions)"
-	echo 1>&2 "options: ${options}"
-	echo 1>&2 "dirnames: ${dirnames}"
-	exit 1
-    fi
-fi
-
 echo "static const char *const multilib_raw[] = {"
 
 mkdir tmpmultilib.$$ || exit 1
@@ -264,6 +250,10 @@ if [ -n "${dirnames}" ]; then
     for opts in `echo ${set} | sed -e 's|/| |'g`; do
       patt="/"
       for opt in `echo ${opts} | sed -e 's_|_ _'g`; do
+	if [ -z "$1" ]; then
+	  echo 1>&2 "Error calling $0: No dirname for option: $opt"
+	  exit 1
+	fi
         if [ "$1" != "${opt}" ]; then
           todirnames="${todirnames} -e s|/${opt}/|/${1}/|g"
 	  patt="${patt}${1}/"
@@ -320,6 +310,10 @@ if [ -n "${osdirnames}" ]; then
       for opts in `echo ${set} | sed -e 's|/| |'g`; do
         patt="/"
         for opt in `echo ${opts} | sed -e 's_|_ _'g`; do
+	if [ -z "$1" ]; then
+	  echo 1>&2 "Error calling $0: No osdirname for option: $opt"
+	  exit 1
+	fi
           if [ "$1" != "${opt}" ]; then
             toosdirnames="${toosdirnames} -e s|/${opt}/|/${1}/|g"
 	    patt="${patt}${1}/"
-- 
2.34.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] genmultilib: Fix sanity check
  2022-11-21 11:59 [PATCH] genmultilib: Fix sanity check Christophe Lyon
@ 2022-11-21 12:17 ` Jakub Jelinek
  2022-11-21 12:20   ` Christophe Lyon
  0 siblings, 1 reply; 4+ messages in thread
From: Jakub Jelinek @ 2022-11-21 12:17 UTC (permalink / raw)
  To: Christophe Lyon; +Cc: gcc-patches

On Mon, Nov 21, 2022 at 12:59:15PM +0100, Christophe Lyon wrote:
> My previous patch to add a sanity check to genmultilib actually
> checked the number of dirnames with the number of "sets of options"
> rather than the number of options, thus breaking the build on some
> targets.
> 
> To avoid duplicating once more the loop that constructs the sed
> patterns, this patch checks that the current dirname/osdirname is not
> empty in the existing loops.
> 
> Are there targets where:
> if [ "$1" != "${opt}" ]; then
> is "legally" executed with an empty $1? (and thus where this patch
> would incorrectly trigger an error?)

Dunno, let's try your patch.  And if that triggers on something
valid then the next step would be just to revert the sanity checks
completely.

> 	* genmultilib: Fix options and dirnames/osdirnames sanity
>           check.

This won't get through the pre-commit hook, the second line
should be indented just by tab and nothing further.

	Jakub


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] genmultilib: Fix sanity check
  2022-11-21 12:17 ` Jakub Jelinek
@ 2022-11-21 12:20   ` Christophe Lyon
  2022-11-21 14:27     ` Jeff Law
  0 siblings, 1 reply; 4+ messages in thread
From: Christophe Lyon @ 2022-11-21 12:20 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches



On 11/21/22 13:17, Jakub Jelinek wrote:
> On Mon, Nov 21, 2022 at 12:59:15PM +0100, Christophe Lyon wrote:
>> My previous patch to add a sanity check to genmultilib actually
>> checked the number of dirnames with the number of "sets of options"
>> rather than the number of options, thus breaking the build on some
>> targets.
>>
>> To avoid duplicating once more the loop that constructs the sed
>> patterns, this patch checks that the current dirname/osdirname is not
>> empty in the existing loops.
>>
>> Are there targets where:
>> if [ "$1" != "${opt}" ]; then
>> is "legally" executed with an empty $1? (and thus where this patch
>> would incorrectly trigger an error?)
> 
> Dunno, let's try your patch.  And if that triggers on something
> valid then the next step would be just to revert the sanity checks
> completely.

Agreed.


> 
>> 	* genmultilib: Fix options and dirnames/osdirnames sanity
>>            check.
> 
> This won't get through the pre-commit hook, the second line
> should be indented just by tab and nothing further.
> 
Thanks for catching this.

Pushed.

Christophe

> 	Jakub
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] genmultilib: Fix sanity check
  2022-11-21 12:20   ` Christophe Lyon
@ 2022-11-21 14:27     ` Jeff Law
  0 siblings, 0 replies; 4+ messages in thread
From: Jeff Law @ 2022-11-21 14:27 UTC (permalink / raw)
  To: Christophe Lyon, Jakub Jelinek; +Cc: gcc-patches


On 11/21/22 05:20, Christophe Lyon via Gcc-patches wrote:
>
>
> On 11/21/22 13:17, Jakub Jelinek wrote:
>> On Mon, Nov 21, 2022 at 12:59:15PM +0100, Christophe Lyon wrote:
>>> My previous patch to add a sanity check to genmultilib actually
>>> checked the number of dirnames with the number of "sets of options"
>>> rather than the number of options, thus breaking the build on some
>>> targets.
>>>
>>> To avoid duplicating once more the loop that constructs the sed
>>> patterns, this patch checks that the current dirname/osdirname is not
>>> empty in the existing loops.
>>>
>>> Are there targets where:
>>> if [ "$1" != "${opt}" ]; then
>>> is "legally" executed with an empty $1? (and thus where this patch
>>> would incorrectly trigger an error?)
>>
>> Dunno, let's try your patch.  And if that triggers on something
>> valid then the next step would be just to revert the sanity checks
>> completely.
>
> Agreed.

The first version (as we know) tripped on a few targets in my tester.  
I've got those restarted and we should know in a few hours if there's 
any major issues.


jeff



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-11-21 14:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-21 11:59 [PATCH] genmultilib: Fix sanity check Christophe Lyon
2022-11-21 12:17 ` Jakub Jelinek
2022-11-21 12:20   ` Christophe Lyon
2022-11-21 14:27     ` Jeff Law

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).