Re: Is VIEW_CONVERT_EXPR an lvalue? (was Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10)))
On Sat, Jun 11, 2011 at 10:01 PM, Jason Merrill wrote: > On 06/10/2011 10:20 AM, Richard Guenther wrote: >> >> no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example >> would turn the above to (volatile int) a[1]). > > The gimplifier seems to consider it an lvalue: gimplify_expr uses > gimplify_compound_lval for it, and gimplify_addr_expr handles taking its > address. And get_inner_reference handles it. So I think fold should be > changed, and we should clarify that VIEW_CONVERT_EXPR is an lvalue. > > If not, we need a new tree code for treating an lvalue as an lvalue of a > different type without having to take its address; that's what I thought > VIEW_CONVERT_EXPR was for. The please provide a specification on what a VIEW_CONVERT_EXPR does to type-based alias analysis. We are trying to avoid that by the rvalue rule. Also you can always avoid VIEW_CONVERT_EXPRs for lvalues by simply moving the conversion to the rvalue side. Yes, we do handle lvalue VIEW_CONVERT_EXPRs, but that is for Ada which uses it for aggregates. I don't want us to add more lvalue VIEW_CONVERT_EXPR cases, especially not for register types. Richard. > Jason >
Re: GCC 4.6.1 Status
On Sat, Jun 11, 2011 at 10:19 PM, Erik Vaughn wrote: >> GCC 4.6.1 is planned for roughly late May, unless any reason arises to> >> release >>it earlier. >> The next report for 4.6.1 will be sent by Richard. > > Is there a reason that the release has been delayed? Lack of time? Queuing up some more bugfixes? Richard.
Re: Is VIEW_CONVERT_EXPR an lvalue? (was Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10)))
On Sun, Jun 12, 2011 at 12:59 PM, Richard Guenther wrote: > On Sat, Jun 11, 2011 at 10:01 PM, Jason Merrill wrote: >> On 06/10/2011 10:20 AM, Richard Guenther wrote: >>> >>> no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example >>> would turn the above to (volatile int) a[1]). >> >> The gimplifier seems to consider it an lvalue: gimplify_expr uses >> gimplify_compound_lval for it, and gimplify_addr_expr handles taking its >> address. And get_inner_reference handles it. So I think fold should be >> changed, and we should clarify that VIEW_CONVERT_EXPR is an lvalue. >> >> If not, we need a new tree code for treating an lvalue as an lvalue of a >> different type without having to take its address; that's what I thought >> VIEW_CONVERT_EXPR was for. Btw, see tree.def which says /* Represents viewing something of one type as being of a second type. This corresponds to an "Unchecked Conversion" in Ada and roughly to the idiom *(type2 *)&X in C. The only operand is the value to be viewed as being of another type. It is undefined if the type of the input and of the expression have different sizes. This code may also be used within the LHS of a MODIFY_EXPR, in which case no actual data motion may occur. TREE_ADDRESSABLE will be set in this case and GCC must abort if it could not do the operation without generating insns. */ DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) > The please provide a specification on what a VIEW_CONVERT_EXPR does > to type-based alias analysis. We are trying to avoid that by the rvalue rule. > Also you can always avoid VIEW_CONVERT_EXPRs for lvalues by simply > moving the conversion to the rvalue side. > > Yes, we do handle lvalue VIEW_CONVERT_EXPRs, but that is for Ada > which uses it for aggregates. I don't want us to add more lvalue > VIEW_CONVERT_EXPR > cases, especially not for register types. > > Richard. > >> Jason >> >
GCC mainline is broken on x86
Hi, Revision 174952: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00441.html totally breaks C++ on x86: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49378 http://gcc.gnu.org/ml/gcc-regression/2011-06/msg00159.html One symptom is we are using uninitialized registers, which leads to writing random memory location. The same ia32 binary works on Fedora 14 under kernel 2.6.35 and failed under Fedora 15 under kernel 2.6.38. We also use uninitialized registers on x86-64, but the program doesn't crash. This bug may also affects C and other languages. -- H.J.
gcc-4.3-20110612 is now available
Snapshot gcc-4.3-20110612 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110612/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 174971 You'll find: gcc-4.3-20110612.tar.bz2 Complete GCC MD5=9f297d52f1d562825664b493330888af SHA1=e97990d361023afe8087b205032a4ac64caeaea6 Diffs from 4.3-20110605 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: Is VIEW_CONVERT_EXPR an lvalue? (was Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10)))
On 06/12/2011 06:59 AM, Richard Guenther wrote: The please provide a specification on what a VIEW_CONVERT_EXPR does to type-based alias analysis. If the alias set of the VIEW_CONVERT_EXPR type the same as the set for the operand, ignore it; if it's a subset, handle it like a COMPONENT_REF; otherwise ignore the operand for TBAA. It seems like get_alias_set currently gets this backwards; it's ignoring outer COMPONENT_REFs instead of the inner structure. Yes, we do handle lvalue VIEW_CONVERT_EXPRs, but that is for Ada which uses it for aggregates. It also seems to be widely used for vectors, but perhaps that's only for rvalues. I don't want us to add more lvalue VIEW_CONVERT_EXPR cases, especially not for register types. Then how do we convert an int lvalue to a volatile int lvalue? /* Represents viewing something of one type as being of a second type. This corresponds to an "Unchecked Conversion" in Ada and roughly to the idiom *(type2 *)&X in C. Right, that's why I thought it was an lvalue. This code may also be used within the LHS of a MODIFY_EXPR And this. Jason
Re: Is VIEW_CONVERT_EXPR an lvalue? (was Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10)))
On Jun 12, 2011, at 4:03 AM, Richard Guenther wrote: > Btw, see tree.def which says > > /* Represents viewing something of one type as being of a second type. > This corresponds to an "Unchecked Conversion" in Ada and roughly to > the idiom *(type2 *)&X in C. The only operand is the value to be > viewed as being of another type. It is undefined if the type of the > input and of the expression have different sizes. > > This code may also be used within the LHS of a MODIFY_EXPR, in which > case no actual data motion may occur. TREE_ADDRESSABLE will be set in > this case and GCC must abort if it could not do the operation without > generating insns. */ I wasn't able to follow what this was trying to say. :-( No actual data motion may occur? The wording is weasely. Does it mean: Data motion does not occur when used on the LHS of a MODIFY_EXPR? If so, it should just directly state it.
Re: Generate annotations for a binary translator
> > At the end of the link belows, > > > > http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG > > > > It says, > > > > "Note that at present, the representation of control flow in the tree > > representation is discarded before expanding to RTL. Long term the CFG > > should be maintained and "expanded" to the RTL representation along > > with the function tree itself." > > > > Does this mean in the end of GCC compilation, the CFG information is > > lost? Thanks! > > That documentation is out of date. The CFG is now retained through most > of the RTL passes. The comment on function gimple_expand_cfg in gcc/cfgexpand.c prove the document is wrong, right? "We do conversion per basic block and preserve/update the tree CFG. This implies we have to do some magic as the CFG can simultaneously consist of basic blocks containing RTL and GIMPLE trees." Is there a way for me to correct the document? 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
