Re: [PATCH] libstdc++ testsuite cxxflags

[Cesar Philippidis]

On 11/21/13, 5:42 AM, Jonathan Wakely wrote:
> On 20 November 2013 23:57, Cesar Philippidis wrote:
>> On 11/20/13, 1:46 PM, Jonathan Wakely wrote:
>>> On 20 November 2013 21:44, Jonathan Wakely wrote:
>>>> On 29 October 2013 15:37, Cesar Philippidis wrote:
>>>>> This patch addresses two issues with the libstdc++ testsuite:
>>>>>
>>>>>   * duplicate "-g -O2" CXXFLAGS
>>>>>   * missing "-g -O2" for remote targets
>>>>>
>>>>> The duplicate "-g -O2" flags is a result of testsuite_flags.in using
>>>>> build-time CXXFLAGS and proc libstdc++_init using the environmental
>>>>> CXXFLAGS, which defaults to its build-time value. This patch prevents
>>>>> testsuite_flags.in from using build-time CXXFLAGS.
>>>>
>>>>> Certain remote targets require a minimum optimization level -O1 in order
>>>>> to pass several atomics built-in function tests. This patch ensures
>>>>> cxxflags contains "-g -O2" at minimum when no other optimization flags
>>>>> are specified. The testsuite used to set those flags prior to Benjamin's
>>>>> patch to remove duplicate cxxflags here
>>>>> <http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01572.html>.
>>>>>
>>>>> Is this OK for trunk? If so, please apply (I don't have commit rights).
>>>>
>>>> I think so ... although I'm not sure I've got my head round the
>>>> effects in all cases!
>>>
>>> Sorry, I didn't realise gmail thought Ctrl-Enter meant send. I meant
>>> to ask a couple of questions about it ...
>>>
>>> Is removing EXTRA_CXX_FLAGS necessary too?
>>
>> I looked at it again, and it seems to be OK to leave it in there.
>>
>>> For remote targets, if CXXFLAGS is set in the env can -g still end up 
>>> missing?
>>
>> No, but CXXFLAGS isn't necessarily set in the env. Specifically, if you
>> run the testsuite without using the makefile, the CXXFLAGS may not be set.
>>
>> I revised the patch to preserve @EXTRA_CXX_FLAGS@. I also append the
>> '-g' flag with '-O2', since the '-g' isn't as important in the testsuite
>> as '-O2'.
>>
>> Is this patch OK? Is so, please commit it because I do not have an svn
>> account.
> 
> I've been playing around with this patch and CXXFLAGS further, and I'm
> not sure about it now.
> 
> What harm do the duplicate flags do? If you want different flags to be
> used when running the testsuite you can set CXXFLAGS, which will come
> later on the command-line and so take precedence. However, if we
> remove "-g -O2" from CXXFLAGS_config and you use CXXFLAGS=-DFOO when
> running the testsuite then after this change you won't get the same
> result, you'd have to change to use CXXFLAGS="-g -O2 -DFOO"
> 
> Is that really what we want?

I see your point. Well, if you want to override CXXFLAGS during testing,
it's probably better to use different environmental variable altogether
and include '-g -O2' as part of the base CXXFLAGS. The attached patch
does that with LIBSTDCXX_CXXFLAGS.

That said, I don't have a strong opinion on the matter, so if you want
to use the libstdcxx_testsuite-b.diff patch without the Makefile.in
changes, that's fine with me.

Cesar
2013-11-21  Cesar Philippidis  

libstdc++-v3/
* scripts/testsuite_flags.in (cxxflags): Remove @CXXFLAGS@ since 
libstdc++.exp imports those flags via getenv.
* testsuite/lib/libstdc++.exp (libstdc++_init): Ensure that 
cxxflags contains '-g -O2' flag. Also, use env LIBSTDCXX_CXXFLAGS 
to augment cxxflags instead of env CXXFLAGS.


diff --git a/libstdc++-v3/scripts/testsuite_flags.in 
b/libstdc++-v3/scripts/testsuite_flags.in
index cf692f8..5e7ad32 100755
--- a/libstdc++-v3/scripts/testsuite_flags.in
+++ b/libstdc++-v3/scripts/testsuite_flags.in
@@ -57,7 +57,7 @@ case ${query} in
   ;;
 --cxxflags)
   CXXFLAGS_default="-D_GLIBCXX_ASSERT -fmessage-length=0"
-  CXXFLAGS_config="@SECTION_FLAGS@ @CXXFLAGS@ @EXTRA_CXX_FLAGS@"
+  CXXFLAGS_config="@SECTION_FLAGS@ @EXTRA_CXX_FLAGS@"
   echo ${CXXFLAGS_default} ${CXXFLAGS_config} 
   ;;
 --cxxvtvflags)
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 0dff98c..2848ca7 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -278,8 +278,8 @@ proc libstdc++_init { testfile } {
set cc [exec sh $flags_file --build-cc]
set includes [exec sh $flags_file --build-includes]
 }
-append cxxflags " "
-append cxxflags [getenv CXXFLAGS]
+append cxxflags " -g -O2 "
+append cxxflags [getenv LIBSTDCXX_CXXFLAGS]
 v3track cxxflags 2
 
 # Always use MO files built by this test harness.

Re: [PATCH] libstdc++ testsuite cxxflags

[Cesar Philippidis]

