[PATCH] Add missing requirement to crossmodule-indircall-1a.c

[PATCH] Add missing requirement to crossmodule-indircall-1a.c

[Haswell]

The additional source must have the same requirement crossmodule-indircall-1.c has.

	* crossmodule-indircall-1a.c: Add missing requirement.

diff -Nur a/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c b/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c
--- a/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c	2013-08-10 00:53:00.000000000 +0200
+++ b/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c	2014-10-21 16:06:46.715580336 +0200
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target lto } */
 /* It seems there is no way to avoid the other source of mulitple
    source testcase from being compiled independently.  Just avoid
    error.  */

Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[Jeff Law]

On 10/21/14 16:13, Haswell wrote:
> The additional source must have the same requirement crossmodule-indircall-1.c has.
>
> 	* crossmodule-indircall-1a.c: Add missing requirement.
Why?  When used by crossmodule-indircall-1.c we'll have already tested 
the marker and when used by itself, it does nothing.

So I don't see why you think a marker is needed for this source file.

jeff

Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[jb999]

"Jeff Law" <law@redhat.com>:
>On 10/21/14 16:13, Haswell wrote:
>> The additional source must have the same requirement crossmodule-indircall-1.c has.
>>
>> 	* crossmodule-indircall-1a.c: Add missing requirement.
>Why?  When used by crossmodule-indircall-1.c we'll have already tested 
>the marker and when used by itself, it does nothing.

>So I don't see why you think a marker is needed for this source file.

When configuring --disable-lto it gets compiled twice:

FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-generate -D_PROFILE_GENERATE
UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-use -D_PROFILE_USE

Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[Jeff Law]

On 10/21/14 12:21, jb999@gmx.de wrote:
> "Jeff Law" <law@redhat.com>:
>> On 10/21/14 16:13, Haswell wrote:
>>> The additional source must have the same requirement crossmodule-indircall-1.c has.
>>>
>>> 	* crossmodule-indircall-1a.c: Add missing requirement.
>> Why?  When used by crossmodule-indircall-1.c we'll have already tested
>> the marker and when used by itself, it does nothing.
>
>> So I don't see why you think a marker is needed for this source file.
>
> When configuring --disable-lto it gets compiled twice:
>
> FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-generate -D_PROFILE_GENERATE
> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-use -D_PROFILE_USE
I'd recommend looking deeper.  I believe that file should be collapsing 
down to main () { return 0; } when LTO is not enabled.

jeff

Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[jb999]

"Jeff Law" <law@redhat.com>:

> On 10/21/14 12:21, jb999@gmx.de wrote:
> > "Jeff Law" <law@redhat.com>:
> >> On 10/21/14 16:13, Haswell wrote:
> >>> The additional source must have the same requirement crossmodule-indircall-1.c has.
> >>>
> >>> 	* crossmodule-indircall-1a.c: Add missing requirement.
> >> Why?  When used by crossmodule-indircall-1.c we'll have already tested
> >> the marker and when used by itself, it does nothing.
> >
> >> So I don't see why you think a marker is needed for this source file.
> >
> > When configuring --disable-lto it gets compiled twice:
> >
> > FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
> > UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-generate -D_PROFILE_GENERATE
> > UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
> > UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-use -D_PROFILE_USE
> I'd recommend looking deeper.  I believe that file should be collapsing 
> down to main () { return 0; } when LTO is not enabled.

I'm not a dejagnu expert, but this is what happens:

/tmp/build/gcc/xgcc -B/tmp/build/gcc/ /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fno-diagnostics-show-caret -fdiagnostics-color=never /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fprofile-generate -D_PROFILE_GENERATE -lm -o /tmp/build/gcc/testsuite/gcc/crossmodule-indircall-1a.x01
/tmp/cc4rrWCn.o: In function `main':
crossmodule-indircall-1a.c:(.text+0x0): multiple definition of `main'
/tmp/ccgMlXGi.o:crossmodule-indircall-1a.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
compiler exited with status 1

Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[Jeff Law]

