Reducing fortran testcase with delta.
Hi, I have noticed this wiki:A_guide_to_testcase_reduction which tells how to reduce a c/c++ testcase with delta. That's a really good tool to do this reducing job. And for c/c++ the topformflat tool in the Delta distribution will puts syntactically related tokens on one line (because delta is line granularity), is there the same thing for preprocessing the fortran code? Thanks, Li
Re: Reducing fortran testcase with delta.
Hi Li,
I've attached 'Fortran-aware' delta. I tries to guess cut a Fortran file
in more reasonable places (e.g. between subroutine boundaries, after
enddos). It works reasonably well, but is a hack.
Especially with Fortran90 and modules, iterated delta runs can help a lot
(i.e. first runs removes 'public/use' module statements, next round cleans
more efficiently). It also features 'randomized' bisection. That helps to
reduce towards a minimized testcase when iterating delta runs.
I usually call it with the following script:
cat do_many
for i in `seq 1 30`
do
~/delta-2006.08.03/delta -suffix=.f90 -test=delta.script
-cp_minimal=small.f90 bug.f90
cp small.f90 small.f90.$i
cp small.f90 bug.f90
done
Cheers,
Joost
#!/usr/bin/perl -w
# delta; see License.txt for copyright and terms of use
use strict;
#
# Implementation of the delta debugging algorithm:
# http://www.st.cs.uni-sb.de/dd/
# Daniel S. Wilkerson d...@cs.berkeley.edu
# Notes:
# The test script should not depend on the current directory to work.
# Note that 1-minimality does not imply idempotency, so we could
# re-run once it is stuck, perhaps with some randomization.
# Global State
my @chunks = ();# Once input, is read only.
my @markers = (); # Delimits a dynamic subsequence of @chunks
being considered.
my %test_cache = ();# Cached test results.
# Mark boundaries that uniquely determine the marked contents. This
# is used as a shorter key to hash on than the contents themselves.
# Since Perl hashes retain their keys if you don't do this you get a
# horrible memory leak in the test_cache.
my $mark_signature;
# End of the last marker rendered to the tmp file. Used to figure out
# if the next one abuts it or not.
my $last_mark_stop;
my @current_markers;# Markers to be rendered to $tmpinput if answer
not in cache.
my $tmpinput; # Temporary file to render marked subsequence
to.
my $last_successful_tmpinput; # Last one to past the test.
my $tmp_index = 0; # Cache the last index used to make a tmp file.
my $tmpdir_index = 0; # Cache the last index used to make a tmp
directory.
my $tmpdir; # Temporary directory for external programs.
my $logfile = "log";# File in $tmpdir where log of successful runs
is written.
chomp (my $this_dir = `pwd`); # The current directory.
my $starttime = time; # The time we started.
my $granularity = "line"; # What is the size of an input chunk?
my $dump_input = 0; # Dump out the input after reading it in.
my $cp_minimal; # Copy the minimal successful test to the
current dir.
my $verbose = 0;# Be more verbose.
my $quiet = 0; # Prints go to /dev/null.
my $suffix = ".c"; # For now, our input files are .c files.
my $test; # The script to run as the test.
# when true, all operations on input file are in-place:
# - don't make a new directory
# - overwrite the original input file with our constructed inputs
my $in_place = 0;
my $start_file; # name of input/output file for in_place
my $help_message = <<"END"
Delta version 2003.7.14
delta implements the delta-debugging algorithm:
http://www.st.cs.uni-sb.de/dd/
Implemented by Daniel Wilkerson.
usage: $0 [options] start-file
-test= Specify the test script.
-suffix= Candidate filename suffix [$suffix]
-dump_input Dump input after reading
-cp_minimal= Copy the minimal successful test to the
current directory
-granularity=lineUse lines as the granularity (default)
-granularity=top_formUse C top-level forms as the granularity
(currently only works with CIL output)
-log= Log file for main events
-quiet Say nothing
-verbose Get more verbose output
-in_placeOverwrite start-file with inputs
-helpGet help
The test program accepts a single argument, the name of the candidate
file to test. It is run within a directory containing only that file,
and it can make temporary files/directories in that directory. It
should return zero for a candidate that exhibits the desired property,
and nonzero for one that does not.
Example test program (delta will retain a line containing "foo"):
#!/bin/sh
grep 'foo' <"\$1" >/dev/null
END
;
# Functions
sub output(@) {
print @_ unless $quiet;
}
# Return true if the current_markers pass the interesting test.
sub test {
if (-f "DELTA-STOP") {
output "Stopping because DELTA-STOP file exists\n";
exit 1;
}
my $cached_result = $test_cache{$mark_signature};
if (defined $cached_result) {
output
Re: Reducing fortran testcase with delta.
Hi Joost,
On Fri, Oct 30, 2009 at 4:41 PM, VandeVondele Joost wrote:
> Hi Li,
>
> I've attached 'Fortran-aware' delta. I tries to guess cut a Fortran file in
> more reasonable places (e.g. between subroutine boundaries, after enddos).
> It works reasonably well, but is a hack.
I think another way might be doing like what topformflat did in c/c++
code. Move these lines between {do enddo} or {subroutine} in one line
without breaking into delta. But anyway, your idea is good too and it has
been accomplished!
>
> Especially with Fortran90 and modules, iterated delta runs can help a lot
> (i.e. first runs removes 'public/use' module statements, next round cleans
> more efficiently). It also features 'randomized' bisection. That helps to
> reduce towards a minimized testcase when iterating delta runs.
>
This really helps, I'll try your hacked delta for fortran code.
> I usually call it with the following script:
>
>> cat do_many
>
> for i in `seq 1 30`
> do
> ~/delta-2006.08.03/delta -suffix=.f90 -test=delta.script
> -cp_minimal=small.f90 bug.f90
> cp small.f90 small.f90.$i
> cp small.f90 bug.f90
> done
>
Thanks,
Li
Library ABI seriously broken!!
Hi, sorry if the issue is already well known, but it's so serious that I decided to post an heads up: today (not yesterday), the ABI is broken, the size of many symbols exported by libstdc++ changed, see eg: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02895.html http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02903.html http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02904.html I'm adding below some of the many error messages spilled by abi_check. I *strongly* suspect: 2009-10-28 Jerry Quinn * mangle.c (mangle_type_string_for_rtti): Revert r149964. (needs_fake_anon): Likewise. (write_name): Likewise. (write_nested_name): Likewise. * cp-tree.h (mangle_type_string_for_rtti): Likewise. (get_anonymous_namespace): Likewise. * name-lookup.c (get_anonymous_namespace_name): Likewise. * rtti.c (tinfo_name): Insert '*' in front of private names. (tinfo_base_init): Use it. 2009-10-28 Jerry Quinn * libsupc++/tinfo.cc (operator=(const type_info&)): Compare by pointer if name begins with '*'. * libsupc++/typeinfo (type_info::name()): Likewise. * libsupc++/tinfo2.cc (before): Likewise. Please provide feedback ASAP. Thanks, Paolo. 171 incompatible symbols 0 _ZTSSt18basic_stringstreamIcSt11char_traitsIcESaIcEE typeinfo name for std::basic_stringstream, std::allocator > version status: unversioned type: object type size: 48 status: incompatible sizes 49 48 1 _ZTSSt7codecvtIcc11__mbstate_tE typeinfo name for std::codecvt version status: unversioned type: object type size: 27 status: incompatible sizes 28 27 2 _ZTSSt10moneypunctIwLb0EE typeinfo name for std::moneypunct version status: unversioned type: object type size: 21 status: incompatible sizes 22 21 3 _ZTSSt13basic_fstreamIcSt11char_traitsIcEE typeinfo name for std::basic_fstream > version status: unversioned type: object type size: 38 status: incompatible sizes 39 38 4 _ZTSSt12ctype_bynameIwE typeinfo name for std::ctype_byname version status: unversioned type: object type size: 19 status: incompatible sizes 20 19 5 _ZTSPa typeinfo name for signed char* version status: unversioned type: object type size: 2 status: incompatible sizes 3 2 6 _ZTSSt15underflow_error typeinfo name for std::underflow_error version status: unversioned type: object type size: 19 status: incompatible sizes 20 19 7 _ZTSSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE typeinfo name for std::basic_ostringstream, std::allocator > version status: unversioned type: object type size: 49 status: incompatible sizes 50 49 8 _ZTSSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE typeinfo name for std::money_put > > version status: unversioned type: object type size: 59 status: incompatible sizes 60 59 9 _ZTSSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE typeinfo name for std::num_put > > version status: unversioned type: object type size: 57 status: incompatible sizes 58 57 10 _ZTSPh typeinfo name for unsigned char* version status: unversioned type: object type size: 2 status: incompatible sizes 3 2 11 _ZTSSt13basic_filebufIcSt11char_traitsIcEE typeinfo name for std::basic_filebuf > version status: unversioned type: object type size: 38 status: incompatible sizes 39 38 12 _ZTSs typeinfo name for short version status: unversioned type: object type size: 1 status: incompatible sizes 2 1 13 _ZTSSt8bad_cast typeinfo name for std::bad_cast version status: unversioned type: object type size: 11 status: incompatible sizes 12 11 14 _ZTSPKj typeinfo name for unsigned int const* version status: unversioned type: object type size: 3 status: incompatible sizes 4 3 15 _ZTSPKc typeinfo name for char const* version status: unversioned type: object type size: 3 status: incompatible sizes 4 3 16 _ZTSe typeinfo name for long double version status: unversioned type: object type size: 1 status: incompatible sizes 2 1 17 _ZTSSt14basic_ifstreamIcSt11char_traitsIcEE typeinfo name for std::basic_ifstream > version status: unversioned type: object type size: 39 status: incompatible sizes 40 39 18 _ZTSSt9money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE typeinfo name for std::money_put > > version status: unversioned type: object type size: 59 status: incompatible sizes 60 59 19 _ZTSl typeinfo name for long version status: unversioned type: object type size: 1 status: incompatible sizes 2 1 20 _ZTSSt21__ctype_abstract_baseIcE typeinfo name for std::__ctype_abstract_base version status: unversioned type: object type size: 28 status: incompatible sizes 29 28 21 _ZTSPx typeinfo name for long long* version status: unversioned type: ob
Re: Library ABI seriously broken!!
On Fri, 2009-10-30 at 12:48 +0100, Paolo Carlini wrote: > Hi, > > sorry if the issue is already well known, but it's so serious that I > decided to post an heads up: today (not yesterday), the ABI is broken, > the size of many symbols exported by libstdc++ changed, see eg: > > http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02895.html > http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02903.html > http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02904.html > > I'm adding below some of the many error messages spilled by abi_check. > > I *strongly* suspect: > > 2009-10-28 Jerry Quinn > > * mangle.c (mangle_type_string_for_rtti): Revert r149964. > (needs_fake_anon): Likewise. > (write_name): Likewise. > (write_nested_name): Likewise. > * cp-tree.h (mangle_type_string_for_rtti): Likewise. > (get_anonymous_namespace): Likewise. > * name-lookup.c (get_anonymous_namespace_name): Likewise. > * rtti.c (tinfo_name): Insert '*' in front of private names. > (tinfo_base_init): Use it. Hi, Paolo, I've reverted the patch. This was intended to fix the broken bootstrap under --enable-build-with-cxx. Currently anonymous namespaces get random names so successive builds of the compiler have different binaries when built with C++. The patch marked anonymous namespaces so they could be compared by pointer instead of string allowing removal of the random naming. Obviously a different strategy is needed. I missed the ABI breakage when testing. Sorry for the aggravation. Jerry
Re: Library ABI seriously broken!!
Jerry Quinn wrote: > I've reverted the patch. > Thanks Jerry for your quick feedback. Paolo.
Re: Library ABI seriously broken!!
On Fri, Oct 30, 2009 at 1:54 PM, Paolo Carlini wrote:
> Jerry Quinn wrote:
>> I've reverted the patch.
>>
> Thanks Jerry for your quick feedback.
I think it was just
static tree
-tinfo_name (tree type)
+tinfo_name (tree type, bool mark_private)
{
const char *name;
+ int length;
tree name_string;
- name = mangle_type_string_for_rtti (type);
- name_string = fix_string_type (build_string (strlen (name) + 1, name));
- return name_string;
+ name = mangle_type_string (type);
+ length = strlen (name);
+
+ if (mark_private)
+{
+ /* Inject '*' at beginning of name to force pointer comparison. */
+ char* buf = (char*) XALLOCAVEC (char, length + 1);
+ buf[0] = '*';
+ memcpy (buf + 1, name, length);
+ name_string = build_string (length + 1, buf);
+}
+ else
+name_string = build_string (length, name);
+
+ return fix_string_type (name_string);
where you replaced build_string (strlen (name) + 1, name) with
build_string (strlen (name), name). I don't know if this renders the
ABIs incompatible, but I doubt it - it would be nice to verify that indeed
just extra '\0's are now missing at the end.
Richard.
> Paolo.
>
IRA is not looking into the predicates ?
Hi,
I am doing a port for a 32bit target in GCC 4.4.0. The target does not
have support for symbolic address in QImode for load operations. In
order to do this what i have done is in define_expand for moveqi
reject symbolic address it they come in source operands and i have
also written a predicate for *moveqi_internal to reject such cases.
But i get the following ICE:
insn does not satisfy its constraints:
(insn 24 5 6 2 ice4.c:4 (set (reg:QI 17 r1)
(mem/c/i:QI (symbol_ref:SI ("s") [flags 0x2] ) [0 s+0 S1 A32])) 0 {*movqi_internal} (nil))
>From ice4.c.172r.ira
(insn 24 5 6 2 ice4.c:4 (set (reg:QI 17 r1)
(mem/c/i:QI (symbol_ref:SI ("s") [flags 0x2] ) [0 s+0 S1 A32])) 0 {*movqi_internal} (nil))
(insn 6 24 7 2 ice4.c:4 (set (reg:QI 16 r0 [62])
(plus:QI (reg:QI 17 r1)
(const_int -100 [0xff9c]))) 16 {addqi3} (nil))
>From ice4.c.168r.asmcons
(insn 5 2 6 2 ice4.c:4 (set (reg:SI 61 [ s ])
(mem/c/i:SI (symbol_ref:SI ("s") [flags 0x2] ) [0 s+0 S4 A32])) 2 {*movsi_internal} (nil))
(insn 6 5 7 2 ice4.c:4 (set (reg:QI 62)
(plus:QI (subreg:QI (reg:SI 61 [ s ]) 0)
(const_int -100 [0xff9c]))) 16 {addqi3}
(expr_list:REG_DEAD (reg:SI 61 [ s ])
(nil)))
How can i prevent this ICE ?
Regards,
Shafi
Re: Library ABI seriously broken!!
Richard Guenther wrote: > where you replaced build_string (strlen (name) + 1, name) with > build_string (strlen (name), name). I don't know if this renders the > ABIs incompatible, but I doubt it - it would be nice to verify that indeed > just extra '\0's are now missing at the end. > To be clear: if knowledgeable people can confirm this kind of reasoning, of course I have no objections, but then abi_check must be also fixed at the same time, nothing should committed leading to regressions, either substantive or only apparent. Paolo.
Re: Library ABI seriously broken!!
On Fri, Oct 30, 2009 at 2:15 PM, Paolo Carlini wrote: > Richard Guenther wrote: >> where you replaced build_string (strlen (name) + 1, name) with >> build_string (strlen (name), name). I don't know if this renders the >> ABIs incompatible, but I doubt it - it would be nice to verify that indeed >> just extra '\0's are now missing at the end. >> > To be clear: if knowledgeable people can confirm this kind of reasoning, > of course I have no objections, but then abi_check must be also fixed at > the same time, nothing should committed leading to regressions, either > substantive or only apparent. I fully agree with you here. A simple solution is to re-instantiate the +1 (with a comment before it). Richard.
RFC PRE-ing REFERENCE expressions
Hi Richi,
Following up your suggestion on PR41488, I am continuing to test with
loop header copy before FRE in GCC 4.4.1. One regression I am trying
to tackle is from the test case below.
typedef struct {
int degree;
int c[(256)];
} swbcht_Polynomial;
typedef struct {
int m;
int n;
const swbcht_Polynomial *primPoly;
unsigned short alpha[(1 << (13))];
} swbcht_GF;
typedef struct {
swbcht_GF gf;
} swbcht_Handle;
static const swbcht_Polynomial _primPoly13;
void _ComputeGFLookupTables (swbcht_Handle *bchH, int m)
{
int i, j;
swbcht_GF *gf = &bchH->gf;
gf->m = m;
gf->n = (1 << m) - 1;
gf->primPoly = &_primPoly13;
for (i = 0; i < gf->m; i++) {
gf->alpha[gf->m] ^= (gf->primPoly->c[i] * gf->alpha[i]);
}
}
The dump after CH - FRE looks like
_ComputeGFLookupTables (struct swbcht_Handle * bchH, int m)
{
int i;
short unsigned int D.1241;
short int D.1240;
short int D.1239;
short unsigned int D.1238;
short unsigned int D.1237;
short unsigned int D.1236;
const int D.1235;
const struct swbcht_Polynomial * D.1233;
short int D.1232;
short unsigned int D.1231;
int D.1230;
int D.1229;
int D.1228;
:
bchH_2(D)->gf.m = m_4(D);
D.1228_5 = 1 << m_4(D);
D.1229_6 = D.1228_5 + -1;
bchH_2(D)->gf.n = D.1229_6;
bchH_2(D)->gf.primPoly = &_primPoly13;
if (m_4(D) > 0)
goto ;
else
goto ;
:
goto ;
:
:
# i_35 = PHI <0(5), i_23(7)>
D.1230_10 = bchH_2(D)->gf.m;
D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
D.1232_12 = (short int) D.1231_11;
D.1233_13 = bchH_2(D)->gf.primPoly;
D.1235_15 = D.1233_13->c[i_35];
D.1236_16 = (short unsigned int) D.1235_15;
D.1237_18 = bchH_2(D)->gf.alpha[i_35];
D.1238_19 = D.1236_16 * D.1237_18;
D.1239_20 = (short int) D.1238_19;
D.1240_21 = D.1239_20 ^ D.1232_12;
D.1241_22 = (short unsigned int) D.1240_21;
bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
i_23 = i_35 + 1;
D.1230_8 = bchH_2(D)->gf.m;
if (i_23 < D.1230_8)
goto ;
else
goto ;
:
goto ;
:
:
return;
}
1. Why does FRE miss eliminating expression bchH_2(D)->gf.primPoly in
bb 3 with &_primPoly13. This is normally the case if we ran FRE then
CH.
Further PRE identifies bchH_2(D)->gf.primPoly as a partially redundant
expression and hoists it into predecessor bb 7 and we get
:
# i_35 = PHI <0(5), i_23(7)>
# prephitmp.25_49 = PHI
# prephitmp.27_51 = PHI <&_primPoly13(5), pretmp.26_50(7)>
D.1230_10 = prephitmp.25_49;
D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
D.1232_12 = (short int) D.1231_11;
D.1233_13 = prephitmp.27_51;
D.1235_15 = D.1233_13->c[i_35];
D.1236_16 = (short unsigned int) D.1235_15;
D.1237_18 = bchH_2(D)->gf.alpha[i_35];
D.1238_19 = D.1236_16 * D.1237_18;
D.1239_20 = (short int) D.1238_19;
D.1240_21 = D.1239_20 ^ D.1232_12;
D.1241_22 = (short unsigned int) D.1240_21;
bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
i_23 = i_35 + 1;
D.1230_8 = bchH_2(D)->gf.m;
if (D.1230_8 > i_23)
goto ;
else
goto ;
:
pretmp.26_50 = bchH_2(D)->gf.primPoly;
goto ;
Clearly prephitmp.27_51 will make a redundant induction variable.
Stepping through the insert_into_preds_of_block in tree-ssa-pre.c
I can see the value numbers for expression bchH_2(D)->gf.primPoly
available through bb 3 and through bb 2 are different.
2. Is this because alias analysis cannot determine bchH_2(D)->gf
has a unique target?
Many Thanks,
Rahul
Re: RFC PRE-ing REFERENCE expressions
On Fri, Oct 30, 2009 at 3:22 PM, Rahul Kharche wrote:
> Hi Richi,
>
> Following up your suggestion on PR41488, I am continuing to test with
> loop header copy before FRE in GCC 4.4.1. One regression I am trying
> to tackle is from the test case below.
>
> typedef struct {
> int degree;
> int c[(256)];
> } swbcht_Polynomial;
>
>
> typedef struct {
> int m;
> int n;
> const swbcht_Polynomial *primPoly;
> unsigned short alpha[(1 << (13))];
> } swbcht_GF;
>
>
> typedef struct {
> swbcht_GF gf;
> } swbcht_Handle;
>
>
> static const swbcht_Polynomial _primPoly13;
>
> void _ComputeGFLookupTables (swbcht_Handle *bchH, int m)
> {
> int i, j;
>
> swbcht_GF *gf = &bchH->gf;
>
> gf->m = m;
> gf->n = (1 << m) - 1;
>
> gf->primPoly = &_primPoly13;
>
> for (i = 0; i < gf->m; i++) {
> gf->alpha[gf->m] ^= (gf->primPoly->c[i] * gf->alpha[i]);
> }
> }
>
>
> The dump after CH - FRE looks like
>
> _ComputeGFLookupTables (struct swbcht_Handle * bchH, int m)
> {
> int i;
> short unsigned int D.1241;
> short int D.1240;
> short int D.1239;
> short unsigned int D.1238;
> short unsigned int D.1237;
> short unsigned int D.1236;
> const int D.1235;
> const struct swbcht_Polynomial * D.1233;
> short int D.1232;
> short unsigned int D.1231;
> int D.1230;
> int D.1229;
> int D.1228;
>
> :
> bchH_2(D)->gf.m = m_4(D);
> D.1228_5 = 1 << m_4(D);
> D.1229_6 = D.1228_5 + -1;
> bchH_2(D)->gf.n = D.1229_6;
> bchH_2(D)->gf.primPoly = &_primPoly13;
> if (m_4(D) > 0)
> goto ;
> else
> goto ;
>
> :
> goto ;
>
> :
>
> :
> # i_35 = PHI <0(5), i_23(7)>
> D.1230_10 = bchH_2(D)->gf.m;
> D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
> D.1232_12 = (short int) D.1231_11;
> D.1233_13 = bchH_2(D)->gf.primPoly;
> D.1235_15 = D.1233_13->c[i_35];
> D.1236_16 = (short unsigned int) D.1235_15;
> D.1237_18 = bchH_2(D)->gf.alpha[i_35];
> D.1238_19 = D.1236_16 * D.1237_18;
> D.1239_20 = (short int) D.1238_19;
> D.1240_21 = D.1239_20 ^ D.1232_12;
> D.1241_22 = (short unsigned int) D.1240_21;
> bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
> i_23 = i_35 + 1;
> D.1230_8 = bchH_2(D)->gf.m;
> if (i_23 < D.1230_8)
> goto ;
> else
> goto ;
>
> :
> goto ;
>
> :
>
> :
> return;
>
> }
>
> 1. Why does FRE miss eliminating expression bchH_2(D)->gf.primPoly in
> bb 3 with &_primPoly13. This is normally the case if we ran FRE then
> CH.
>
> Further PRE identifies bchH_2(D)->gf.primPoly as a partially redundant
> expression and hoists it into predecessor bb 7 and we get
>
> :
> # i_35 = PHI <0(5), i_23(7)>
> # prephitmp.25_49 = PHI
> # prephitmp.27_51 = PHI <&_primPoly13(5), pretmp.26_50(7)>
> D.1230_10 = prephitmp.25_49;
> D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
> D.1232_12 = (short int) D.1231_11;
> D.1233_13 = prephitmp.27_51;
> D.1235_15 = D.1233_13->c[i_35];
> D.1236_16 = (short unsigned int) D.1235_15;
> D.1237_18 = bchH_2(D)->gf.alpha[i_35];
> D.1238_19 = D.1236_16 * D.1237_18;
> D.1239_20 = (short int) D.1238_19;
> D.1240_21 = D.1239_20 ^ D.1232_12;
> D.1241_22 = (short unsigned int) D.1240_21;
> bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
> i_23 = i_35 + 1;
> D.1230_8 = bchH_2(D)->gf.m;
> if (D.1230_8 > i_23)
> goto ;
> else
> goto ;
>
> :
> pretmp.26_50 = bchH_2(D)->gf.primPoly;
> goto ;
>
>
> Clearly prephitmp.27_51 will make a redundant induction variable.
> Stepping through the insert_into_preds_of_block in tree-ssa-pre.c
> I can see the value numbers for expression bchH_2(D)->gf.primPoly
> available through bb 3 and through bb 2 are different.
>
> 2. Is this because alias analysis cannot determine bchH_2(D)->gf
> has a unique target?
You should move to GCC 4.5 - the alias-oracle in GCC 4.4 is too weak
to discover all this and virtual operands are not helpful because these
are all indirect accesses through pointers without points-to information.
Richard.
>
> Many Thanks,
> Rahul
>
>
Re: IRA is not looking into the predicates ?
Mohamed Shafi writes:
>>From ice4.c.168r.asmcons
>
> (insn 5 2 6 2 ice4.c:4 (set (reg:SI 61 [ s ])
> (mem/c/i:SI (symbol_ref:SI ("s") [flags 0x2] 0xb7bfd000 s>) [0 s+0 S4 A32])) 2 {*movsi_internal} (nil))
>
> (insn 6 5 7 2 ice4.c:4 (set (reg:QI 62)
> (plus:QI (subreg:QI (reg:SI 61 [ s ]) 0)
> (const_int -100 [0xff9c]))) 16 {addqi3}
> (expr_list:REG_DEAD (reg:SI 61 [ s ])
> (nil)))
>
> How can i prevent this ICE ?
If asmcons is the first place that this appears, then I think it must
be coming from some asm statement. So the first step would be to look
at the asm statement and see if it can be rewritten using a different
constraint.
Ian
Re: IRA is not looking into the predicates ?
On 10/30/09 07:13, Mohamed Shafi wrote: Hi, I am doing a port for a 32bit target in GCC 4.4.0. The target does not have support for symbolic address in QImode for load operations. You'll need to make sure to reject such addresses for QImode in GO_IF_LEGITIMATE_ADDRESS. In order to do this what i have done is in define_expand for moveqi reject symbolic address it they come in source operands and i have also written a predicate for *moveqi_internal to reject such cases. OK. Nothing wrong with these steps. Though you really need to make sure GO_IF_LEGITIMATE_ADDRESS is defined correctly. IRA doesn't look at operand predicates or insn conditions. It assumes that any insns are valid assuming any pseudo registers appearing in the insn get suitable hard registers. Based on the dumps you provided it appears that reg61 does not get a hard register and reload is generating the problematical insn #24. This is a good indication that your GO_IF_LEGITIMATE_ADDRESS is incorrectly implemented. jeff
Re: Library ABI seriously broken!!
On 10/30/2009 09:20 AM, Richard Guenther wrote: On Fri, Oct 30, 2009 at 2:15 PM, Paolo Carlini wrote: Richard Guenther wrote: where you replaced build_string (strlen (name) + 1, name) with build_string (strlen (name), name). I don't know if this renders the ABIs incompatible, but I doubt it - it would be nice to verify that indeed just extra '\0's are now missing at the end. To be clear: if knowledgeable people can confirm this kind of reasoning, of course I have no objections, but then abi_check must be also fixed at the same time, nothing should committed leading to regressions, either substantive or only apparent. I fully agree with you here. A simple solution is to re-instantiate the +1 (with a comment before it). Yes, the +1 does seem to be needed, my mistake. Jason
[RFC] md reorg plans for 4.6?
Hi all, with the new plugin infrastructure, it makes sense to replace the one-catches-all md reorg pass with target-specific passes plugged into the pass manager. If the md reorg is doing just complex peephole optimizations that cannot be achieved with targets, that's fine. This has the advantage of being able to move passes where they really belong. Many targets could benefit: - Blackfin, IA64 and picochip is doing clever tricks to move splitting, sched2 and vartracking in the middle of its reorg - MEP doesn't do the same tricks with vartracking, but also requires dataflow - MIPS also could be split in several passes with nice dumps, eliminating crtl->dbr_scheduled_p which is there just to place delay-slot scheduling in the middle of md reorg - i386... md reorg is sane and it is already doing plugin-style pass registration... but what about moving reg-stack.c to config/i386? :-) - the split passes are a mess and some targets split again at the beginning of reorg -- having separate dumps would be nice (s390) - there's also M68HC11 and SH... well, I doubt there will be volunteers. - for SPU, there is an additional scheduling pass done as part of md_reorg; again, splitting dumps would be nice and in addition I wonder if doing sched2+this pass is really necessary if more pass placement freedom is given to the backend. At the same time, it would be nice to free the CFG only for targets that absolutely abhor it (doing so in their own md reorg pass) rather than doing it for all targets. Paolo
Re: Reducing fortran testcase with delta.
Sent from my iPhone On Oct 30, 2009, at 1:08 AM, Li Feng wrote: Hi, I have noticed this wiki:A_guide_to_testcase_reduction which tells how to reduce a c/c++ testcase with delta. That's a really good tool to do this reducing job. And for c/c++ the topformflat tool in the Delta distribution will puts syntactically related tokens on one line (because delta is line granularity), is there the same thing for preprocessing the fortran code? Not really but fortran is normally already line based so running delta on it just works. Just remember to delete *.mod between each run. Thanks, Li
Re: Library ABI seriously broken!!
Jason Merrill wrote: > Yes, the +1 does seem to be needed, my mistake. Thanks. So I went ahead and reapplied the patch with the +1 fixed, after having double checked that the testsuites are now fine. Paolo.
Re: [RFC] md reorg plans for 4.6?
Paolo Bonzini writes: > with the new plugin infrastructure, it makes sense to replace the > one-catches-all md reorg pass with target-specific passes plugged into > the pass manager. Yes, please. > - there's also M68HC11 and SH... well, I doubt there will be volunteers. But note that, e.g., bt-load.c looks like a generic file but is actually SH specific, so moving it into config/sh will be an improvement for everybody. Ian
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
Kaveh R. GHAZI wrote: A prerelease tarball of the upcoming mpc-0.8 is available here: http://www.multiprecision.org/mpc/download/mpc-0.8-dev.tar.gz This release is feature complete with respect to C99 and GCC's needs. So I expect to make this version be the one made mandatory for the gcc-4.5 release. If there are any remaining bugs especially portability problems to GCC's primary or secondary platforms, I'd like to get those reported and fixed before this release is final. Please test this MPC package and report back the results of running "make check" along with your target triplet, the compiler version you used, and the versions of gmp/mpfr used to compile it. You do not necessarily need to bootstrap mainline GCC with this MPC, but if you have the spare time and cycles it would be nice too. Thanks, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu I'm on MacOSX 10.3 MacOSX:~/Tarballs/mpc-0.8-dev ed$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) The -Werror kills it. This warning is familiar. MacOSX:~/Tarballs/mpc-0.8-dev ed$ make make all-recursive make[1]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev' Making all in src make[2]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..-pedantic -Wno-long-long -Wall -Werror -O2 -pedantic -mpowerpc -no-cpp-precomp -force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP -MF .deps/abs.Tpo -c -o abs.lo abs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -pedantic -Wno-long-long -Wall -Werror -O2 -pedantic -mpowerpc -no-cpp-precomp -force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP -MF .deps/abs.Tpo -c abs.c -fno-common -DPIC -o .libs/abs.o In file included from mpc-impl.h:33, from abs.c:22: mpc.h:148: warning: use of `long double' type; its size may change in a future release mpc.h:148: warning: (Long double usage is reported only once for each file. mpc.h:148: warning: To disable this warning, use -Wno-long-double.) make[2]: *** [abs.lo] Error 1 make[2]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev' make: *** [all] Error 2
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
Ed Smith-Rowland wrote: Kaveh R. GHAZI wrote: A prerelease tarball of the upcoming mpc-0.8 is available here: http://www.multiprecision.org/mpc/download/mpc-0.8-dev.tar.gz This release is feature complete with respect to C99 and GCC's needs. So I expect to make this version be the one made mandatory for the gcc-4.5 release. If there are any remaining bugs especially portability problems to GCC's primary or secondary platforms, I'd like to get those reported and fixed before this release is final. Please test this MPC package and report back the results of running "make check" along with your target triplet, the compiler version you used, and the versions of gmp/mpfr used to compile it. You do not necessarily need to bootstrap mainline GCC with this MPC, but if you have the spare time and cycles it would be nice too. Thanks, --Kaveh -- Kaveh R. Ghazigh...@caip.rutgers.edu I'm on MacOSX 10.3 MacOSX:~/Tarballs/mpc-0.8-dev ed$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) The -Werror kills it. This warning is familiar. MacOSX:~/Tarballs/mpc-0.8-dev ed$ make make all-recursive make[1]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev' Making all in src make[2]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..-pedantic -Wno-long-long -Wall -Werror -O2 -pedantic -mpowerpc -no-cpp-precomp -force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP -MF .deps/abs.Tpo -c -o abs.lo abs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -pedantic -Wno-long-long -Wall -Werror -O2 -pedantic -mpowerpc -no-cpp-precomp -force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP -MF .deps/abs.Tpo -c abs.c -fno-common -DPIC -o .libs/abs.o In file included from mpc-impl.h:33, from abs.c:22: mpc.h:148: warning: use of `long double' type; its size may change in a future release mpc.h:148: warning: (Long double usage is reported only once for each file. mpc.h:148: warning: To disable this warning, use -Wno-long-double.) make[2]: *** [abs.lo] Error 1 make[2]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev' make: *** [all] Error 2 Once I deleted -Werror out of the makefiles... === All 57 tests passed === I don't know how you would tweak the configure to kill this -Werror for mac but that would do it. Ed
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
Kaveh R. GHAZI wrote: > Please test this MPC package and report back the results of running > "make check" along with your target triplet, the compiler version you > used, and the versions of gmp/mpfr used to compile it. === All 57 tests passed === i686-pc-cygwin gcc version 4.3.4 20090804 (release) 1 (GCC) Cygwin Package Information Package Version gmp 4.3.1-3 mpfr 2.4.1-4 > You do not > necessarily need to bootstrap mainline GCC with this MPC, but if you > have the spare time and cycles it would be nice too. I didn't, I'm afraid, sorry. cheers, DaveK
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: "Ed Smith-Rowland" <3dw...@verizon.net> I'm on MacOSX 10.3 MacOSX:~/Tarballs/mpc-0.8-dev ed$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) The -Werror kills it. Once I deleted -Werror out of the makefiles... === All 57 tests passed === I don't know how you would tweak the configure to kill this -Werror for mac but that would do it. The -Werror flag will not be used in the final release, so it should work for you. Thanks for testing. --Kaveh