On 11/20/13, 1:46 PM, Jonathan Wakely wrote:
> On 20 November 2013 21:44, Jonathan Wakely wrote:
>> On 29 October 2013 15:37, Cesar Philippidis wrote:
>>> This patch addresses two issues with the libstdc++ testsuite:
>>>
>>>   * duplicate "-g -O2" CXXFLAGS
>>>   * missing "-g -O2" for remote targets
>>>
>>> The duplicate "-g -O2" flags is a result of testsuite_flags.in using
>>> build-time CXXFLAGS and proc libstdc++_init using the environmental
>>> CXXFLAGS, which defaults to its build-time value. This patch prevents
>>> testsuite_flags.in from using build-time CXXFLAGS.
>>
>>> Certain remote targets require a minimum optimization level -O1 in order
>>> to pass several atomics built-in function tests. This patch ensures
>>> cxxflags contains "-g -O2" at minimum when no other optimization flags
>>> are specified. The testsuite used to set those flags prior to Benjamin's
>>> patch to remove duplicate cxxflags here
>>> <http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01572.html>.
>>>
>>> Is this OK for trunk? If so, please apply (I don't have commit rights).
>>
>> I think so ... although I'm not sure I've got my head round the
>> effects in all cases!
> 
> Sorry, I didn't realise gmail thought Ctrl-Enter meant send. I meant
> to ask a couple of questions about it ...
> 
> Is removing EXTRA_CXX_FLAGS necessary too?

I looked at it again, and it seems to be OK to leave it in there.

> For remote targets, if CXXFLAGS is set in the env can -g still end up missing?

No, but CXXFLAGS isn't necessarily set in the env. Specifically, if you
run the testsuite without using the makefile, the CXXFLAGS may not be set.

I revised the patch to preserve @EXTRA_CXX_FLAGS@. I also append the
'-g' flag with '-O2', since the '-g' isn't as important in the testsuite
as '-O2'.

Is this patch OK? Is so, please commit it because I do not have an svn
account.

Thanks,
Cesar
2013-11-20  Cesar Philippidis  

libstdc++-v3/
* scripts/testsuite_flags.in (cxxflags): Remove @CXXFLAGS@ since 
libstdc++.exp imports those flags via getenv.
* testsuite/lib/libstdc++.exp (libstdc++_init): Ensure that 
CXXFLAGS contains a '-O' flag. 


diff --git a/libstdc++-v3/scripts/testsuite_flags.in 
b/libstdc++-v3/scripts/testsuite_flags.in
index cf692f8..5e7ad32 100755
--- a/libstdc++-v3/scripts/testsuite_flags.in
+++ b/libstdc++-v3/scripts/testsuite_flags.in
@@ -57,7 +57,7 @@ case ${query} in
   ;;
 --cxxflags)
   CXXFLAGS_default="-D_GLIBCXX_ASSERT -fmessage-length=0"
-  CXXFLAGS_config="@SECTION_FLAGS@ @CXXFLAGS@ @EXTRA_CXX_FLAGS@"
+  CXXFLAGS_config="@SECTION_FLAGS@ @EXTRA_CXX_FLAGS@"
   echo ${CXXFLAGS_default} ${CXXFLAGS_config} 
   ;;
 --cxxvtvflags)
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 0dff98c..58f2d51 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -280,6 +280,11 @@ proc libstdc++_init { testfile } {
 }
 append cxxflags " "
 append cxxflags [getenv CXXFLAGS]
+
+if ![regexp "\-O" $cxxflags] {
+   append cxxflags " -g -O2"
+}
+
 v3track cxxflags 2
 
 # Always use MO files built by this test harness.

PING: [PATCH] libstdc++ testsuite cxxflags

[Cesar Philippidis]

This patch needs a review.



Thanks,
Cesar

Re: [PATCH] aarch64 gcc.c-torture/execute/20101011-1.c failures

[Cesar Philippidis]

On 11/19/13, 1:37 AM, Marcus Shawcroft wrote:
> On 18 November 2013 18:02, Cesar Philippidis  wrote:
> 
>>>> gcc.c-torture/execute/20101011-1.c test on aarch64. The reason why this
>>>> test fails is because aarch64 does not trap on integer division by zero.
>>>>
>>>> Is this OK for trunk? If so, please commit it because I do not have an
>>>> svn account.
> 
> This is OK.
> 
> The comment Jeff highlighted is incorrect. AArch64 does not trap on
> integer division.
> 
> To get integer trap on divide by zero behavior we would have to go the
> mips route and add -mdivide-traps to explicitly check and generate a
> brk #XXX instruction.

Can someone please commit it for me?

Thanks,
Cesar

Re: [PATCH] aarch64 gcc.c-torture/execute/20101011-1.c failures

[Cesar Philippidis]

On 11/18/13, 10:01 AM, Andrew Pinski wrote:
> On Mon, Nov 18, 2013 at 9:58 AM, Cesar Philippidis
>  wrote:
>> This patch addresses the failures caused by the
>> gcc.c-torture/execute/20101011-1.c test on aarch64. The reason why this
>> test fails is because aarch64 does not trap on integer division by zero.
>>
>> Is this OK for trunk? If so, please commit it because I do not have an
>> svn account.
> 
> ENOPATCH

Sorry about that. I attached the patch this time.

Thanks,
Cesar

2013-11-18  Cesar Philippidis  

gcc/testsuite/
* gcc.c-torture/execute/20101011-c (DO_TEST): Define as 0 
for aarch64 since it does not trap on integer division.

Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c
===
--- gcc/testsuite/gcc.c-torture/execute/20101011-1.c(revision 204752)
+++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c(working copy)
@@ -12,10 +12,9 @@
 #elif defined (__sh__)
   /* On SH division by zero does not trap.  */
 # define DO_TEST 0
-#elif defined (__aarch64__) && !defined(__linux__)
-  /* AArch64 divisions do trap by default, but libgloss targets do not
- intercept the trap and raise a SIGFPE. So restrict the test to
- AArch64 systems that use the Linux kernel.  */
+#elif defined (__aarch64__)
+  /* On AArch64 integer division by zero does not trap.  */
+# define DO_TEST 0
 #elif defined (__TMS320C6X__)
   /* On TI C6X division by zero does not trap.  */
 # define DO_TEST 0