On 10/23/14 08:30, jb999@gmx.de wrote:
> "Jeff Law" <law@redhat.com>:
>
>> On 10/21/14 12:21, jb999@gmx.de wrote:
>>> "Jeff Law" <law@redhat.com>:
>>>> On 10/21/14 16:13, Haswell wrote:
>>>>> The additional source must have the same requirement crossmodule-indircall-1.c has.
>>>>>
>>>>> 	* crossmodule-indircall-1a.c: Add missing requirement.
>>>> Why?  When used by crossmodule-indircall-1.c we'll have already tested
>>>> the marker and when used by itself, it does nothing.
>>>
>>>> So I don't see why you think a marker is needed for this source file.
>>>
>>> When configuring --disable-lto it gets compiled twice:
>>>
>>> FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-generate -D_PROFILE_GENERATE
>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-use -D_PROFILE_USE
>> I'd recommend looking deeper.  I believe that file should be collapsing
>> down to main () { return 0; } when LTO is not enabled.
>
> I'm not a dejagnu expert, but this is what happens:
>
> /tmp/build/gcc/xgcc -B/tmp/build/gcc/ /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fno-diagnostics-show-caret -fdiagnostics-color=never /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fprofile-generate -D_PROFILE_GENERATE -lm -o /tmp/build/gcc/testsuite/gcc/crossmodule-indircall-1a.x01
> /tmp/cc4rrWCn.o: In function `main':
> crossmodule-indircall-1a.c:(.text+0x0): multiple definition of `main'
> /tmp/ccgMlXGi.o:crossmodule-indircall-1a.c:(.text+0x0): first defined here
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
Thanks.

What's weird here is the source file is listed twice on the command 
line!  No wonder it's failing.

I can't typically decipher tcl code without trace info and some 
send_user commands to see what the values of various things are.  But 
the following seems, umm, odd:

profopt.exp:
         set extra_flags [profopt-get-options $src]
[ ... ]

         set options "$extra_options"
         lappend options "additional_flags=$option $extra_flags 
$profile_option"

         set comp_output [${tool}_target_compile "$src" "$execname1" 
executable $options]


Note $src passed to the target_compile procedure as an argument and also 
inside the string $options.

I'd think that's the real problem here.  Though I have no idea how 
that's expected to work in an LTO enabled compile.

jeff

Re: Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[jb999]

"Jeff Law" <law@redhat.com>:
>On 10/23/14 08:30, jb999@gmx.de wrote:
>> "Jeff Law" <law@redhat.com>:
>>
>>> On 10/21/14 12:21, jb999@gmx.de wrote:
>>>> "Jeff Law" <law@redhat.com>:
>>>>> On 10/21/14 16:13, Haswell wrote:
>>>>>> The additional source must have the same requirement crossmodule-indircall-1.c has.
>>>>>>
>>>>>> 	* crossmodule-indircall-1a.c: Add missing requirement.
>>>>> Why?  When used by crossmodule-indircall-1.c we'll have already tested
>>>>> the marker and when used by itself, it does nothing.
>>>>
>>>>> So I don't see why you think a marker is needed for this source file.
>>>>
>>>> When configuring --disable-lto it gets compiled twice:
>>>>
>>>> FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
>>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-generate -D_PROFILE_GENERATE
>>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
>>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-use -D_PROFILE_USE
>>> I'd recommend looking deeper.  I believe that file should be collapsing
>>> down to main () { return 0; } when LTO is not enabled.
>>
>> I'm not a dejagnu expert, but this is what happens:
>>
>> /tmp/build/gcc/xgcc -B/tmp/build/gcc/ /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fno-diagnostics-show-caret -fdiagnostics-color=never /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fprofile-generate -D_PROFILE_GENERATE -lm -o /tmp/build/gcc/testsuite/gcc/crossmodule-indircall-1a.x01
>> /tmp/cc4rrWCn.o: In function `main':
>> crossmodule-indircall-1a.c:(.text+0x0): multiple definition of `main'
>> /tmp/ccgMlXGi.o:crossmodule-indircall-1a.c:(.text+0x0): first defined here
>> collect2: error: ld returned 1 exit status
>> compiler exited with status 1
>Thanks.

>What's weird here is the source file is listed twice on the command 
>line!  No wonder it's failing.

>I can't typically decipher tcl code without trace info and some 
>send_user commands to see what the values of various things are.
>[...]
>Though I have no idea how that's expected to work in an LTO enabled compile.

With LTO enabled it runs just fine (which is the reason for the patch I suggested):

spawn /tmp/build/gcc/xgcc -B/tmp/build/gcc/ /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fno-diagnostics-show-caret -fdiagnostics-color=never -fprofile-generate -D_PROFILE_GENERATE -lm -o /tmp/build/gcc/testsuite/gcc/crossmodule-indircall-1a.x01

PASS: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
PASS: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-generate -D_PROFILE_GENERATE
spawn /tmp/build/gcc/xgcc -B/tmp/build/gcc/ /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fno-diagnostics-show-caret -fdiagnostics-color=never -fprofile-use -D_PROFILE_USE -lm -o /tmp/build/gcc/testsuite/gcc/crossmodule-indircall-1a.x02

PASS: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
PASS: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-use -D_PROFILE_USE

Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[Jeff Law]

