Re: Possible wrong-way example in gcc4-4-2 documentation of __builtin_expect
The online docs at http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Other-Builtins.html has a confusing (to me) example of __builtin_expect. Could someone take a look at this? Since you are limited to integral expressions for exp, you should use constructions such as if (__builtin_expect (ptr != NULL, 1)) error (); This seems backwards.The return value of __builtin_expect is the first argument, namely (ptr != NULL), which presumably is true in the NON-error case. The following example might be more helpful: if (__builtin_expect (ptr == NULL, 0)) error (); Apologies if I'm not reading this correctly. The point of the example is that you cannot write if (__builtin_expect (ptr, 1)) error (); so the "!= NULL" is important here. But you are right that "error ()" is a bit unexpected; care to send a patch that changes it to e.g. "do_something ()"? Segher
Re: Possible wrong-way example in gcc4-4-2 documentation of __builtin_expect
On 20 December 2011 12:49, Segher Boessenkool wrote: > > The point of the example is that you cannot write > > if (__builtin_expect (ptr, 1)) > error (); > > so the "!= NULL" is important here. But you are right that > "error ()" is a bit unexpected; care to send a patch that changes > it to e.g. "do_something ()"? or even ptr->do_something() since that would depend on the value of ptr
Help with generating 'memset' for loop initialization
Hello All,
With the code given below, i expected the ppc compiler (e500mc v4.6.2)
to generate 'memset' zero call for loop initialization (at '-O3'),
but it generates a loop.
Case:1
int a[18], b[18];
foo () {
int i;
for (i=0; i < 18; i++)
a[i] = 0;
}
Also based on the '-ftree-loop-distribute-patterns' flag, if the test
case (taken from gcc doc) is as shown below, the compiler does
generate 'memset' zero.
Case:2
int a[18], b[18];
foo () {
int i;
for (i=0; i < 18; i++) {
a[i] = 0; -(A)
b[i] = a[i] + i; -(B)
}
}
Here statements (A) and (B) are split in to two loops and for the 1st
loop the compiler generates 'memset' zero call. Isn't the same
optimization supposed to happen with case (1)?
Also with case(2) statement (A), for loop iterations < 18, the
compiler unrolls the loop and for iterations >= 18, 'memset' zero is
generated.
Looking at 'gcc/tree-loop-distribution.c' file,
static int
ldist_gen (struct loop *loop, struct graph *rdg,
VEC (int, heap) *starting_vertices)
{
...
BITMAP_FREE (processed);
nbp = VEC_length (bitmap, partitions);
if (nbp <= 1
|| partition_contains_all_rw (rdg, partitions))
goto ldist_done;
(Z)
if (dump_file && (dump_flags & TDF_DETAILS))
dump_rdg_partitions (dump_file, partitions);
FOR_EACH_VEC_ELT (bitmap, partitions, i, partition)
if (!generate_code_for_partition (loop, partition, i < nbp - 1))
---(Y) // code for generating built-in
'memset' is called from here.
goto ldist_done;
rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
update_ssa (TODO_update_ssa_only_virtuals | TODO_update_ssa);
ldist_done:
BITMAP_FREE (remaining_stmts);
.
return nbp;
}
>From statement (Z), if the no of distributed loops is <=1 , then the
code generating built-in function (Y) is not executed.
Is it a good solution to update this conditional check for single loop
(which is not split) also? or Is there any other place/pass where we
can implement this.
Regards,
Rohit
Misleading error if the type in catch() is ambiguous
Dear All,
I suspect there is a regression from g++ 4.4 in later versions. If the
name of the class is ambiguous in a catch(), this fact is not reported.
I had checked bz, but not found this particular case:
http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=ambiguous
Attached a simple test case. The lines of the errors are:
31: ambiguous parent class
37: ambiguous type name for variable
43: ambiguous type name for caught exception
I tested on an amd64 machine with Debian Wheezy, stock gcc-4.4, 4.5, 4.6
and 4.7 built from the svn trunk:
$g++-4.4 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-14'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.6 (Debian 4.4.6-14)
$g++-4.4 -c test_gccexbug.cpp
test_gccexbug.cpp:31: error: reference to ‘ex2’ is ambiguous
test_gccexbug.cpp:17: error: candidates are: class ex2
test_gccexbug.cpp:11: error: class t::ex2
test_gccexbug.cpp:31: error: reference to ‘ex2’ is ambiguous
test_gccexbug.cpp:17: error: candidates are: class ex2
test_gccexbug.cpp:11: error: class t::ex2
test_gccexbug.cpp: In function ‘void bar()’:
test_gccexbug.cpp:37: error: reference to ‘ex2’ is ambiguous
test_gccexbug.cpp:17: error: candidates are: class ex2
test_gccexbug.cpp:11: error: class t::ex2
test_gccexbug.cpp:37: error: reference to ‘ex2’ is ambiguous
test_gccexbug.cpp:17: error: candidates are: class ex2
test_gccexbug.cpp:11: error: class t::ex2
test_gccexbug.cpp:37: error: expected ‘;’ before ‘x’
test_gccexbug.cpp:43: error: reference to ‘ex2’ is ambiguous
test_gccexbug.cpp:17: error: candidates are: class ex2
test_gccexbug.cpp:11: error: class t::ex2
test_gccexbug.cpp:43: error: expected type-specifier before ‘ex2’
test_gccexbug.cpp:43: error: expected ‘)’ before ‘&’ token
test_gccexbug.cpp:43: error: expected ‘{’ before ‘&’ token
test_gccexbug.cpp:43: error: expected primary-expression before ‘)’ token
test_gccexbug.cpp:43: error: expected ‘;’ before ‘)’ token
Note: ambiguity errors are reported twice for lines 31 and 37 and once
for line 43.
$g++-4.5 -v
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.3/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.3-9'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-gold --enable-ld=default --with-plugin-ld=ld.gold
--enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.3 (Debian 4.5.3-9)
$g++-4.5 -c test_gccexbug.cpp
test_gccexbug.cpp:31:27: error: reference to ‘ex2’ is ambiguous
test_gccexbug.cpp:17:1: error: candidates are: class ex2
test_gccexbug.cpp:11:1: error: class t::ex2
test_gccexbug.cpp: In function ‘void bar()’:
test_gccexbug.cpp:37:7: error: reference to ‘ex2’ is ambiguous
test_gccexbug.cpp:17:1: error: candidates are: class ex2
test_gccexbug.cpp:11:1: error: class t::ex2
test_gccexbug.cpp:37:11: error: expected ‘;’ before ‘x’
test_gccexbug.cpp:43:17: error: expected type-specifier before ‘ex2’
test_gccexbug.cpp:43:20: error: expected ‘)’ before ‘&’ token
test_gccexbug.cpp:43:20: error: expected ‘{’ before ‘&’ token
test_gccexbug.cpp:43:21: error: expected primary-expression before ‘)’ token
test_gccexbug.cpp:43:21: error: expected ‘;’ before ‘)’ token
Note: ambiguity is reported once for lines 31 and 37, and no ambiguity
is reported for line 43. The error is misleading imho, because it
suggests that the type name is not know instead of being ambiguous.
I suspect that the fix that removed the duplicate ambiguity messages
might have gone a bit too far in the case of the catch(), though I
couldn't check this since I'm not familiar with the gcc source.
gcc-4.6 and gcc-4.7 (built from the svn trunk, r182460) give the same
error as gcc-4.5 above.
Regards, Peter
// te
Re: Help with generating 'memset' for loop initialization
On Tue, Dec 20, 2011 at 2:23 PM, Rohit Arul Raj wrote:
> Hello All,
>
> With the code given below, i expected the ppc compiler (e500mc v4.6.2)
> to generate 'memset' zero call for loop initialization (at '-O3'),
> but it generates a loop.
>
> Case:1
>
> int a[18], b[18];
> foo () {
> int i;
>
> for (i=0; i < 18; i++)
> a[i] = 0;
> }
>
> Also based on the '-ftree-loop-distribute-patterns' flag, if the test
> case (taken from gcc doc) is as shown below, the compiler does
> generate 'memset' zero.
>
> Case:2
>
> int a[18], b[18];
> foo () {
> int i;
>
> for (i=0; i < 18; i++) {
> a[i] = 0; -(A)
> b[i] = a[i] + i; -(B)
> }
> }
>
> Here statements (A) and (B) are split in to two loops and for the 1st
> loop the compiler generates 'memset' zero call. Isn't the same
> optimization supposed to happen with case (1)?
>
> Also with case(2) statement (A), for loop iterations < 18, the
> compiler unrolls the loop and for iterations >= 18, 'memset' zero is
> generated.
>
> Looking at 'gcc/tree-loop-distribution.c' file,
>
> static int
> ldist_gen (struct loop *loop, struct graph *rdg,
> VEC (int, heap) *starting_vertices)
> {
> ...
> BITMAP_FREE (processed);
> nbp = VEC_length (bitmap, partitions);
>
> if (nbp <= 1
> || partition_contains_all_rw (rdg, partitions))
> goto ldist_done;
> (Z)
>
> if (dump_file && (dump_flags & TDF_DETAILS))
> dump_rdg_partitions (dump_file, partitions);
>
> FOR_EACH_VEC_ELT (bitmap, partitions, i, partition)
> if (!generate_code_for_partition (loop, partition, i < nbp - 1))
> ---(Y) // code for generating built-in
> 'memset' is called from here.
> goto ldist_done;
>
> rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
> update_ssa (TODO_update_ssa_only_virtuals | TODO_update_ssa);
>
> ldist_done:
>
> BITMAP_FREE (remaining_stmts);
>
> .
> return nbp;
> }
>
> From statement (Z), if the no of distributed loops is <=1 , then the
> code generating built-in function (Y) is not executed.
>
> Is it a good solution to update this conditional check for single loop
> (which is not split) also? or Is there any other place/pass where we
> can implement this.
Well, at least we do not want to create any code if the builtin code
generation would fail.
Richard.
> Regards,
> Rohit
Re: Misleading error if the type in catch() is ambiguous
On 20 December 2011 13:31, Peter A. Felvegi wrote: > > I suspect there is a regression from g++ 4.4 in later versions. If the name > of the class is ambiguous in a catch(), this fact is not reported. Bugs should be reported to bugzilla: http://gcc.gnu.org/bugs/#report Please also provide a reduced testcase that demonstrates only the actual problem, not lots of other error messages that are expected (it's harder to see at a glance whether the behaviour is correct when there are several lines of correct errors.) Thanks.
Re: Misleading error if the type in catch() is ambiguous
I've submitted a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640 Regards, Peter
gcc-4.4-20111220 is now available
Snapshot gcc-4.4-20111220 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20111220/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 182554 You'll find: gcc-4.4-20111220.tar.bz2 Complete GCC MD5=9e5d9c36079dac7470862cf687ad6ad1 SHA1=e039a558f46e685f680a87257af36d98833c63fd Diffs from 4.4-20111213 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: Modifying the datatype of a formal parameter
Here is a follow up. I am closer to what I need, but not quite there yet. Basically I just want to switch the type of one formal parameter to a different type. On Mon, Dec 19, 2011 at 11:05 PM, Matt Davis wrote: > Hi Martin and thank you very much for your reply. I do have some more > resolution to my issue. > > On Mon, Dec 19, 2011 at 8:42 PM, Martin Jambor wrote: >> Hi, >> >> On Sun, Dec 18, 2011 at 01:57:17PM +1100, Matt Davis wrote: >>> I am using 'ipa_modify_formal_parameters()' to change the type of a >>> function's >>> formal parameter. After my pass completes, I get a 'gimple_expand_cfg()' >>> error. I must be missing some key piece here, as the failure points to a >>> NULL >>> "SA.partition_to_pseudo" value. I also set_default_ssa_name() on the >>> returned >>> value from ipa_modify_formal_parameter (the adjustment's 'reduction' >>> field). Do >>> I need to re-gimplify the function or run some kind of 'cleanup' or 'update' >>> once I modify this formal parameter? >> >> It's difficult to say without knowing what and at what stage of the >> compilation you are doing. > > My pass is getting called as the last IPA pass > (PLUGIN_ALL_IPA_PASSES_END). I do use the same function > "ipa_modify_formal_parameters()" to add additional parameters to > certain functions. And it works well. > >> The sad truth is that >> ipa_modify_formal_parameters is very much crafted for its sole user >> which is IPA-SRA and is probably quite less general than what the >> original intention was. Any pass using the function then must modify >> the body itself to reflect the changes, just like IPA-SRA does. >> >> SRA does not re-gimplify the modify functions, it just returns >> TODO_update_ssa or (TODO_update_ssa | TODO_cleanup_cfg) if any EH >> cleanup changed the CFG. > > Yep, and I do call update_ssa and cleanup_tree_cfg() after my pass. > >> So I would suggest to have a look at IPA-SRA (grep for the only call >> to ipa_modify_formal_parameters in tree-sra.c), especially at what you >> do differently. If you then have any further questions, feel free to >> ask. > > Yeah, that was one of the first things I did. Now, as mentioned, I > do have some more clarity on my issue. Basically, I am just changing > the type of an existing formal parameter. When I look at > "gimple_expand_cfg()" which is called later, I notice that the > "SA.partition_to_pseudo" for that parameter is NULL, to which > "gimple_expand_cfg()" aborts() on. Now, that value is NULL, because > in "gimple_expand_cfg()" the function "expand_used_vars()" is called. > I need "expand_one_var()" called since that should fix-up the RTX > assigned to the parameter I am modifying. Unfortunately, the bitmap, > "SA.partition_has_default_def" is true for the parameter, even if I do > not set it explicitly. And since it is always set, the > "expand_one_var()" routine is never called. I need to unset the > default def associated to the param to force "expand_one_var()" to > execute. So, for the ssa name assigned to the parameter I am > modifying, I use SSA_NAME_IS_DEFAULT_DEF to set the flag to 'false' > This sounds like a really gross hack. If I do this, I will need to > set a new ssa definition for the modified parameter. I use ipa_modify_formal_paramaters() and swap the type of the param with that of my desired type. The resulting PARM_DECL that the latter function gives me has no default definition. So, I use make_ssa_name() and set the return of that to the default definition for the PARM_DECL. That works fine, however I need to somehow rebuild the SSANAMES for the function. So, the new name I have for the modified PARAM_DECL is out of order and gimple_expand_cfg() fails, because the new definition of the PARM_DECL is now of order for SA,partition_to_pseudo, when gimple_expand_cfg() is called. Since the partition-to-pseudo stuff works based on the index of where the SSA_NAME is in the functions list of SSANAMES. gimple_expand_cfg() works by iterating across all SSANAMEs including the one I no longer need. What I need to do is replace the old SSA_NAME with the newer SSA_NAME I get back from make_ssa_name(). I could do this directly, but I have yet to find an appropriate routine in tree-flow.h and tree-flow-inline.h -Matt
Re: Possible wrong-way example in gcc4-4-2 documentation of __builtin_expect
Ok, here is a patch which improves the example: --- gcc/doc/extend.texi.ORIG 2011-12-20 17:35:32.236578828 -0800 +++ gcc/doc/extend.texi 2011-12-20 17:37:10.460583316 -0800 @@ -7932,7 +7932,7 @@ @smallexample if (__builtin_expect (ptr != NULL, 1)) - error (); + ptr->do_something(); @end smallexample @noindent From: Jonathan Wakely To: Segher Boessenkool Cc: james_av...@yahoo.com; gcc@gcc.gnu.org Sent: Tuesday, December 20, 2011 5:22 AM Subject: Re: Possible wrong-way example in gcc4-4-2 documentation of __builtin_expect On 20 December 2011 12:49, Segher Boessenkool wrote: > > The point of the example is that you cannot write > > if (__builtin_expect (ptr, 1)) > error (); > > so the "!= NULL" is important here. But you are right that > "error ()" is a bit unexpected; care to send a patch that changes > it to e.g. "do_something ()"? or even ptr->do_something() since that would depend on the value of ptr
Which Binutils should I use for performing daily regression test on trunk?
Hi, I plan to set up daily regression test on trunk for target ARM-NONE-EABI and post results to gcc-testresults mailing list. Which Binutils should I use, the Binutils trunk or the latest released Binutils? And which way is recommended, building from a combined tree or building separately? If there is something I should pay attention to, please let me know. Thanks very much. BR, Terry