[PATCH] aarch64 gcc.c-torture/execute/20101011-1.c failures

[Cesar Philippidis]

This patch addresses the failures caused by the
gcc.c-torture/execute/20101011-1.c test on aarch64. The reason why this
test fails is because aarch64 does not trap on integer division by zero.

Is this OK for trunk? If so, please commit it because I do not have an
svn account.

Thanks,
Cesar

Re: [PATCH] Add check for aarch64 in vect_cmdline_needed

[Cesar Philippidis]

On 11/6/13, 5:06 PM, Joseph S. Myers wrote:

> You should be testing aarch64*-*-* so as to match aarch64_be targets.

Thank you for catching that. Please commit this new patch if is OK. I
don't have SVN access.

Thanks,
Cesar

2013-11-06  Cesar Philippidis  

gcc/testsuite/
* lib/target-supports.exp 
(check_effective_target_vect_cmdline_neeed): Add aarch64 to the list 
of targets that do not need command line argument to enable SIMD.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 423006)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -1920,7 +1920,8 @@ proc check_effective_target_vect_cmdline_needed {
 || [check_effective_target_powerpc_altivec]))
 || ([istarget sparc*-*-*] && [check_effective_target_sparc_vis])
  || [istarget spu-*-*]
-|| ([istarget arm*-*-*] && [check_effective_target_arm_neon]) } {
+|| ([istarget arm*-*-*] && [check_effective_target_arm_neon]) 
+|| [istarget aarch64*-*-*] } {
   set et_vect_cmdline_needed_saved 0
}
 }

[PATCH] Add check for aarch64 in vect_cmdline_needed

[Cesar Philippidis]

The following tests were failing on Aarch64 because the vectorizer was
successfully able to vectorize their loop nests:

FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect
"vectorized 0 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
"vectorized 0 loops" 1

Apparently the intent of these particular tests is to ensure that those
loops do not get vectorized when the target does not support SIMD.

Is this OK for trunk? If so, please commit it since I do not have a SVN
account.

Thanks,
Cesar
2013-11-05  Cesar Philippidis  

gcc/testsuite/
* lib/target-supports.exp 
(check_effective_target_vect_cmdline_neeed): Add aarch64 to the list 
of targets that do not need command line argument to enable SIMD.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 423006)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -1920,7 +1920,8 @@ proc check_effective_target_vect_cmdline_needed {
 || [check_effective_target_powerpc_altivec]))
 || ([istarget sparc*-*-*] && [check_effective_target_sparc_vis])
  || [istarget spu-*-*]
-|| ([istarget arm*-*-*] && [check_effective_target_arm_neon]) } {
+|| ([istarget arm*-*-*] && [check_effective_target_arm_neon]) 
+|| [istarget aarch64-*-*] } {
   set et_vect_cmdline_needed_saved 0
}
 }

[PATCH] libstdc++ testsuite cxxflags

[Cesar Philippidis]

This patch addresses two issues with the libstdc++ testsuite:

  * duplicate "-g -O2" CXXFLAGS
  * missing "-g -O2" for remote targets

The duplicate "-g -O2" flags is a result of testsuite_flags.in using
build-time CXXFLAGS and proc libstdc++_init using the environmental
CXXFLAGS, which defaults to its build-time value. This patch prevents
testsuite_flags.in from using build-time CXXFLAGS.

Certain remote targets require a minimum optimization level -O1 in order
to pass several atomics built-in function tests. This patch ensures
cxxflags contains "-g -O2" at minimum when no other optimization flags
are specified. The testsuite used to set those flags prior to Benjamin's
patch to remove duplicate cxxflags here
<http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01572.html>.

Is this OK for trunk? If so, please apply.

Thanks,
Cesar
2013-10-28  Cesar Philippidis  

libstdc++-v3/
* scripts/testsuite_flags.in (cxxflags): Don't use build-time
CXXFLAGS and EXTRA_CXX_FLAGS.
* testsuite/lib/libstdc++.exp (libstdc++_init): Ensure, at minimum,
cxxflags contains "-g -O2".

diff --git a/libstdc++-v3/scripts/testsuite_flags.in 
b/libstdc++-v3/scripts/testsuite_flags.in
index d7710ca..35b36e7 100755
--- a/libstdc++-v3/scripts/testsuite_flags.in
+++ b/libstdc++-v3/scripts/testsuite_flags.in
@@ -55,7 +55,7 @@ case ${query} in
   ;;
 --cxxflags)
   CXXFLAGS_default="-D_GLIBCXX_ASSERT -fmessage-length=0"
-  CXXFLAGS_config="@SECTION_FLAGS@ @CXXFLAGS@ @EXTRA_CXX_FLAGS@"
+  CXXFLAGS_config="@SECTION_FLAGS@"
   echo ${CXXFLAGS_default} ${CXXFLAGS_config}
   ;;
 --cxxparallelflags)
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 51ff6dd..68dcb15 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -265,6 +265,15 @@ proc libstdc++_init { testfile } {
 }
 append cxxflags " "
 append cxxflags [getenv CXXFLAGS]
+
+if {$cxxflags == "-D_GLIBCXX_ASSERT -fmessage-length=0 "} {
+   append cxxflags "-g"
+}
+
+if ![regexp "\-O" $cxxflags] {
+   append cxxflags " -O2"
+}
+
 v3track cxxflags 2
 
 # Always use MO files built by this test harness.

Re: [PATCH] libgomp testsuite fixes