On 11/05/14 13:30, jb999@gmx.de wrote:
> "Jeff Law" <law@redhat.com>:
>> On 10/23/14 08:30, jb999@gmx.de wrote:
>>> "Jeff Law" <law@redhat.com>:
>>>
>>>> On 10/21/14 12:21, jb999@gmx.de wrote:
>>>>> "Jeff Law" <law@redhat.com>:
>>>>>> On 10/21/14 16:13, Haswell wrote:
>>>>>>> The additional source must have the same requirement crossmodule-indircall-1.c has.
>>>>>>>
>>>>>>> 	* crossmodule-indircall-1a.c: Add missing requirement.
>>>>>> Why?  When used by crossmodule-indircall-1.c we'll have already tested
>>>>>> the marker and when used by itself, it does nothing.
>>>>>
>>>>>> So I don't see why you think a marker is needed for this source file.
>>>>>
>>>>> When configuring --disable-lto it gets compiled twice:
>>>>>
>>>>> FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
>>>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-generate -D_PROFILE_GENERATE
>>>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
>>>>> UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,    -fprofile-use -D_PROFILE_USE
>>>> I'd recommend looking deeper.  I believe that file should be collapsing
>>>> down to main () { return 0; } when LTO is not enabled.
>>>
>>> I'm not a dejagnu expert, but this is what happens:
>>>
>>> /tmp/build/gcc/xgcc -B/tmp/build/gcc/ /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fno-diagnostics-show-caret -fdiagnostics-color=never /tmp/gcc-4.9.1/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fprofile-generate -D_PROFILE_GENERATE -lm -o /tmp/build/gcc/testsuite/gcc/crossmodule-indircall-1a.x01
>>> /tmp/cc4rrWCn.o: In function `main':
>>> crossmodule-indircall-1a.c:(.text+0x0): multiple definition of `main'
>>> /tmp/ccgMlXGi.o:crossmodule-indircall-1a.c:(.text+0x0): first defined here
>>> collect2: error: ld returned 1 exit status
>>> compiler exited with status 1
>> Thanks.
>
>> What's weird here is the source file is listed twice on the command
>> line!  No wonder it's failing.
>
>> I can't typically decipher tcl code without trace info and some
>> send_user commands to see what the values of various things are.
>> [...]
>> Though I have no idea how that's expected to work in an LTO enabled compile.
>
> With LTO enabled it runs just fine (which is the reason for the patch I suggested):
It's definitely some wacky dejagnu nonsense going on.

So if I run both crossmodule-indircall "tests" (yes I know one is an 
auxiliary file, but what I'm doing emulates what happen inside all the 
dejagnu/tcl/expect insanity):

Running /home/gcc/GIT-2/gcc/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp ...
FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, 
-fprofile-generate -D_PROFILE_GENERATE


So, yea, in a --disable-lto toolchain I can reproduce you problem.

Now it gets interesting.  Let's run the two tests independently.

  make check-gcc RUNTESTFLAGS="tree-prof.exp=crossmodule-indircall-1.c"
[ ...]
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file 
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for 
target.
Using /home/gcc/GIT-2/gcc/gcc/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running /home/gcc/GIT-2/gcc/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp ...

                 === gcc Summary ===

# of unsupported tests          1

  make check-gcc RUNTESTFLAGS="tree-prof.exp=crossmodule-indircall-1a.c"
[ ... ]
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file 
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for 
target.
Using /home/gcc/GIT-2/gcc/gcc/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running /home/gcc/GIT-2/gcc/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp ...

                 === gcc Summary ===

# of expected passes            4
/home/tmp/gcc3/gcc/xgcc  version 5.0.0 20150115 (experimental) (GCC)


Umm, WTF.  if I run them independently, everything works as expected. 
Clearly state from running crossmodule-indircall-1.c is affecting how we 
"test" crossmodule-indircall-1a.c.

I'm pretty sure we don't want to "fix" crossmodule-indircall-1a.c, but 
that the bug is in the dejagnu/tcl/expect code.

Jeff

Re: [PATCH] Add missing requirement to crossmodule-indircall-1a.c

[Jeff Law]

On 11/05/14 13:30, jb999@gmx.de wrote:
>
> With LTO enabled it runs just fine (which is the reason for the patch I suggested):
This is definitely a testing framework problem.  The profopt framework 
isn't clearing the "additional_whatever" variables.  Presumably failure 
to clear is specific to a test failing or being unsupported as I'd 
expect all kinds of failures if we never cleared those variables.

My head hurts, I haven't had to read this much expect/tcl in nearly 20 
years.  But I'm totally certain we shouldn't be hacking up the source 
code to deal with the defect in the testing harness.

jeff