Re: Generate annotations for a binary translator

[陳韋任]

Hi, Ian

> That documentation is out of date.  The CFG is now retained through most
> of the RTL passes.

  You said "through most of the RTLpasses". And I found the CFG
is freed before other passes in gcc/passes.c.

NEXT_PASS (pass_free_cfg);
NEXT_PASS (pass_machine_reorg);
NEXT_PASS (pass_cleanup_barriers);
NEXT_PASS (pass_delay_slots);
NEXT_PASS (pass_split_for_shorten_branches);
NEXT_PASS (pass_convert_to_eh_region_ranges);
NEXT_PASS (pass_shorten_branches);
NEXT_PASS (pass_set_nothrow_function_flags);
NEXT_PASS (pass_final);

Is the CFG the same as the one in the assembly? I mean
if I analysis the assembly and contruct the CFG back, they
are the same?

  Thanks.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

internal_error in loop-iv.c

[Frederic Riss]

Hi,

My port hits this assertion in loop-iv.c:799:

gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));

It's in the function get_biv_step:

static bool
get_biv_step (df_ref last_def, rtx reg, rtx *inner_step,
  enum machine_mode *inner_mode, enum rtx_code *extend,
  enum machine_mode *outer_mode, rtx *outer_step)
{
  *outer_mode = GET_MODE (reg);

  if (!get_biv_step_1 (last_def, reg,
   inner_step, inner_mode, extend, *outer_mode,
   outer_step))
return false;

  gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
  gcc_assert (*inner_mode != *outer_mode || *outer_step == const0_rtx);

  return true;
}

The analyzed register is SImode (outer_mode), but the step determined
by the biv step analysis returns a V2HI (inner_mode) step value. As
the register is modified through a subreg, there's no extension. The
vector mode comes from the analysis of the following insn:

(insn 170 169 171 12 /work1-disk/dft/src/dft.c:99 (set (subreg:V2HI
(reg:SI 544 [ vect_vec_iv_.173 ]) 0)
(plus:V2HI (subreg:V2HI (reg:SI 540 [ vect_vec_iv_.173 ]) 0)
(subreg:V2HI (reg:SI 542 [ vect_cst_.172 ]) 0))) 347
{addv2hi3} (expr_list:REG_DEAD (reg:SI 542 [ vect_cst_.172 ])
(expr_list:REG_EQUAL (plus:V2HI (subreg:V2HI (reg:SI 540 [
vect_vec_iv_.173 ]) 0)
(const_vector:V2HI [
(const_int 4 [0x4])
(const_int 4 [0x4])
]))
(nil

The code looks OK to me, but I thought there might be some rule about
vector subregs that I don't know about.

If the code is OK, should get_biv_step return true or false?

Many thanks,
Fred

Bootstrap failure on PowerPC

[Revital Eres]

Hello,

I get the following bootstrap failure on ppc64-redhat-linux with trunk -r174840
compiling with -O2 flag..

Thanks,
Revital


/bin/sh ../../libtool --tag=CC   --mode=compile
/home/eres/mainline/build/./gcc/xgcc
-B/home/eres/mainline/build/./gcc/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/
-B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/
-isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include
-isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include
 -m32 -fPIC -mstrict-align -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc/libjava/classpath/native/fdlibm
-I../../include-fexceptions -fasynchronous-unwind-tables -g -O2
-m32 -fPIC -mstrict-align -MT w_exp.lo -MD -MP -MF .deps/w_exp.Tpo -c
-o w_exp.lo ../../../../../../../gcc/libjava/classpath/native/fdlibm/w_exp.c
../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c: In
function ג_Jv_strtod_rג:
../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c:106:1:
internal compiler error: in op_iter_init, at tree-flow-inline.h:745
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [strtod.lo] Error 1
make[7]: *** Waiting for unfinished jobs
mv -f .deps/s_tanh.Tpo .deps/s_tanh.Plo

Re: Bootstrap failure on PowerPC

[Richard Guenther]

On Thu, Jun 9, 2011 at 2:01 PM, Revital Eres  wrote:
> Hello,
>
> I get the following bootstrap failure on ppc64-redhat-linux with trunk 
> -r174840
> compiling with -O2 flag..

Can you provide a backtrace and open a bugreport?

Richard.

> Thanks,
> Revital
>
>
> /bin/sh ../../libtool --tag=CC   --mode=compile
> /home/eres/mainline/build/./gcc/xgcc
> -B/home/eres/mainline/build/./gcc/
> -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/
> -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/
> -isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include
> -isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include
>  -m32 -fPIC -mstrict-align -DHAVE_CONFIG_H -I.
> -I../../../../../../../gcc/libjava/classpath/native/fdlibm
> -I../../include    -fexceptions -fasynchronous-unwind-tables -g -O2
> -m32 -fPIC -mstrict-align -MT w_exp.lo -MD -MP -MF .deps/w_exp.Tpo -c
> -o w_exp.lo ../../../../../../../gcc/libjava/classpath/native/fdlibm/w_exp.c
> ../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c: In
> function ג_Jv_strtod_rג:
> ../../../../../../../gcc/libjava/classpath/native/fdlibm/strtod.c:106:1:
> internal compiler error: in op_iter_init, at tree-flow-inline.h:745
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[7]: *** [strtod.lo] Error 1
> make[7]: *** Waiting for unfinished jobs
> mv -f .deps/s_tanh.Tpo .deps/s_tanh.Plo
>

Re: Bootstrap failure on PowerPC

[Revital Eres]

Hello,

>
> Can you provide a backtrace and open a bugreport?

Sure, will do that. (I deleted the bootstrap dir so I can not provide
that info immediately though)

Thanks,
Revital

Re: Generate annotations for a binary translator

[Ian Lance Taylor]

陳韋任  writes:

>> That documentation is out of date.  The CFG is now retained through most
>> of the RTL passes.
>
>   You said "through most of the RTLpasses". And I found the CFG
> is freed before other passes in gcc/passes.c.
>
> NEXT_PASS (pass_free_cfg);
> NEXT_PASS (pass_machine_reorg);
> NEXT_PASS (pass_cleanup_barriers);
> NEXT_PASS (pass_delay_slots);
> NEXT_PASS (pass_split_for_shorten_branches);
> NEXT_PASS (pass_convert_to_eh_region_ranges);
> NEXT_PASS (pass_shorten_branches);
> NEXT_PASS (pass_set_nothrow_function_flags);
> NEXT_PASS (pass_final);
>
> Is the CFG the same as the one in the assembly? I mean
> if I analysis the assembly and contruct the CFG back, they
> are the same?

The machine reorg pass in particular can change anything, and may change
the CFG.  The delay slots pass may also change the CFG.  It depends on
your particular target.

Ian

Re: Bootstrap failure on PowerPC

[Dominique Dhumieres]

Hi,

I have provided a backtrace and a preprocessed file in
PR49344.

Dominique

How to set revision_string in version.c?

[Vlad Krylov]

Hi all.


I see in gcc/gcc/version.c:

/* The complete version string, assembled from several pieces.
   BASEVER, DATESTAMP, DEVPHASE, and REVISION are defined by the
   Makefile.  */

In gcc/gcc/Makefile.in:

REVISION:= $(srcdir)/REVISION 

I've created gcc/REVISION file with some number and then build new gcc. But 
'gcc -v' doesn't differ from previous build, I can't find the number.
What am I doing wrong? Help me please

Re: Disabling Secondary Tests

[Janis Johnson]

On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
> On 6/6/11, Janis Johnson  wrote:
>> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>>> The PPH project has tests that compile two different ways, and
>>> then compare the assembly.  If either of the compiles fails, the
>>> comparison will fail.  We'd like to simply not run the comparison.
>>>
>>> We currently have:
>>>
>>> set have_errs [llength [grep $test "{\[ \t\]\+dg-error\[\t\]\+.*\[
>>> \t\]\+}"]]
>>> # Compile the file the first time for a base case.
>>> dg-test -keep-output $test "$options -I." ""
>>>
>>> if { $have_errs } {
>>>verbose -log "regular compilation failed"
>>>fail "$nshort $options, regular compilation failed"
>>>return
>>> }
>>>
>>> But that only stops subsequent actions when the test is known
>>> a priori to have errors.  How do we detect compilation errors,
>>> so as to skip the remainder of the actions?
>>
>> Complicated GCC tests do this by using local procs instead of dg-runtest
>> and dg-test.  See, for example, gcc.dg/lto/lto.exp,
>> gcc.dg/compat/compat.exp and gcc.dg/tree-prof/tree-prof.exp, which use
>> lto.exp, compat.exp and profopt.exp from GCC's testsuite/lib.  Those
>> have scenarios in which further testing is skipped after a compile or
>> link fails.
> 
> So, I ended up changing the definition of fail from "reports test
> failing" to "does not produce an assembly file".  We really need
> the latter for comparison, so it is the true measure.  Once I made
> that change in orientation, I was able to achieve what I wanted.
> 
> The simple part is the regular compile.
> 
> # Compile the file the first time for a base case.
> set dg-do-what-default compile
> dg-test -keep-output $test "$options -I." ""
> 
> # Quit if it did not compile successfully.
> if { ![file_on_host exists "$bname.s"] } {
> # All regular compiles should pass.
> fail "$nshort $options (regular assembly missing)"
> return
> }

Don't use dg-test, use a new variant of it as is done with the lto,
compat, and profopt tests.  You'll have much more control that way
and can better check the success of individual steps to decide what
to do next.

> The complicated part is the compile we are comparing against, which
> required knowing whether or not a compile failure is expected.  For
> that we grep for dg-xfail-if and the appropriate option.
> 
> # Compile a second time using the pph files.
> dg-test -keep-output $test "$options $mapflag -I." ""
> 
> # Quit if it did not compile successfully.
> if { ![file_on_host exists "$bname.s"] } {
> # Expect assembly to be missing when the compile is an expected fail.
> if { ![llength [grep $test "dg-xfail-if.*-fpph-map"]] } {
> fail "$nshort $options (pph assembly missing)"
> }
> return
> }
> 

Relying on the existence of dg-xfail-if won't work when an expected
compilation failure starts working, or an unexpected one arises.

Janis

Re: How to set revision_string in version.c?

[Jonathan Wakely]

On 9 June 2011 17:12, Vlad Krylov wrote:
>
> Hi all.
>
>
> I see in gcc/gcc/version.c:
>
> /* The complete version string, assembled from several pieces.
>   BASEVER, DATESTAMP, DEVPHASE, and REVISION are defined by the
>   Makefile.  */
>
> In gcc/gcc/Makefile.in:
>
> REVISION    := $(srcdir)/REVISION
>
> I've created gcc/REVISION file with some number and then build new gcc. But 
> 'gcc -v' doesn't differ from previous build, I can't find the number.
> What am I doing wrong? Help me please

Does the file gcc/DEV-PHASE exist and is it non-empty?

Re: How to set revision_string in version.c?

[Basile Starynkevitch]

On Thu, 9 Jun 2011 16:12:17 +
Vlad Krylov  wrote:
> 
> REVISION:= $(srcdir)/REVISION 

Assuming you are talking of some svn snapshot, the good way to update it is to 
use
  ./contrib/gcc_update
that script will build the REVISION file correctly (after running svn update).

Regards.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Adding fstack-protector prologue to get_pc_thunk for targets with TARGET_PAD_SHORT_FUNCTION

[asharif tools]

On Wed, Jun 8, 2011 at 10:32 PM, Ian Lance Taylor  wrote:
> asharif tools  writes:
>
>> function:
>>       call    __i686.get_pc_thunk.bx
>>       addl    $_GLOBAL_OFFSET_TABLE_, %ebx
>>       movl    %gs:20, %eax # Stack-guard init
>>       movl    %eax, -12(%ebp) # Stack-guard init
>
>> Now, what I want to do is move stack guard initialization part
>> (consisting of the two instructions I have commented as "Stack-guard
>> init" into get_pc_thunk.bx for those functions that have both the
>> stack guard and a call to get_pc_thunk.bx. The compiler should
>> generate a "stack_guarded_get_pc_thunk.bx" that will do move the
>> %gs:20 value to the correction location on the stack instead of
>> executing nops. In this way some useful work can be done instead of
>> nops.
>
> I don't understand how you can do that.  The offset from %ebp will be
> different in different functions.  When optimizing, it is likely to be
> an offset from %esp instead.  The scratch register used may also be
> different; consider functions with __attribute__ ((regparm (2))), or the
> use of -mregparm=2.

I see.

Would it be possible for the caller of stack_protected_get_pc_thunk to
pass in this offset from gs in the return register (ebx in this case)
in all the cases you described?

>
>
>> As far as I understand, the stack guard part is done in function.c
>> (called by cfgexpand.c) which adds the prologue and epilogue to the
>> protected functions. At this point, we are still target-independent.
>>
>> The get_pc_thunk.bx is generated by the target-specific
>> config/i386/i386.c part (ix86_file_end).
>>
>> How should I go about creating such a patch that should:
>>
>> 1. Check if a function has both stack guard as well as access to a
>> global (which would result in having the get_pc_thunk call).
>> 2. Remove the stack guard prologue instructions.
>> 3. Replace calls to get_pc_thunk.bx in that function to
>> stack_guarded_get_pc_thunk.
>>
>> Specifically, what phase should this be done in?
>
> If you can do this, do it at final, in the expansion for the stack_set
> and set_got insns.
>
> Ian
>

C++0x atomics and GCC - update

[Andrew MacLeod]

I've updated the original documents on the atomics page 
http://gcc.gnu.org/wiki/Atomic/GCCMM  to add some clarity in places 
(especially in the 'synchronization models' section) and updated some 
bitrot.


As mentioned last week, I've added a section on codegen which Aldy has 
begun implementing: http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen


I've also just finished an initial cut of a new page which discusses the 
optimization effects the different models have. It took a while to 
whittle it down to something digestible, but I think the interaction is 
fairly readable now.  It is not a complete analysis of each optimization 
yet, but it does cover how the different models will impact the 
optimizers and touches on implementation.  I'll leave the real gory 
details until the codegen changes are complete and there is atomic code 
to play with.


The one-line version is that most optimizations will probably just need 
tweaking for what to do around built-ins rather than always assuming 
they are a full barrier.


WIP : http://gcc.gnu.org/wiki/Atomic/GCCMM/Optimizations

I will now pick up where Aldy left off and finish the codegen parts for 
the mem_exchange instruction. (I might switch that to the load and store 
operations).  Then I'll create some testcases for it, and modify the 
dead store optimizer as a litmus test.   This will give us an 
implementation sample to see that everything plays together and behaves 
as expected.  If that seems to work out, we'll proceed with the rest of 
the atomic operations.


If you are interested in the memory model read that newest document and 
let me know what isn't clear. If you know a lot about this stuff, look 
at it and let me know what needs fixing.  If you don't care, go read 
your next email :-)


There will also be lots of time to comment when the patch is ready for 
the 'cxx-mem-model' branch


Andrew

Re: Adding fstack-protector prologue to get_pc_thunk for targets with TARGET_PAD_SHORT_FUNCTION

[Ian Lance Taylor]

asharif tools  writes:

> On Wed, Jun 8, 2011 at 10:32 PM, Ian Lance Taylor  wrote:
>> asharif tools  writes:
>>
>>> function:
>>>       call    __i686.get_pc_thunk.bx
>>>       addl    $_GLOBAL_OFFSET_TABLE_, %ebx
>>>       movl    %gs:20, %eax # Stack-guard init
>>>       movl    %eax, -12(%ebp) # Stack-guard init
>>
>>> Now, what I want to do is move stack guard initialization part
>>> (consisting of the two instructions I have commented as "Stack-guard
>>> init" into get_pc_thunk.bx for those functions that have both the
>>> stack guard and a call to get_pc_thunk.bx. The compiler should
>>> generate a "stack_guarded_get_pc_thunk.bx" that will do move the
>>> %gs:20 value to the correction location on the stack instead of
>>> executing nops. In this way some useful work can be done instead of
>>> nops.
>>
>> I don't understand how you can do that.  The offset from %ebp will be
>> different in different functions.  When optimizing, it is likely to be
>> an offset from %esp instead.  The scratch register used may also be
>> different; consider functions with __attribute__ ((regparm (2))), or the
>> use of -mregparm=2.
>
> I see.
>
> Would it be possible for the caller of stack_protected_get_pc_thunk to
> pass in this offset from gs in the return register (ebx in this case)
> in all the cases you described?

You mean the offset from %esp or %ebp.  This would require an leal
instruction, so now you are only saving one instruction.  And that by
itself would not be enough, because __stack_protected_get_pc_thunk would
not know which register it could use to move the value.  But you could
have different variants of the function, or it could preserve the
register.  With those conditions, yes, I think it would be possible.
But the savings seems fairly minimal to me, and it only matters on the
Atom.  Not that I want to stop you if you are interested.

Ian

Tracing C++ template instantiations

[Jonathan Wakely]

When I'm working on complicated template code and debugging a mixture
of bugs in my templates and ICEs in g++ caused by my buggy templates I
sometimes wish I could see a dump of all the templates that the
compiler is instantiating, so I can see at which point in a
deeply-nested instantiation things don't happen the way I expected
them to.  With variadic templates in particular it's sometimes hard to
visualize what's happening to your code.

Someone else asked for this the other day on gcc-help
(http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
I'd take a look at implementing it. It turns out that or class
templates all that's needed is something like:
 verbatim ("instantiating class template %qT", type)
in instantiate_class_template_1 in gcc/cp/pt.c
Presumably it wouldn't be much harder to do the same for function templates.

Is there something that does this already that I've missed?  If I were
to add a switch like -ftrace-template-instantiation to control this,
is there any chance of getting it accepted?

It might be useful if the trace said something like:
  attempting to instantiate foo...
attempting to instantiate foo::baz ...
successfully instantiated foo::baz
  failed to instantiate foo
with nesting to see which instantiations depend on others and to see
which pass/fail, but I've already found it useful just to see a list
of instantiations, in order to verify whether some refactoring reduces
the number of instantiations.

Would anyone else find this useful, or should I just keep it in my own
source tree for my own use?

Re: Tracing C++ template instantiations

[Jason Merrill]

On 06/09/2011 03:48 PM, Jonathan Wakely wrote:

Someone else asked for this the other day on gcc-help
(http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
I'd take a look at implementing it. It turns out that or class
templates all that's needed is something like:
  verbatim ("instantiating class template %qT", type)
in instantiate_class_template_1 in gcc/cp/pt.c
Presumably it wouldn't be much harder to do the same for function templates.


How about patterning this on announce_function, so calling the compiler 
without -quiet would print class template instantiations as well?  Then 
you wouldn't need to handle function templates, since announce_function 
already does.


Jason

Re: Tracing C++ template instantiations

[Jonathan Wakely]

On 9 June 2011 21:06, Jason Merrill wrote:
> On 06/09/2011 03:48 PM, Jonathan Wakely wrote:
>>
>> Someone else asked for this the other day on gcc-help
>> (http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
>> I'd take a look at implementing it. It turns out that or class
>> templates all that's needed is something like:
>>  verbatim ("instantiating class template %qT", type)
>> in instantiate_class_template_1 in gcc/cp/pt.c
>> Presumably it wouldn't be much harder to do the same for function
>> templates.
>
> How about patterning this on announce_function, so calling the compiler
> without -quiet would print class template instantiations as well?  Then you
> wouldn't need to handle function templates, since announce_function already
> does.

That sounds helpful, I'll look into it, thanks.

Re: Disabling Secondary Tests

[Lawrence Crowl]

On 6/9/11, Janis Johnson  wrote:
> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
>> On 6/6/11, Janis Johnson  wrote:
>>> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
 The PPH project has tests that compile two different ways, and
 then compare the assembly.  If either of the compiles fails, the
 comparison will fail.  We'd like to simply not run the comparison.

 We currently have:

 set have_errs [llength [grep $test "{\[ \t\]\+dg-error\[\t\]\+.*\[
 \t\]\+}"]]
 # Compile the file the first time for a base case.
 dg-test -keep-output $test "$options -I." ""

 if { $have_errs } {
verbose -log "regular compilation failed"
fail "$nshort $options, regular compilation failed"
return
 }

 But that only stops subsequent actions when the test is known
 a priori to have errors.  How do we detect compilation errors,
 so as to skip the remainder of the actions?
>>>
>>> Complicated GCC tests do this by using local procs instead of dg-runtest
>>> and dg-test.  See, for example, gcc.dg/lto/lto.exp,
>>> gcc.dg/compat/compat.exp and gcc.dg/tree-prof/tree-prof.exp, which use
>>> lto.exp, compat.exp and profopt.exp from GCC's testsuite/lib.  Those
>>> have scenarios in which further testing is skipped after a compile or
>>> link fails.
>>
>> So, I ended up changing the definition of fail from "reports test
>> failing" to "does not produce an assembly file".  We really need
>> the latter for comparison, so it is the true measure.  Once I made
>> that change in orientation, I was able to achieve what I wanted.
>>
>> The simple part is the regular compile.
>>
>> # Compile the file the first time for a base case.
>> set dg-do-what-default compile
>> dg-test -keep-output $test "$options -I." ""
>>
>> # Quit if it did not compile successfully.
>> if { ![file_on_host exists "$bname.s"] } {
>> # All regular compiles should pass.
>> fail "$nshort $options (regular assembly missing)"
>> return
>> }
>
> Don't use dg-test, use a new variant of it as is done with the lto,
> compat, and profopt tests.  You'll have much more control that way
> and can better check the success of individual steps to decide what
> to do next.

I am having trouble identifying the variant.  Does it have a name,
or is it inline code?

>> The complicated part is the compile we are comparing against, which
>> required knowing whether or not a compile failure is expected.  For
>> that we grep for dg-xfail-if and the appropriate option.
>>
>> # Compile a second time using the pph files.
>> dg-test -keep-output $test "$options $mapflag -I." ""
>>
>> # Quit if it did not compile successfully.
>> if { ![file_on_host exists "$bname.s"] } {
>> # Expect assembly to be missing when the compile is an expected fail.
>> if { ![llength [grep $test "dg-xfail-if.*-fpph-map"]] } {
>> fail "$nshort $options (pph assembly missing)"
>> }
>> return
>> }
>
> Relying on the existence of dg-xfail-if won't work when an expected
> compilation failure starts working, or an unexpected one arises.

If the compilation starts working, I get an assembly file, and
continue to assembly comparisons.  If the compilation fails,
but with a different error, then the other (typically dg-bogus)
directives should report the unexpected failure.  In either case,
I think, I get proper notice.  Am I missing something?

-- 
Lawrence Crowl

Re: Disabling Secondary Tests

[Janis Johnson]

On 06/09/2011 01:30 PM, Lawrence Crowl wrote:
> On 6/9/11, Janis Johnson  wrote:
>> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
>>> On 6/6/11, Janis Johnson  wrote:
 On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
> The PPH project has tests that compile two different ways, and
> then compare the assembly.  If either of the compiles fails, the
> comparison will fail.  We'd like to simply not run the comparison.
>
> We currently have:
>
> set have_errs [llength [grep $test "{\[ \t\]\+dg-error\[\t\]\+.*\[
> \t\]\+}"]]
> # Compile the file the first time for a base case.
> dg-test -keep-output $test "$options -I." ""
>
> if { $have_errs } {
>verbose -log "regular compilation failed"
>fail "$nshort $options, regular compilation failed"
>return
> }
>
> But that only stops subsequent actions when the test is known
> a priori to have errors.  How do we detect compilation errors,
> so as to skip the remainder of the actions?

 Complicated GCC tests do this by using local procs instead of dg-runtest
 and dg-test.  See, for example, gcc.dg/lto/lto.exp,
 gcc.dg/compat/compat.exp and gcc.dg/tree-prof/tree-prof.exp, which use
 lto.exp, compat.exp and profopt.exp from GCC's testsuite/lib.  Those
 have scenarios in which further testing is skipped after a compile or
 link fails.
>>>
>>> So, I ended up changing the definition of fail from "reports test
>>> failing" to "does not produce an assembly file".  We really need
>>> the latter for comparison, so it is the true measure.  Once I made
>>> that change in orientation, I was able to achieve what I wanted.
>>>
>>> The simple part is the regular compile.
>>>
>>> # Compile the file the first time for a base case.
>>> set dg-do-what-default compile
>>> dg-test -keep-output $test "$options -I." ""
>>>
>>> # Quit if it did not compile successfully.
>>> if { ![file_on_host exists "$bname.s"] } {
>>> # All regular compiles should pass.
>>> fail "$nshort $options (regular assembly missing)"
>>> return
>>> }
>>
>> Don't use dg-test, use a new variant of it as is done with the lto,
>> compat, and profopt tests.  You'll have much more control that way
>> and can better check the success of individual steps to decide what
>> to do next.
> 
> I am having trouble identifying the variant.  Does it have a name,
> or is it inline code?

I meant that you should write one.  For example, gcc.dg/lto/lto.exp
uses lto_execute which is defined in lib/lto.exp, and
gcc.dg/compat/compat.exp uses compat-execute defined in lib/compat.exp.

>>> The complicated part is the compile we are comparing against, which
>>> required knowing whether or not a compile failure is expected.  For
>>> that we grep for dg-xfail-if and the appropriate option.
>>>
>>> # Compile a second time using the pph files.
>>> dg-test -keep-output $test "$options $mapflag -I." ""
>>>
>>> # Quit if it did not compile successfully.
>>> if { ![file_on_host exists "$bname.s"] } {
>>> # Expect assembly to be missing when the compile is an expected 
>>> fail.
>>> if { ![llength [grep $test "dg-xfail-if.*-fpph-map"]] } {
>>> fail "$nshort $options (pph assembly missing)"
>>> }
>>> return
>>> }
>>
>> Relying on the existence of dg-xfail-if won't work when an expected
>> compilation failure starts working, or an unexpected one arises.
> 
> If the compilation starts working, I get an assembly file, and
> continue to assembly comparisons.  If the compilation fails,
> but with a different error, then the other (typically dg-bogus)
> directives should report the unexpected failure.  In either case,
> I think, I get proper notice.  Am I missing something?

I don't fully understand the purpose of grepping for dg-xfail-if.
You shouldn't care about that within the test, just whether the
compile succeeded or not.  If there are messages that prevent the
compile from succeeding, then they should be handled with appropriate
test directives.

Apart from that, whether or not a dg-xfail-if directives takes effect
depends on the target and options used for the test.

Just in case you're not aware of it (many people aren't), the test
directives are documented in
http://gcc.gnu.org/onlinedocs/gccint/Directives.html#Directive.

Janis

Re: Disabling Secondary Tests

[Lawrence Crowl]

On 6/9/11, Janis Johnson  wrote:
> On 06/09/2011 01:30 PM, Lawrence Crowl wrote:
>> On 6/9/11, Janis Johnson  wrote:
>>> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
 On 6/6/11, Janis Johnson  wrote:
> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>> The PPH project has tests that compile two different ways, and
>> then compare the assembly.  If either of the compiles fails, the
>> comparison will fail.  We'd like to simply not run the comparison.
>>
>> We currently have:
>>
>> set have_errs [llength [grep $test "{\[ \t\]\+dg-error\[\t\]\+.*\[
>> \t\]\+}"]]
>> # Compile the file the first time for a base case.
>> dg-test -keep-output $test "$options -I." ""
>>
>> if { $have_errs } {
>>verbose -log "regular compilation failed"
>>fail "$nshort $options, regular compilation failed"
>>return
>> }
>>
>> But that only stops subsequent actions when the test is known
>> a priori to have errors.  How do we detect compilation errors,
>> so as to skip the remainder of the actions?
>
> Complicated GCC tests do this by using local procs instead of
> dg-runtest
> and dg-test.  See, for example, gcc.dg/lto/lto.exp,
> gcc.dg/compat/compat.exp and gcc.dg/tree-prof/tree-prof.exp, which use
> lto.exp, compat.exp and profopt.exp from GCC's testsuite/lib.  Those
> have scenarios in which further testing is skipped after a compile or
> link fails.

 So, I ended up changing the definition of fail from "reports test
 failing" to "does not produce an assembly file".  We really need
 the latter for comparison, so it is the true measure.  Once I made
 that change in orientation, I was able to achieve what I wanted.

 The simple part is the regular compile.

 # Compile the file the first time for a base case.
 set dg-do-what-default compile
 dg-test -keep-output $test "$options -I." ""

 # Quit if it did not compile successfully.
 if { ![file_on_host exists "$bname.s"] } {
 # All regular compiles should pass.
 fail "$nshort $options (regular assembly missing)"
 return
 }
>>>
>>> Don't use dg-test, use a new variant of it as is done with the lto,
>>> compat, and profopt tests.  You'll have much more control that way
>>> and can better check the success of individual steps to decide what
>>> to do next.
>>
>> I am having trouble identifying the variant.  Does it have a name,
>> or is it inline code?
>
> I meant that you should write one.  For example, gcc.dg/lto/lto.exp
> uses lto_execute which is defined in lib/lto.exp, and
> gcc.dg/compat/compat.exp uses compat-execute defined in lib/compat.exp.
>
 The complicated part is the compile we are comparing against, which
 required knowing whether or not a compile failure is expected.  For
 that we grep for dg-xfail-if and the appropriate option.

 # Compile a second time using the pph files.
 dg-test -keep-output $test "$options $mapflag -I." ""

 # Quit if it did not compile successfully.
 if { ![file_on_host exists "$bname.s"] } {
 # Expect assembly to be missing when the compile is an expected
 fail.
 if { ![llength [grep $test "dg-xfail-if.*-fpph-map"]] } {
 fail "$nshort $options (pph assembly missing)"
 }
 return
 }
>>>
>>> Relying on the existence of dg-xfail-if won't work when an expected
>>> compilation failure starts working, or an unexpected one arises.
>>
>> If the compilation starts working, I get an assembly file, and
>> continue to assembly comparisons.  If the compilation fails,
>> but with a different error, then the other (typically dg-bogus)
>> directives should report the unexpected failure.  In either case,
>> I think, I get proper notice.  Am I missing something?
>
> I don't fully understand the purpose of grepping for dg-xfail-if.
> You shouldn't care about that within the test, just whether the
> compile succeeded or not.  If there are messages that prevent the
> compile from succeeding, then they should be handled with
> appropriate test directives.

Each .cc file is compiled twice.  First without PPH and then
with PPH.  We compare the assembly generated as a proxy for "did
we compile correctly".  The PPH code is in development, and so
several tests fail when compiled with PPH.  We use the dg-xfail-if
to indicate when we expect the PPH compilation to fail.  The specific
failure is indicated by other directives, usually dg-bogus.
The goal is to ensure that our tests are clean, either all pass
or xfail.

> Apart from that, whether or not a dg-xfail-if directives takes
> effect depends on the target and options used for the test.

Yes, we are counting on that.  All the non-PPH compilations pass,
but only most of the PPH compilations pass.  The others get the
dg-xfail-if.

> Just in case you're 

gcc-4.5-20110609 is now available

[gccadmin]

Snapshot gcc-4.5-20110609 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110609/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 174862

You'll find:

 gcc-4.5-20110609.tar.bz2 Complete GCC

  MD5=028e452f5cc4ea194db7894c631e2660
  SHA1=5da2908065d53b9eb864d3458566532aa6be7bb8

Diffs from 4.5-20110602 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Tracing C++ template instantiations‏

[Nathan Ridge]

> On 06/09/2011 03:48 PM, Jonathan Wakely wrote:
>
> When I'm working on complicated template code and debugging a mixture
> of bugs in my templates and ICEs in g++ caused by my buggy templates I
> sometimes wish I could see a dump of all the templates that the
> compiler is instantiating, so I can see at which point in a
> deeply-nested instantiation things don't happen the way I expected
> them to. With variadic templates in particular it's sometimes hard to
> visualize what's happening to your code.
> 
> Someone else asked for this the other day on gcc-help
> (http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
> I'd take a look at implementing it. It turns out that or class
> templates all that's needed is something like:
> verbatim ("instantiating class template %qT", type)
> in instantiate_class_template_1 in gcc/cp/pt.c
> Presumably it wouldn't be much harder to do the same for function templates.
> 
> Is there something that does this already that I've missed? If I were
> to add a switch like -ftrace-template-instantiation to control this,
> is there any chance of getting it accepted?
> 
> It might be useful if the trace said something like:
> attempting to instantiate foo...
> attempting to instantiate foo::baz ...
> successfully instantiated foo::baz
> failed to instantiate foo
> with nesting to see which instantiations depend on others and to see
> which pass/fail, but I've already found it useful just to see a list
> of instantiations, in order to verify whether some refactoring reduces
> the number of instantiations.
> 
> Would anyone else find this useful, or should I just keep it in my own
> source tree for my own use?

+1 for this feature. I would find it very useful too!

Regards,
Nate.