[Cesar Philippidis]

On 6/20/13 9:49 AM, Mike Stump wrote:
> On May 30, 2013, at 12:59 PM, Cesar Philippidis  
> wrote:
>> Here is a patch from our backlog at Mentor Graphics that addresses a 
>> libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following 
>> error with dejagnu
> 
>> Is it OK for trunk?
> 
> Ok.
> 
> Committed revision 200253.

Please backport this patch along with the libitm fix to 4.8. Thank you.
(The libitm patch was discussed here
<http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01229.html>.)

Cesar

Index: libgomp/testsuite/libgomp.fortran/fortran.exp
===
--- libgomp/testsuite/libgomp.fortran/fortran.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.fortran/fortran.exp   (working copy)
@@ -1,4 +1,6 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
+load_gcc_lib gfortran-dg.exp
 
 global shlib_ext
 global ALWAYS_CFLAGS
Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp   (revision 199267)
+++ libgomp/testsuite/lib/libgomp.exp   (working copy)
@@ -9,24 +9,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
-load_gcc_lib gfortran-dg.exp
 
 set dg-do-what-default run
 
Index: libgomp/testsuite/libgomp.c/c.exp
===
--- libgomp/testsuite/libgomp.c/c.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c/c.exp   (working copy)
@@ -7,6 +7,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 # If a testcase doesn't have special options, use these.
 if ![info exists DEFAULT_CFLAGS] then {
Index: libgomp/testsuite/libgomp.graphite/graphite.exp
===
--- libgomp/testsuite/libgomp.graphite/graphite.exp (revision 199267)
+++ libgomp/testsuite/libgomp.graphite/graphite.exp (working copy)
@@ -23,6 +23,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 if ![check_effective_target_pthread] {
   return
Index: libgomp/testsuite/libgomp.c++/c++.exp
===
--- libgomp/testsuite/libgomp.c++/c++.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c++/c++.exp   (working copy)
@@ -1,4 +1,5 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 global shlib_ext
 
@@ -53,7 +54,7 @@
 }
 
 # Main loop.
-gfortran-dg-runtest $tests $libstdcxx_includes
+dg-runtest $tests "" $libstdcxx_includes
 }
 
 # All done.
Index: libitm/testsuite/lib/libitm.exp
===
--- libitm/testsuite/lib/libitm.exp (revision 199267)
+++ libitm/testsuite/lib/libitm.exp (working copy)
@@ -23,23 +23,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
 
 set dg-do-what-default run
 
Index: libitm/testsuite/libitm.c++/c++.exp
===
--- libitm/testsuite/libitm.c++/c++.exp (revision 199267)
+++ libitm/testsuite/libitm.c++/c++.exp (working copy)
@@ -15,6 +15,7 @@
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
 
 load_lib libitm-dg.exp
+load_gcc_lib gcc-d

Re: [patch] combine ICE fix

[Cesar Philippidis]

On 10/15/13 12:16 PM, Jeff Law wrote:
> On 10/10/13 10:25, Jakub Jelinek wrote:
>> On Thu, Oct 10, 2013 at 07:26:43AM -0700, Cesar Philippidis wrote:
>>> This patch addresses an ICE when building qemu for a Mips target in
>>> Yocto. Both gcc-trunk, gcc-4.8 and all of the targets are potentially
>>> affected. The problem occurs because the instruction combine phase uses
>>> two data structures to keep track of registers, reg_stat and
>>> regstat_n_sets_and_refs, but they potentially end up out of sync; when
>>> combine inserts a new register into reg_stat it does not update
>>> regstat_n_sets_and_refs. Failing to update the latter results in an
>>> occasional segmentation fault.
>>>
>>> Is this OK for trunk and gcc-4.8? If so, please check it in. I tested it
>>> on Mips and x86-64 and no regressions showed up.
>>
>> That looks broken.  You leave everything from the last size till the
>> current
>> one uninitialized, so it would only work if combine_split_insns
>> always increments max_reg_num () by at most one.
> I don't think that assumption is safe.  Consider a parallel with a bunch
> of (clobber (match_scratch)) expressions.

I address that in the patch posted here
<http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00802.html>. Is that still
insufficient?

>> Furthermore, there are macros which should be used to access
>> the fields, and, if the vector is ever going to be resized, supposedly
>> it should be vec.h vector rather than just array.
>> Or perhaps take into account:
>> /* If a pass need to change these values in some magical way or the
>> pass needs to have accurate values for these and is not using
>> incremental df scanning, then it should use REG_N_SETS and
>> REG_N_USES.  If the pass is doing incremental scanning then it
>> should be getting the info from DF_REG_DEF_COUNT and
>> DF_REG_USE_COUNT.  */
>> and not use REG_N_SETS etc. but instead the df stuff.
> Which begs the question, how exactly is combine utilizing the
> regstat_n_* structures and is that use even valid for combine?

I'll take a look at that.

Cesar

Re: [patch] combine ICE fix

[Cesar Philippidis]

On 10/10/13 9:25 AM, Jakub Jelinek wrote:

> That looks broken.  You leave everything from the last size till the current
> one uninitialized, so it would only work if combine_split_insns
> always increments max_reg_num () by at most one.

Good catch.

> Furthermore, there are macros which should be used to access
> the fields, and, if the vector is ever going to be resized, supposedly
> it should be vec.h vector rather than just array.
> Or perhaps take into account:
> /* If a pass need to change these values in some magical way or the
>pass needs to have accurate values for these and is not using
>incremental df scanning, then it should use REG_N_SETS and
>REG_N_USES.  If the pass is doing incremental scanning then it
>should be getting the info from DF_REG_DEF_COUNT and
>DF_REG_USE_COUNT.  */
> and not use REG_N_SETS etc. but instead the df stuff.

