Re: Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag.

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Christophe Lyon <christophe.lyon@linaro.org> [2016-11-18 13:21:50 +0100]:

> On 16 November 2016 at 23:12, Andrew Burgess
> <andrew.burgess@embecosm.com> wrote:
> > * Mike Stump <mikestump@comcast.net> [2016-11-16 12:59:53 -0800]:
> >
> >> On Nov 16, 2016, at 12:09 PM, Andrew Burgess <andrew.burgess@embecosm.com> wrote:
> >> > My only remaining concern is the new tests, I've tried to restrict
> >> > them to targets that I suspect they'll pass on with:
> >> >
> >> >    /* { dg-final-use { scan-assembler "\.section\[\t \]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.cold\.0" { target *-*-linux* *-*-gnu* } } } */
> >> >
> >> > but I'm still nervous that I'm going to introduce test failures.  Is
> >> > there any advice / guidance I should follow before I commit, or are
> >> > folk pretty relaxed so long as I've made a reasonable effort?
> >>
> >> So, if you are worried about the way the line is constructed, I usually test it by misspelling the *-*-linux* *-*-gnu* part as *-*-linNOTux* *-*-gnNOTu* and see if the test then doesn't run on your machine.  If it doesn't then you can be pretty confident that only machines that match the target triplet can be impacted.  I usually do this type of testing by running the test case in isolation (not the full tests suite).  Anyway, do the best you can, and don't worry about t it too much, learn from the experience, even if it goes wrong in some way.  If it did go wrong, just be responsive (don't check it in just before a 6 week vacation) about fixing it, if you can.
> >>
> >
> > Thanks for the feedback.
> >
> > Change committed as revision 242519.  If anyone sees any issues just
> > let me know.
> >
> 
> Hi Andrew,
> 
> Sorry for the delay, there are so many commits these days, with so
> many regression
> reports to check manually before reporting here....
> 
> So, your new test fails on arm* targets:

After a little digging I think the problem might be that
-freorder-blocks-and-partition is not supported on arm.

This should be detected as the new tests include:

    /* { dg-require-effective-target freorder } */

however this test passed on arm as -freorder-blocks-and-partition does
not issue any warning unless -fprofile-use is also passed.

The patch below extends check_effective_target_freorder to check using
-fprofile-use.  With this change in place the tests are skipped on
arm.

All feedback welcome,

Thanks,
Andrew

---

arm/gcc: Tighten checks in check_effective_target_freorder

In check_effective_target_freorder we check to see if the target
 supports -freorder-blocks-and-partition.  However we disable
 -freorder-blocks-and-partition when -fprofile-use is not supplied so
 for some targets we'll not see any message about lack of support for
 -freorder-blocks-and-partition unless -fprofile-use is also passed.

This commit extends check_effective_target_freorder to first try
-freorder-blocks-and-partition on its own, then try -fprofile-use and
-freorder-blocks-and-partition.

gcc/testsuite/ChangeLog:

	* lib/target-supports.exp (check_effective_target_freorder): Check
	additional case.
---
 gcc/testsuite/ChangeLog               | 5 +++++
 gcc/testsuite/lib/target-supports.exp | 8 +++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 8a2abd2..0716792 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1014,9 +1014,15 @@ proc check_effective_target_fstack_protector {} {
 # for trivial code, 0 otherwise.
 
 proc check_effective_target_freorder {} {
-    return [check_no_compiler_messages freorder object {
+    if { [check_no_compiler_messages freorder object {
 	void foo (void) { }
     } "-freorder-blocks-and-partition"]
+    && [check_no_compiler_messages fprofile_use_freorder object {
+	void foo (void) { }
+    } "-fprofile-use -freorder-blocks-and-partition"] } {
+	return 1
+    }
+    return 0
 }
 
 # Return 1 if -fpic and -fPIC are supported, as in no warnings or errors
-- 
2.6.4