public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: gcc-patches@gnu.org
Cc: dejagnu@gnu.org
Subject: dg-options after board/cflags
Date: Wed, 02 Sep 2020 17:30:27 +0200	[thread overview]
Message-ID: <87h7sg42ng.fsf@oracle.com> (raw)


Hi people!

While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
board/cflags were included in the final compilation line _after_ the
flags in the test's dg-options.

Since the test options are more particular than the board options, I
would expect them to be placed after any board-defined flags, so I
prepared the patch below for dejagnu, which does the right thing for the
gcc.target/bpf testsuite.

However:

1. There could be tests around that depend (erroneously) on some of
   their dg-options to not have effect (or a different effect) because
   they are annulled (or modified) by some flag in a board file.

2. This could also impact other programs using dejagnu.

How do you people recommend to proceed?
Should we fix dejagnu and then fix buggy tests?
Or the other way around?  :-)

diff --git a/lib/target.exp b/lib/target.exp
index 36ae639..f0bfe20 100644
--- a/lib/target.exp
+++ b/lib/target.exp
@@ -455,7 +455,7 @@ proc default_target_compile {source destfile type options} {
 	}
 	if {[regexp "^additional_flags=" $i]} {
 	    regsub "^additional_flags=" $i "" tmp
-	    append add_flags " $tmp"
+	    append additional_flags " $tmp"
 	}
 	if {[regexp "^ldflags=" $i]} {
 	    regsub "^ldflags=" $i "" tmp
@@ -703,6 +703,8 @@ proc default_target_compile {source destfile type options} {
 	}
     }
 
+    append add_flags " $additional_flags"
+    
     verbose "doing compile"
 
     set sources ""
@@ -728,7 +730,7 @@ proc default_target_compile {source destfile type options} {
 	    append add_flags " -o $destfile"
 	}
     }
-
+    
     # This is obscure: we put SOURCES at the end when building an
     # object, because otherwise, in some situations, libtool will
     # become confused about the name of the actual source file.

             reply	other threads:[~2020-09-02 15:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 15:30 Jose E. Marchesi [this message]
2020-09-02 16:30 ` H.J. Lu
2020-09-02 16:47   ` Jose E. Marchesi
2020-09-26 12:33     ` Maciej W. Rozycki
2020-09-28 14:07       ` Jose E. Marchesi

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=87h7sg42ng.fsf@oracle.com \
    --to=jose.marchesi@oracle.com \
    --cc=dejagnu@gnu.org \
    --cc=gcc-patches@gnu.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).