I was thinking about converting that array to a vec. But I don't want to
touch more code than I have to right now. Is this OK as a stopgap?

Thanks for the review!

Cesar
2013-10-11  Cesar Philippidis  

gcc/
* regs.h (REG_N_GROW): New function. 
* combine.c (combine_split_insns): Call REG_N_GROW when
new registers are created.

Index: gcc/regs.h
===
--- gcc/regs.h  (revision 203289)
+++ gcc/regs.h  (working copy)
@@ -89,6 +89,20 @@ REG_N_SETS (int regno)
 #define SET_REG_N_SETS(N,V) (regstat_n_sets_and_refs[N].sets = V)
 #define INC_REG_N_SETS(N,V) (regstat_n_sets_and_refs[N].sets += V)
 
+/* Indexed by n, inserts new registers (old_regno+1)..new_regno.  */
+static inline void
+REG_N_GROW (int new_regno, int old_regno)
+{
+  regstat_n_sets_and_refs = XRESIZEVEC (struct regstat_n_sets_and_refs_t, 
+   regstat_n_sets_and_refs, new_regno+1);
+
+  for (int i = old_regno + 1; i <= new_regno; ++i)
+{
+  SET_REG_N_SETS (i, 1);
+  SET_REG_N_REFS (i, 1);
+}
+}
+
 /* Given a REG, return TRUE if the reg is a PARM_DECL, FALSE otherwise.  */
 extern bool reg_is_parm_p (rtx);
 
Index: gcc/combine.c
===
--- gcc/combine.c   (revision 203289)
+++ gcc/combine.c   (working copy)
@@ -518,7 +518,10 @@ combine_split_insns (rtx pattern, rtx insn)
   ret = split_insns (pattern, insn);
   nregs = max_reg_num ();
   if (nregs > reg_stat.length ())
-reg_stat.safe_grow_cleared (nregs);
+{
+  REG_N_GROW (nregs, reg_stat.length ());
+  reg_stat.safe_grow_cleared (nregs);
+}
   return ret;
 }
 

[patch] combine ICE fix

[Cesar Philippidis]

This patch addresses an ICE when building qemu for a Mips target in
Yocto. Both gcc-trunk, gcc-4.8 and all of the targets are potentially
affected. The problem occurs because the instruction combine phase uses
two data structures to keep track of registers, reg_stat and
regstat_n_sets_and_refs, but they potentially end up out of sync; when
combine inserts a new register into reg_stat it does not update
regstat_n_sets_and_refs. Failing to update the latter results in an
occasional segmentation fault.

Is this OK for trunk and gcc-4.8? If so, please check it in. I tested it
on Mips and x86-64 and no regressions showed up.

Thanks,
Cesar
2013-10-10  Cesar Philippidis  

gcc/
* regs.h (REG_N_GROW): New function. 
* combine.c (combine_split_insns): Call REG_N_GROW when
new registers are created.

Index: gcc/regs.h
===
--- gcc/regs.h  (revision 421441)
+++ gcc/regs.h  (working copy)
@@ -85,6 +85,17 @@ REG_N_SETS (int regno)
   return regstat_n_sets_and_refs[regno].sets;
 }
 
+/* Indexed by n, inserts a new register (REG n).  */
+static inline void
+REG_N_GROW (int regno)
+{
+  regstat_n_sets_and_refs = XRESIZEVEC (struct regstat_n_sets_and_refs_t, 
+   regstat_n_sets_and_refs, regno+1);
+
+  regstat_n_sets_and_refs[regno].sets = 1;
+  regstat_n_sets_and_refs[regno].refs = 1;
+}
+
 /* Indexed by n, gives number of times (REG n) is set.  */
 #define SET_REG_N_SETS(N,V) (regstat_n_sets_and_refs[N].sets = V)
 #define INC_REG_N_SETS(N,V) (regstat_n_sets_and_refs[N].sets += V)
Index: gcc/combine.c
===
--- gcc/combine.c   (revision 421441)
+++ gcc/combine.c   (working copy)
@@ -518,7 +518,10 @@ combine_split_insns (rtx pattern, rtx insn)
   ret = split_insns (pattern, insn);
   nregs = max_reg_num ();
   if (nregs > reg_stat.length ())
-reg_stat.safe_grow_cleared (nregs);
+{
+  reg_stat.safe_grow_cleared (nregs);
+  REG_N_GROW (nregs);
+}
   return ret;
 }
 

[PATCH] if-to-switch pass

[Cesar Philippidis]

Here is an updated version of Tom's if-to-switch conversion pass that 
was originally posted here:

<http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01210.html>. 

I corrected a build problem with ARM by including "tm_p.h" and an ICE 
caused by NULL_TREE argument being passed to fold_binary () inside 
refine_range_plus (). Also, TODO_ggc_collect has been removed in the 
gimple_opt_pass struct.

I bootstrapped and regression tested on x86_64-unknown-linux-gnu and 
arm-none-linux-gnueabi. OK for trunk?

Cesar


2013-06-21  Tom de Vries  
Cesar Philippidis  

* tree-if-switch-conversion.c: New pass.
* tree-pass.h (pass_if_to_switch): Declare.
* common.opt (ftree-if-to-switch-conversion): New switch.
* opts.c (default_options_table): Set flag_tree_if_to_switch_conversion
at -O2 and higher.
* passes.c (init_optimization_passes): Use new pass.
* doc/invoke.texi (-ftree-if-to-switch-conversion): New item.
(Optimization Options, option -O2): Add -ftree-if-to-switch-conversion.
* Makefile.in (OBJS): Add tree-if-switch-conversion.o.
(tree-if-switch-conversion.o): New rule.
* tree.h (expand_switch_using_bit_tests_p): Declare as extern.
* tree-switch-conversion.c (expand_switch_using_bit_tests_p): Remove
static from definition.

* gcc.dg/if-to-switch.c: New test.
* gcc.dg/if-to-switch.c-2: Same.
* gcc.dg/if-to-switch.c-3: Same.
* gcc.dg/tree-ssa/vrp33.c: Run with -fno-tree-if-to-switch-conversion.
* gcc.dg/tree-ssa/vrp63.c: Same.
* gcc.dg/tree-ssa/vrp64.c: Same.
* gcc.dg/pr21643.c: Same.
Index: gcc/tree.h
===
--- gcc/tree.h  (revision 200261)
+++ gcc/tree.h  (working copy)
@@ -5656,6 +5656,10 @@
 extern void expand_stack_restore (tree);
 extern void expand_return (tree);
 
+/* In tree-switch-conversion.c  */
+
+extern bool expand_switch_using_bit_tests_p (tree, unsigned int, unsigned int);
+
 /* In tree-eh.c */
 extern void using_eh_for_cleanups (void);
 
Index: gcc/tree-if-switch-conversion.c
===
--- gcc/tree-if-switch-conversion.c (revision 0)
+++ gcc/tree-if-switch-conversion.c (revision 0)
@@ -0,0 +1,1367 @@
+/* Convert a chain of if statements into a switch statement.
+   Copyright (C) 2010, 2011, 2012 Free Software Foundation, Inc.
+   Contributed by Tom de Vries 
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the
+Free Software Foundation; either version 3, or (at your option) any
+later version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+<http://www.gnu.org/licenses/>.  */
+
+/* The following pass converts a chain of ifs into a switch.
+
+   The if-chain has the following properties:
+   - all bbs end in a GIMPLE_COND.
+   - all but the first bb are empty, apart from the GIMPLE_COND.
+   - the GIMPLE_CONDs compare the same variable against integer constants.
+   - the true gotos all target the same bb.
+   - the false gotos target the next in the if-chain.
+
+   F.i., consider the following if-chain:
+   ...
+   :
+   ...
+   if (D.1993_3 == 32)
+ goto ;
+   else
+ goto ;
+
+   :
+   if (D.1993_3 == 13)
+ goto ;
+   else
+ goto ;
+
+   :
+   if (D.1993_3 == 10)
+ goto ;
+   else
+ goto ;
+
+   :
+   if (D.1993_3 == 9)
+ goto ;
+   else
+ goto ;
+   ...
+
+   The pass will report this if-chain like this:
+   ...
+   var: D.1993_3
+   first: 
+   true: 
+   last: 
+   constants: 9 10 13 32
+   ...
+
+   and then convert the if-chain into a switch:
+   ...
+   :
+   ...
+   switch (D.1993_3) ,
+ case 9: ,
+ case 10: ,
+ case 13: ,
+ case 32: >
+   ...
+
+   The pass will try to construct a chain for each bb, unless the bb it is
+   already contained in a chain.  This ensures that all chains will be found,
+   and that no chain will be constructed twice.
+
+   The pass detect range-checks in analyze_bb as well, and handles them.
+   Simple ones, like 'c <= 5', and more complex ones, like
+   '(unsigned char) c + 247 <= 1', which is generated by the C front-end from
+   code like '(c == 9 || c == 10)' or '(9 <= c && c <= 10)'.
+
+   The if-chain is conceptually similar to a 'reorderable sequence of range
+   conditions' as described in "Efficient and effective branch reordering us

Re: [PATCH] ARMv6-M MI thunk fix

[Cesar Philippidis]

Ping.

Cesar


On 6/7/13 9:50 AM, Cesar Philippidis wrote:
> On 6/6/13 9:00 AM, Richard Earnshaw wrote:
>> The pipeline offset is 4 for Thumb2 as well.  So at the very least you
>> need to explain why your change doesn't apply then as well.
> 
> Yes some context is lost in that comment.  Thunks are usually emitted in
> ARM mode, except for Thumb-only targets.  Is the new comment OK?  If so,
> please check it in since I do not have SVN write access.
> 
> Thanks,
> Cesar
> 
> 
> 2013-06-07  Julian Brown  
>   Cesar Philippidis  
> 
>   gcc/
>   * config/arm/arm.c (arm_output_mi_thunk): Fix offset for
>   TARGET_THUMB1_ONLY.
> 

Re: [PATCH] libitm testsuite fixes

[Cesar Philippidis]

Ping.

Cesar


On 5/30/13 1:02 PM, Cesar Philippidis wrote:
> Here is a patch from our backlog that addresses a libitm issue where 
> setting ENABLE_LTO=1 in site.exp causes the following error with dejagnu:
> 
> ERROR: (DejaGnu) proc "libitm_target_compile linker_plugin19344.c 
> linker_plugin19344.exe executable {{additional_flags=-flto 
> -fuse-linker-plugin}}" does not exist.
> 
> This problem usually does not occur since the default site.exp does not
> contain ENABLE_LTO=1. This patch has been tested both with and without
> our custom site.exp.
> 
> Is this OK for trunk? If so, please check it in since I do not have commit
> rights.
> 
> Cesar Philippidis
> 
> 
> 2013-05-30  Iain Sandoe  
>   Cesar Philippidis  
> 
>   libitm/
>   * testsuite/lib/libitm.exp: Reorder lib loads into dependency order.
>   Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
>   * testsuite/libitm.c/c.exp: load_gcc_lib gcc-dg.exp.
>   * testsuite/libitm.c++/c++.exp: load_gcc_lib gcc-dg.exp.
> 

Re: [PATCH] libgomp testsuite fixes

[Cesar Philippidis]

Ping.

Cesar


On 5/30/13 12:59 PM, Cesar Philippidis wrote:
> Here is a patch from our backlog at Mentor Graphics that addresses a 
> libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following 
> error with dejagnu:
> 
> ERROR: (DejaGnu) proc "libgomp_target_compile linker_plugin9263.c 
> linker_plugin9263.exe executable {{additional_flags=-flto 
> -fuse-linker-plugin}}" does not exist.
> 
> This problem usually does not occur since the default site.exp does not
> contain ENABLE_LTO=1. I tested both with and without our custom site.exp.
> 
> Is it OK for trunk? If so, please check it in since I do not have commit
> rights.
> 
> Cesar Philippidis
> 
> 
> 2013-05-30  Iain Sandoe  
>   Cesar Philippidis  
> 
>   libgomp/
>   * testsuite/lib/libgomp.exp: Reorder lib loads into dependency order.
>   Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
>   * testsuite/libgomp.c/c.exp: load_gcc_lib gcc-dg.exp.
>   * testsuite/libgomp.fortran/fortran.exp: Likewise.
>   * testsuite/libgomp.graphite/graphite.exp: Likewise.
>   * testsuite/libgomp.c++/c++.exp: load_gcc_lib gcc-dg.exp.
>   Use dg-runtest rather than gfortran-dg-runtest.
> 

Re: [PATCH] ARMv6-M MI thunk fix

[Cesar Philippidis]

On 6/10/13 8:32 AM, Richard Earnshaw wrote:
> On 07/06/13 17:50, Cesar Philippidis wrote:
>> On 6/6/13 9:00 AM, Richard Earnshaw wrote:
>>> The pipeline offset is 4 for Thumb2 as well.  So at the very least you
>>> need to explain why your change doesn't apply then as well.
>>
>> Yes some context is lost in that comment.  Thunks are usually emitted in
>> ARM mode, except for Thumb-only targets.  Is the new comment OK?  If so,
>> please check it in since I do not have SVN write access.
>>
> 
> So what about ARMv7-M, which is thumb2 but no ARM state?

Thumb2 is handled differently. This patch is inside an if
(TARGET_THUMB1) block.

Cesar

Re: [PATCH] ARMv6-M MI thunk fix

[Cesar Philippidis]

On 6/6/13 9:00 AM, Richard Earnshaw wrote:
> The pipeline offset is 4 for Thumb2 as well.  So at the very least you
> need to explain why your change doesn't apply then as well.

Yes some context is lost in that comment.  Thunks are usually emitted in
ARM mode, except for Thumb-only targets.  Is the new comment OK?  If so,
please check it in since I do not have SVN write access.

Thanks,
Cesar


2013-06-07  Julian Brown  
    Cesar Philippidis  

gcc/
* config/arm/arm.c (arm_output_mi_thunk): Fix offset for
TARGET_THUMB1_ONLY.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 199695)
+++ gcc/config/arm/arm.c(working copy)
@@ -25217,7 +25217,12 @@
{
  /* Output ".word .LTHUNKn-7-.LTHUNKPCn".  */
  rtx tem = XEXP (DECL_RTL (function), 0);
- tem = gen_rtx_PLUS (GET_MODE (tem), tem, GEN_INT (-7));
+ /* When supported, thunks are generated in ARM mode.  But for 
+TARGET_THUMB1_ONLY the thunk is in Thumb mode, so the PC 
+pipeline offset is four rather than eight.  Adjust the 
+offset accordingly.  */
+ tem = gen_rtx_PLUS (GET_MODE (tem), tem,
+ GEN_INT (TARGET_THUMB1_ONLY ? -3 : -7));
  tem = gen_rtx_MINUS (GET_MODE (tem),
   tem,
   gen_rtx_SYMBOL_REF (Pmode,

[PATCH] ARMv6-M MI thunk fix

[Cesar Philippidis]

This patch addresses the following FAILs on armv6-m:

  FAIL: g++.sum:g++.old-deja/g++.jason/thunk2.C -std=gnu++11 execution test
  FAIL: g++.sum:g++.old-deja/g++.jason/thunk2.C -std=gnu++98 execution test

The source of the problem is the use of ARM thunk offsets for Thumb1. 
This test is using multiple inheritance, and that triggered the
problem. 

I tested this patch with the default ARM and THUMB multilibs in 
additional to -march=armv6-m.

OK for trunk?

Cesar


2013-06-06  Julian Brown  
Cesar Philippidis  

gcc/
* config/arm/arm.c (arm_output_mi_thunk): Fix offset for
TARGET_THUMB1_ONLY.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 405523)
+++ gcc/config/arm/arm.c(revision 405524)
@@ -23140,7 +23140,11 @@
{
  /* Output ".word .LTHUNKn-7-.LTHUNKPCn".  */
  rtx tem = XEXP (DECL_RTL (function), 0);
- tem = gen_rtx_PLUS (GET_MODE (tem), tem, GEN_INT (-7));
+ /* For TARGET_THUMB1_ONLY the thunk is in Thumb mode, so the PC
+pipeline offset is four rather than eight.  Adjust the offset
+accordingly.  */
+ tem = gen_rtx_PLUS (GET_MODE (tem), tem,
+ GEN_INT (TARGET_THUMB1_ONLY ? -3 : -7));
  tem = gen_rtx_MINUS (GET_MODE (tem),
   tem,
   gen_rtx_SYMBOL_REF (Pmode,

[PATCH] libffi documentation fix

[Cesar Philippidis]

This patch from libffi revision 675c9839224 allows libffi.pdf to be 
generated without tex related errors. I tested it on gcc trunk. Please 
backport it to gcc. The original patch can be found here:


http://sourceware.org/ml/libffi-discuss/2013/msg00086.html

Cesar


2013-06-03  Andreas Schwab  

* doc/libffi.texi (Structures): Fix missing category argument of
@deftp.
Index: libffi/doc/libffi.texi
===
--- libffi/doc/libffi.texi  (revision 199458)
+++ libffi/doc/libffi.texi  (working copy)
@@ -360,7 +360,7 @@
 new @code{ffi_type} object for it.
 
 @tindex ffi_type
-@deftp ffi_type
+@deftp {Data type} ffi_type
 The @code{ffi_type} has the following members:
 @table @code
 @item size_t size

[PATCH] libitm testsuite fixes

[Cesar Philippidis]

Here is a patch from our backlog that addresses a libitm issue where 
setting ENABLE_LTO=1 in site.exp causes the following error with dejagnu:

ERROR: (DejaGnu) proc "libitm_target_compile linker_plugin19344.c 
linker_plugin19344.exe executable {{additional_flags=-flto 
-fuse-linker-plugin}}" does not exist.

This problem usually does not occur since the default site.exp does not
contain ENABLE_LTO=1. This patch has been tested both with and without
our custom site.exp.

Is this OK for trunk? If so, please check it in since I do not have commit
rights.

Cesar Philippidis


2013-05-30  Iain Sandoe  
    Cesar Philippidis  

libitm/
* testsuite/lib/libitm.exp: Reorder lib loads into dependency order.
Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
* testsuite/libitm.c/c.exp: load_gcc_lib gcc-dg.exp.
* testsuite/libitm.c++/c++.exp: load_gcc_lib gcc-dg.exp.
Index: libitm/testsuite/lib/libitm.exp
===
--- libitm/testsuite/lib/libitm.exp (revision 199267)
+++ libitm/testsuite/lib/libitm.exp (working copy)
@@ -23,23 +23,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
 
 set dg-do-what-default run
 
Index: libitm/testsuite/libitm.c++/c++.exp
===
--- libitm/testsuite/libitm.c++/c++.exp (revision 199267)
+++ libitm/testsuite/libitm.c++/c++.exp (working copy)
@@ -15,6 +15,7 @@
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
 
 load_lib libitm-dg.exp
+load_gcc_lib gcc-dg.exp
 
 global shlib_ext
 
Index: libitm/testsuite/libitm.c/c.exp
===
--- libitm/testsuite/libitm.c/c.exp (revision 199267)
+++ libitm/testsuite/libitm.c/c.exp (working copy)
@@ -21,6 +21,7 @@
 }
 
 load_lib libitm-dg.exp
+load_gcc_lib gcc-dg.exp
 
 # If a testcase doesn't have special options, use these.
 if ![info exists DEFAULT_CFLAGS] then {

[PATCH] libgomp testsuite fixes

[Cesar Philippidis]

Here is a patch from our backlog at Mentor Graphics that addresses a 
libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following 
error with dejagnu:

ERROR: (DejaGnu) proc "libgomp_target_compile linker_plugin9263.c 
linker_plugin9263.exe executable {{additional_flags=-flto 
-fuse-linker-plugin}}" does not exist.

This problem usually does not occur since the default site.exp does not
contain ENABLE_LTO=1. I tested both with and without our custom site.exp.

Is it OK for trunk? If so, please check it in since I do not have commit
rights.

Cesar Philippidis


2013-05-30  Iain Sandoe  
    Cesar Philippidis  

libgomp/
* testsuite/lib/libgomp.exp: Reorder lib loads into dependency order.
Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
* testsuite/libgomp.c/c.exp: load_gcc_lib gcc-dg.exp.
* testsuite/libgomp.fortran/fortran.exp: Likewise.
* testsuite/libgomp.graphite/graphite.exp: Likewise.
* testsuite/libgomp.c++/c++.exp: load_gcc_lib gcc-dg.exp.
Use dg-runtest rather than gfortran-dg-runtest.
Index: libgomp/testsuite/libgomp.fortran/fortran.exp
===
--- libgomp/testsuite/libgomp.fortran/fortran.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.fortran/fortran.exp   (working copy)
@@ -1,4 +1,6 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
+load_gcc_lib gfortran-dg.exp
 
 global shlib_ext
 global ALWAYS_CFLAGS
Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp   (revision 199267)
+++ libgomp/testsuite/lib/libgomp.exp   (working copy)
@@ -9,24 +9,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
-load_gcc_lib gfortran-dg.exp
 
 set dg-do-what-default run
 
Index: libgomp/testsuite/libgomp.c/c.exp
===
--- libgomp/testsuite/libgomp.c/c.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c/c.exp   (working copy)
@@ -7,6 +7,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 # If a testcase doesn't have special options, use these.
 if ![info exists DEFAULT_CFLAGS] then {
Index: libgomp/testsuite/libgomp.graphite/graphite.exp
===
--- libgomp/testsuite/libgomp.graphite/graphite.exp (revision 199267)
+++ libgomp/testsuite/libgomp.graphite/graphite.exp (working copy)
@@ -23,6 +23,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 if ![check_effective_target_pthread] {
   return
Index: libgomp/testsuite/libgomp.c++/c++.exp
===
--- libgomp/testsuite/libgomp.c++/c++.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c++/c++.exp   (working copy)
@@ -1,4 +1,5 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 global shlib_ext
 
@@ -53,7 +54,7 @@
 }
 
 # Main loop.
-gfortran-dg-runtest $tests $libstdcxx_includes
+dg-runtest $tests "" $libstdcxx_includes
 }
 
 # All done.