Abt RTL expression
Hi all,
I need some clarification in understanding the below mentioned RTL Expressions
1. (insn 11 10 12 0
gcc/testsuite/gcc.c-torture/execute/20020611-1.c:13 (parallel [
(set (reg/f:SI 13 a5 [28])
(symbol_ref:SI ("n") [flags 0x2] ))
(clobber (reg:CC 21 cc))
]) 22 {movsi_long_const} (nil)
(expr_list:REG_UNUSED (reg:CC 21 cc)
(expr_list:REG_EQUIV (symbol_ref:SI ("n") [flags 0x2]
)
(nil
Normally set syntax is : set lval x
here lval is (reg/f: SI 13 a5 [28])
a) To which register is the value of n copied? if a5 is the register
what is 13 and [28]
b) what is [flags 0x2]
2.(insn 12 11 13 0 gcc/testsuite/gcc.c-torture/execute/20020611-1.c:13
(set (reg:SI 0 d0 [orig:29 n ] [29])
(mem/c/i:SI (reg/f:SI 13 a5 [28]) [2 n+0 S4 A32])) 15
{movsi_load} (insn_list:REG_DEP_TRUE 11 (nil))
(expr_list:REG_DEAD (reg/f:SI 13 a5 [28])
(expr_list:REG_EQUAL (mem/c/i:SI (symbol_ref:SI ("n") [flags
0x2] ) [2 n+0 S4 A32])
(nil
a) what does this mean [orig:29 n ] [29] in the above expression?
b) what does this mean [2 n+0 S4 A32] in the above expression?
Thanking you in advance,
Regards,
Rohit
Re: is this a good time to commit a patch on builtin_function?
On 10/23/06, Rafael Espíndola <[EMAIL PROTECTED]> wrote: I have an approved patch that factors code that is common to all builtin_function implementations (http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00195.html, http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01499.html). I have just updated and tested it. Is this a good time to commit? Usually such changes disturb branches and are more suitable for late stage2. But in this case I don't see why this should be the case. Richard.
[32bit] `main' missing argc/argv DW_AT_location
Hi, is it a known bug that `main' function (and so even specially compiled with the specific prologue/epilogue) missing DWARF `DW_AT_location' for its `argc' and `argv' on 32-bit targets? I did not find a Bugzilla entry for it. affected: x86_64-redhat-linux with -m32, i386-redhat-linux not affected: x86_64-redhat-linux (-m64) 32-bit broken for: gcc-4.1.1, snapshot 4.2.0 always works: gcc-3.4.6 It causes gdb(1) to hide the arguments during backtrace: #0 main () at test.c:3 Thanks, Jan correct (gcc-3.4.6): <1>: Abbrev Number: 33 (DW_TAG_subprogram) DW_AT_sibling : DW_AT_external: 1 DW_AT_name: main DW_AT_decl_file : 46 DW_AT_decl_line : 267 DW_AT_prototyped : 1 DW_AT_type: DW_AT_low_pc : 0x8048c0f DW_AT_high_pc : 0x8048e26 DW_AT_frame_base : 616(location list) <2>: Abbrev Number: 34 (DW_TAG_formal_parameter) DW_AT_name: argc DW_AT_decl_file : 46 DW_AT_decl_line : 267 DW_AT_type: DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0) <2>: Abbrev Number: 34 (DW_TAG_formal_parameter) DW_AT_name: argv DW_AT_decl_file : 46 DW_AT_decl_line : 267 DW_AT_type: DW_AT_location: 2 byte block: 91 4 (DW_OP_fbreg: 4) incorrect (gcc-4.1.1): <1><64>: Abbrev Number: 2 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: main DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_prototyped : 1 DW_AT_type: <9b> DW_AT_low_pc : 0x8048324 DW_AT_high_pc : 0x804833d DW_AT_frame_base : 0 (location list) DW_AT_sibling : <9b> <2><82>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_name: argc DW_AT_decl_file : 1 DW_AT_decl_line : 1 DW_AT_type: <9b> <2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_name: argv DW_AT_decl_file : 1 DW_AT_decl_line : 1 DW_AT_type:
gmp and mpfr in infrastructure
Hey Kaveh. I'm trying to do a build of gcc. As documented here: http://gcc.gnu.org/install/prerequisites.html Apparently a specific version of GMP and MPFR are suggested. Any chance you could upload this to ftp.gcc.gnu.org/pub/infrastructure? I've found the GMP website to be quite unresponsive. best, benjamin
Re: Abt RTL expression
> a) To which register is the value of n copied? if a5 is the register
> what is 13 and [28]
All of those numbers refer to the same register -
13 is the number of the register; a5 is the name of the register
(if it is an hard register);
[28] is the number of the old pseudo register.
(please look at ORIGINAL_REGNO in rtl.h for more info)
> b) what is [flags 0x2]
[flags 0x2] are symbol_ref flags and var_decl is the tree decl associated
with this symbol.
(see SYMBOL_REF_FLAGS in rtl.h)
>
> 2.(insn 12 11 13 0 gcc/testsuite/gcc.c-torture/execute/20020611-1.c:13
> (set (reg:SI 0 d0 [orig:29 n ] [29])
> (mem/c/i:SI (reg/f:SI 13 a5 [28]) [2 n+0 S4 A32])) 15
> {movsi_load} (insn_list:REG_DEP_TRUE 11 (nil))
> (expr_list:REG_DEAD (reg/f:SI 13 a5 [28])
> (expr_list:REG_EQUAL (mem/c/i:SI (symbol_ref:SI ("n") [flags
> 0x2] ) [2 n+0 S4 A32])
> (nil
>
> a) what does this mean [orig:29 n ] [29] in the above expression?
As above; [orig:29 n ] [29] are the numbers of the old
pseudo register.
> b) what does this mean [2 n+0 S4 A32] in the above expression?
[2 n+0 S4 A32] contains information on the memory expression -
2 is the alias set (MEM_ALIAS_SET);n is the base memory expression and 0 is
it's offset
;S4 is the size in bytes of the memory expression (MEM_SIZE) and A32 is the
alignment in bits (MEM_ALIGN).
Hope it helps,
Revital
Abt RTL expression - Optimization
Hi all,
This small bit of code worked fine with all optimization except Os.
unsigned int n = 30;
void x ()
{
unsigned int h;
h = n <= 30; // Line 1
if (h)
p = 1;
else
p = 0;
}
when we tried to debug the emitted RTL instruction for Os, it was
found that RTL instruction for Line #1 (Compare and gtu) were not at
all emitted. i.e. there is no reference with respect to "h". For the
same optimization Os, if we declare the identifier "h" as global, it
generates the instructions properly.
1. Is the deletion of instructions (Size optimization with respect to
local identifiers) controlled by any flag?
2. Is it possible to override this optimzation constraint?
Thanking you in advance,
Rohit
Re: Question about LTO dwarf reader vs. artificial variables and formal arguments
Steven Bosscher wrote: I want to make gfortran produce better debug information, but I want to do it in a way that doesn't make it hard/impossible to read back in sufficient information for LTO to work for gfortran. I haven't really been following the whole LTO thing much, but if I understand correctly, the goal is to reconstruct information about declarations from DWARF information that we write out for those declarations. If that's the case, I wonder how LTO will handle artificial "variables" and formal argument lists. [much snippage] The short answer is that I don't know the answer to your questions. ;-) So far I've been focusing on C in the LTO reader, with a few hooks for C++, and I'm not familiar enough with the Fortran front end to know what special challenges it might present. If your goal is to produce better debug information, I'd just focus on doing that within the constraints of Dwarf, and forget about LTO entirely. For instance, I agree with the suggestion that the Fortran front end ought to be tagging artificial variables with DW_AT_artificial instead of resorting to other hacks. That's about keeping the debugger happy and really has nothing to do with LTO. If Dwarf just isn't adequate to represent the full Fortran type information in a way that allows it to be fully reconstructed by the LTO front end, we can both extend Dwarf and extend the Gimple dumper, e.g., by dumping both the "real type" as well as the "declared type" you want the debugger to see. Or we might end up not using Dwarf at all in the long run. -Sandra
Expressions simplification statistic
2006/10/17, Mike Stump <[EMAIL PROTECTED]>: On Oct 17, 2006, at 8:05 AM, Dino Puller wrote: > i'm looking for a statistic of how many expressions simplification > may be possible on source code One way would be: http://www.cs.fit.edu/~mmahoney/compression/text.html But it´s a benchmark about compression. though, this assumes a particular definition of simplification. For other definitions, gcc doesn't just tell you an answer, you'd have to define what you think a simplification is and then instrument gcc to provide that answer. This would be lots of hard work at best. For expressions simplification i mean simply mathematical simplificacions like: x/x=1 0*x=1 1*x=x and so on. bye, Dino
Re: Abt RTL expression - Optimization
On Mon, 2006-10-23 at 16:14 +0530, Rohit Arul Raj wrote: > Hi all, > > This small bit of code worked fine with all optimization except Os. If you are working with 4.0 and greater, there are optimizations that happen before RTL, called the Tree-ssa optimizations. The optimization you are noticing here is called forward propagation. Thanks, Andrew Pinski
Re: gmp and mpfr in infrastructure
On Mon, 23 Oct 2006, Benjamin Kosnik wrote: > Hey Kaveh. > > I'm trying to do a build of gcc. As documented here: > > http://gcc.gnu.org/install/prerequisites.html > > Apparently a specific version of GMP and MPFR are suggested. Any chance > you could upload this to ftp.gcc.gnu.org/pub/infrastructure? I've found > the GMP website to be quite unresponsive. > > best, benjamin I think that is a splendid idea. But I don't recall having access to that directory. Or is it something anyone with svn write access can do? The docs recommend gmp-4.1 or later, but I would suggest the latest, which is version 4.2.1. (Also don't forget the mpfr cumulative patch!) Regards, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: gmp and mpfr in infrastructure
> I think that is a splendid idea. But I don't recall having access to that > directory. Or is it something anyone with svn write access can do? I believe it is something that anybody could do. If you have questions, you can ask on overseers or ping one of the overseers on IRC. > The docs recommend gmp-4.1 or later, but I would suggest the latest, which > is version 4.2.1. (Also don't forget the mpfr cumulative patch!) Since you presumably have the canonical sources we're supposed to use, it would be great if you could do this for everybody else. -benjamin
LOOP_HEADER tree code?
Hello, for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering introducing a tree LOOP_HEADER with single argument N (number of iterations of the loop), that would be present in IL at the beginning of header of each loop. I have following motivations: 1) One of the goals of the project is to avoid recomputing number of iterations of loops, and to keep this information (analysing # of iterations is fairly expensive, and we recompute this information quite a lot at the moment). To keep the information valid, we need to prevent optimizations from destroying it (e.g., if the number is n_1 = n_2 - 1, and this is the last use of n_1, we do not want DCE to remove it); this is easy to achieve if n_1 would be the argument of LOOP_HEADER. Without this tree node in IL, we would need to handle this specially in DCE, and possibly also other optimizers. 2) This statement might make it simpler to ensure that various optimizers update the loops correctly. I am not quite sure whether this is a good idea, though. Are there some reasons why not to do this, or any other problems with the idea? Zdenek
Re: gmp and mpfr in infrastructure
On Mon, 23 Oct 2006, Benjamin Kosnik wrote: > > I think that is a splendid idea. But I don't recall having access to that > > directory. Or is it something anyone with svn write access can do? > > I believe it is something that anybody could do. If you have questions, > you can ask on overseers or ping one of the overseers on IRC. I wasn't able to ssh directly into gcc.gnu.org, it seemed to accept my connection but then it hung for a while and punted me out. So I sent email to overseers. > > The docs recommend gmp-4.1 or later, but I would suggest the latest, which > > is version 4.2.1. (Also don't forget the mpfr cumulative patch!) > > Since you presumably have the canonical sources we're supposed to use, > it would be great if you could do this for everybody else. > -benjamin Yeah sure, I'd like to do that assuming I can get in. In the mean time, I had no problems getting the three files I needed directly from the canonical websites just now using `wget'. ftp://ftp.gnu.org/gnu/gmp/gmp-4.2.1.tar.bz2 http://www.mpfr.org/mpfr-current/mpfr-2.2.0.tar.bz2 http://www.mpfr.org/mpfr-current/patches You'll need to name the patches file something meaningful. I'd be happy to upload these once I get access (unless someone beats me to it). --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: gmp and mpfr in infrastructure
On Mon, 23 Oct 2006, Kaveh R. GHAZI wrote: > I'd be happy to upload these once I get access (unless someone beats me to > it). Ben - Gerald uploaded the files. (Thanks Gerald!) --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: GCC 4.2 branch created; mainline open in Stage 1
Andrew Pinski wrote:
On Sun, 2006-10-22 at 12:58 +, Joseph S. Myers wrote:
All the bugs with "4.2" in their summaries ("[4.1/4.2 Regression]" etc.)
need to have it changed to "4.2/4.3". I don't know the procedure for
this, but perhaps it needs adding to the branching checklist.
As I understand it, it involves editing the mysql database by hand (well
by a script) instead of doing it inside bugzilla. Daniel Berlin has
done that the last couple of releases.
I have checked in the attached patch to add this step to the branching
checklist. I will now ask Daniel to help with the SQL bits.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: GCC 4.2 branch created; mainline open in Stage 1
Mark Mitchell wrote:
Andrew Pinski wrote:
On Sun, 2006-10-22 at 12:58 +, Joseph S. Myers wrote:
All the bugs with "4.2" in their summaries ("[4.1/4.2 Regression]"
etc.) need to have it changed to "4.2/4.3". I don't know the
procedure for this, but perhaps it needs adding to the branching
checklist.
As I understand it, it involves editing the mysql database by hand (well
by a script) instead of doing it inside bugzilla. Daniel Berlin has
done that the last couple of releases.
I have checked in the attached patch to add this step to the branching
checklist. I will now ask Daniel to help with the SQL bits.
Sorry, here's the patch.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Index: branching.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v
retrieving revision 1.24
diff -c -5 -p -r1.24 branching.html
*** branching.html 21 Sep 2006 14:17:36 - 1.24
--- branching.html 23 Oct 2006 19:49:16 -
*** milestone for 3.4.1 for PRs that can't b
*** 73,81
--- 73,85
Update the email parsing script to handle bugs against the new versions.
The script is in CVS at wwwdocs/bugzilla/contrib/bug_email.pl.
Search for an existing version (like "3.3"), and update both places
it occurs to handle the new version through copy and paste.
+ Ask Daniel Berlin to adjust all PRs with the just-branched version
+ in their summary to also contain the new version corresponding to
+ mainline.
+
[Fwd: gcc-4.3-20061023 is now available]
Here is the announcement mail for the special first-from-mainline 4.3 snapshot. The references to "Diffs from" below should say "4.2-20061014" rather than "4.3-". I have reactivated the cronjob so that future snapshots for 4.3 should be generated automatically. Thanks to Joseph for helping me with this. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 --- Begin Message --- Snapshot gcc-4.3-20061023 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061023/ 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/trunk revision 117985 You'll find: gcc-4.3-20061023.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20061023.tar.bz2 C front end and core compiler gcc-ada-4.3-20061023.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20061023.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20061023.tar.bz2 C++ front end and runtime gcc-java-4.3-20061023.tar.bz2 Java front end and runtime gcc-objc-4.3-20061023.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20061023.tar.bz2The GCC testsuite Diffs from 4.3- 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. --- End Message ---
Re: [Fwd: gcc-4.3-20061023 is now available]
Mark, What happened to the gcc 4.2 snapshot tarball for this week? Jack
Re: [Fwd: gcc-4.3-20061023 is now available]
Jack Howarth wrote: Mark, What happened to the gcc 4.2 snapshot tarball for this week? It gets build on Tuesdays, or at least it does now according to crontab. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GMP test
It seems that the GMP test is always run, even when installing binutils
or gdb.
You probably need something like
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC subdirectory, not
in the toplevel (it was anyway a hack for the sake of disabling Fortran).
Sorry for not speaking up earlier,
Paolo
Re: GMP test
>
> It seems that the GMP test is always run, even when installing binutils
> or gdb.
>
> You probably need something like
>
> if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
> ...
> fi
>
> but I think that the whole test now belongs in the GCC subdirectory, not
> in the toplevel (it was anyway a hack for the sake of disabling Fortran).
Moving it is not really a good thing anyways as you are able to configure
and then do a "make -j3" and it is hard to figure out why the build fail
because you don't have the correct version of GMP/MPRF.
-- Pinski
Re: GMP test
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC subdirectory, not
in the toplevel (it was anyway a hack for the sake of disabling Fortran).
Moving it is not really a good thing anyways as you are able to configure
and then do a "make -j3" and it is hard to figure out why the build fail
because you don't have the correct version of GMP/MPRF.
Maintainability first. If something fails with parallel make, and is
reproducible with plain "make" (i.e. doesn't screw up the build
directory), I don't see a reason not to move it. You'd do "make" anyway
to check if a dependency is missing, wouldn't you?
Paolo
Re: GMP test
On Oct 23, 2006, at 4:15 PM, Paolo Bonzini wrote:
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC
subdirectory, not in the toplevel (it was anyway a hack for the
sake of disabling Fortran).
Moving it is not really a good thing anyways as you are able to
configure
and then do a "make -j3" and it is hard to figure out why the build
fail
because you don't have the correct version of GMP/MPRF.
Maintainability first. If something fails with parallel make, and
is reproducible with plain "make" (i.e. doesn't screw up the build
directory), I don't see a reason not to move it. You'd do "make"
anyway to check if a dependency is missing, wouldn't you?
Really, all I care about is having it depend on the languages enabled.
It's driving me crazy at the moment on a non-fortran build.
-eric
Re: GMP test
>
>
> >> if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
> >> ...
> >> fi
> >>
> >> but I think that the whole test now belongs in the GCC subdirectory, not
> >> in the toplevel (it was anyway a hack for the sake of disabling Fortran).
> >
> > Moving it is not really a good thing anyways as you are able to configure
> > and then do a "make -j3" and it is hard to figure out why the build fail
> > because you don't have the correct version of GMP/MPRF.
>
> Maintainability first. If something fails with parallel make, and is
> reproducible with plain "make" (i.e. doesn't screw up the build
> directory), I don't see a reason not to move it. You'd do "make" anyway
> to check if a dependency is missing, wouldn't you?
But this is a different case as this error is for users rather than developers.
So instead of getting an error early before compiling, we get an error 10 to 20
minutes later and users get upset that they get an error this late for something
which could have been found early on.
-- Pinski
Re: GMP test
Maintainability first. If something fails with parallel make, and is reproducible with plain "make" (i.e. doesn't screw up the build directory), I don't see a reason not to move it. You'd do "make" anyway to check if a dependency is missing, wouldn't you? Really, all I care about is having it depend on the languages enabled. It's driving me crazy at the moment on a non-fortran build. As was pointed out, gmp/mpfr are now used in the default code path. This is causing systems with multiple sets of libraries installed, or optional libraries installed in odd paths (/opt/local) to start overriding others. Right now, for example there are two sets of libiconv found on my system. Configure finds one set in /usr/lib, but the -L added for gmp when I set it to /opt/local finds gnu libiconv off in /opt/local which really isn't the desired result. Of course, I can work around this using --with-libiconv-prefix, but my configure line is starting to look a bit long... At some point the configury should agree on how to find optional libraries. I don't mind picking either the system or the ones in .../ some-prefix, but it should be consistent in how it looks for libraries and headers. Thoughts? -eric
Re: GMP test
But this is a different case as this error is for users rather than developers. So instead of getting an error early before compiling, we get an error 10 to 20 minutes later and users get upset that they get an error this late for something which could have been found early on. That is a problem with running configure at make time in general. If we add some kind of plugin system for configure fragments, it might fly. As the thing stands now, it is not a good-enough reason to pollute the toplevel code. We are not maintainers anyway, so we cannot ask anybody to do anything. Kaveh might or might not prepare a patch to move the test, and if he does, it will be up to the maintainers to decide who they agree with. Paolo
More __comp_ctor () woes
Hi again,
I am having issues with the __comp_ctor () __base_ctor () etc functions
that I encounter in the C++ front-end tree (Just before gimplification).
If i compile some code that looks like:
#include
int main()
{
std::allocator alloc;
const char* str1 = "Hello";
const char* str2 = "Hello";
std::basic_string, std::allocator
> str(str1, str2, alloc);
return 0;
}
Note: I think this code is incorrect, however it compiles fine.
I am trying to figure out which of the constructors of std::basic_string
GCC would use for this code. Is it the following constructor?
template
basic_string(_InputIterator __beg, _InputIterator __end, const _Alloc&
__a = _Alloc());
The main problem i am having is that GCC generates a FUNCTION_DECL for:
__comp_ctor (::char const*, ::char const*, ::std::allocator const&)
I am trying to find the corresponding constructor from the basic_string
class that should be called in place of the __comp_ctor function. There
seems to be no FUNCTION_DECL node for the constructor:
basic_string(::char const*, ::char const*, ::std::allocator const&)
which I would expect if there is a __comp_ctor () with those parameters.
My questions are:
1) Which of the basic_string constructors would be being called in this
situation?
2) Do __comp_ctor and __base_ctor functions just call/are substituted
with equivilant "User Constructors" with exactly the same arguments or
do the arguments of the __comp_ctor sometimes differ from the "User
Constructor" that it is associated with?
3) Again, is there a simple way of finding the constructor method that
would be called given a corresponding __comp_ctor () method?
Thanks,
Brendon.
Re: More __comp_ctor () woes
On Tue, 2006-10-24 at 02:30 +, Brendon Costa wrote: > I am trying to find the corresponding constructor from the basic_string > class that should be called in place of the __comp_ctor function. There > seems to be no FUNCTION_DECL node for the constructor: > > basic_string(::char const*, ::char const*, ::std::allocator const&) > > which I would expect if there is a __comp_ctor () with those parameters. Wait you say you have a function decl but cannot find the function decl for the constructor? I don't understand what you are getting at here. Do you understand how templates work because that seems like where you are getting lost. Templates are instantiated with different types, in this case, with _InputIterator being "const char*" > My questions are: > > 1) Which of the basic_string constructors would be being called in this > situation? template basic_string(_InputIterator, _InputIterator, const _Alloc& ); Instantiated with _InputIterator being "const char*". > 3) Again, is there a simple way of finding the constructor method that > would be called given a corresponding __comp_ctor () method? Find how and what? Find the FUNCTION_DECL? (you should already have that.) Find the body of the function? (function decl has that.) Find where the function is defined in the source? (the lotus of the function decl should say where that is). Thanks, Andrew Pinski
Re: More __comp_ctor () woes
Sorry that my previous email was unclear. I have tried to clarify what i
meant in this email by answering your questions.
Andrew Pinski wrote:
On Tue, 2006-10-24 at 02:30 +, Brendon Costa wrote:
I am trying to find the corresponding constructor from the basic_string
class that should be called in place of the __comp_ctor function. There
seems to be no FUNCTION_DECL node for the constructor:
basic_string(::char const*, ::char const*, ::std::allocator const&)
which I would expect if there is a __comp_ctor () with those parameters.
Wait you say you have a function decl but cannot find the function decl
for the constructor? I don't understand what you are getting at here.
Do you understand how templates work because that seems like where you
are getting lost. Templates are instantiated with different types, in
this case, with _InputIterator being "const char*"
If there is a simple class like:
class MyClass
{
MyClass()
{}
};
int main()
{
MyClass c;
return 0;
}
This will produce at least 3 FUNCTION_DECL nodes:
1) main()
2) MyClass::MyClass(MyClass* this)
3) MyClass::__comp_ctor (MyClass* this)
I call (2) a "User Constructor" for want of a better name. But note that
BOTH (2) and (3) are considered "constructors" as returned by
DECL_CONSTRUCTOR_P(fndecl)
I have the FUNCTION_DECL node for (3) and want to find (2) from it.
Basically as i understand it, main() will call (3) using a CALL_EXPR
when it constructs the instance of MyClass. This __comp_ctor (MyClass*
this) function (Which does not have an implementation i can find with
DECL_SAVED_TREE) should call (2)
I have noticed that all __comp_ctor () and __base_ctor () FUNCTION_DECL
nodes seem to correspond to a "User Constructor" for the same class that
the __comp_ctor () was found in with exactly the same parameter list as
the __comp_ctor () has.
For example:
SomeClass::__comp_ctor (const SomeClass&)
will some-how call:
SomeClass::SomeClass(const SomeClass&)
and:
SomeClass::__comp_ctor (int)
will some-how call:
SomeClass::SomeClass(int)
So hopefully that helps to understand what i mean by the two
FUNCTION_DECL nodes.
The problem is that with the code in the previous email, i cant seem to
find the associated "User Constructor" FUNCTION_DECL node given the
__comp_ctor constructor FUNCTION_DECL node. In particular:
std::basic_string::__comp_ctor (::char const*, ::char const*,
::std::allocator const&)
exists, but i cant seem to find an associated:
std::basic_string::basic_string(::char const*, ::char const*,
::std::allocator const&)
NOTE: I have left the template parameters out to make this easier to read.
My questions are:
1) Which of the basic_string constructors would be being called in this
situation?
template
basic_string(_InputIterator, _InputIterator, const _Alloc& );
Instantiated with _InputIterator being "const char*".
Ignore this question. I think i know the answer, and yes i do understand
how template instanciation works. I just wanted someone to say yes or no
as to wether the above constructor from std::basic_string is the one
that is being used when compiling the code I provided.
In particular, is the code I provided calling a different constructor
from within std::basic_string class or is it instanciating this
templated cosntructor and using the instanciated constructor with "const
char*" as the template parameter?
I think the answer is yes it is using an instanciation of this
constructor, but I wanted clarification.
I was interested in the answer to this as i am trying to reproduce the
problem with the __comp_ctor () FUNCTION_DECL in a small test case (Not
using std::basic_string). I have tried but seem unable to reproduce the
problem in a smaller test case currently. An answer to that question
above might help me in finding what exactly is causing the problem i
have encountered.
Thanks,
Brendon.
Re: GCC 4.2 branch created; mainline open in Stage 1
>> As I understand it, it involves editing the mysql database by hand (well >> by a script) instead of doing it inside bugzilla. Daniel Berlin has >> done that the last couple of releases. > > I have checked in the attached patch to add this step to the branching > checklist. I will now ask Daniel to help with the SQL bits. Sorry, here's the patch. So the way i actually do this is with a crappy perl script. in /home/dberlin on sourceware.org, there is a script called 42changer.pl. I just copy it to the next version number (43changer.pl in this case), and edit the script to do so it changes 4.2 regression to 4.2/4.3 regression instead of changing (in this case) 4.1 regression to 4.1/4.2 regression. I'm just saying this for posterity sake so if someone needs to lookup how this actually gets done, they know :) If i actually knew perl, i'm sure it would be trivial to just make this stuff a command line parameter to the script. But i'm afraid of perl, and afraid that if i tried, it would end up only working on months that end in the letter r or something, since that is perl for you. Anyway, i made 43changer.pl and ran it, so the bug summaries have been updated.
Re: More __comp_ctor () woes
On Tue, 2006-10-24 at 03:32 +, Brendon Costa wrote:
> Sorry that my previous email was unclear. I have tried to clarify what i
> meant in this email by answering your questions.
>
>
> If there is a simple class like:
>
> class MyClass
> {
> MyClass()
> {}
> };
>
> int main()
> {
> MyClass c;
> return 0;
> }
>
> This will produce at least 3 FUNCTION_DECL nodes:
> 1) main()
> 2) MyClass::MyClass(MyClass* this)
> 3) MyClass::__comp_ctor (MyClass* this)
>
> I call (2) a "User Constructor" for want of a better name. But note that
> BOTH (2) and (3) are considered "constructors" as returned by
> DECL_CONSTRUCTOR_P(fndecl)
This comes from the fact ABI has two constructors, an in charge and an
out of charge and the orginal constructor is still there though 3 is a
clone of (2). (2) is never compiled or called.
> I have the FUNCTION_DECL node for (3) and want to find (2) from it.
Why do you need to find (2)? It is not the function which is actually
called. DECL_SAVED_TREE might not be set but that is because it has
already been gimplified and lowered to CFG at the time you are looking
through the calls.
Why do you need to know the constructor anyways?
Thanks,
Andrew Pinski
Re: GCC 4.2 branch created; mainline open in Stage 1
Daniel Berlin wrote: Anyway, i made 43changer.pl and ran it, so the bug summaries have been updated. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: More __comp_ctor () woes
Andrew Pinski wrote: Why do you need to find (2)? It is not the function which is actually called. DECL_SAVED_TREE might not be set but that is because it has already been gimplified and lowered to CFG at the time you are looking through the calls. Why do you need to know the constructor anyways? Thanks for the reply. I am creating a tool that allows users to perform static analysis of C++ exception propogation. Basically while GCC compiles source, I gather certain information that is then embedded as data belonging in a seperate section in the asm file. This then produces an object file in which my data is placed into a seperate section called ".edoc" which allows a post processing tool which extracts this information to construct a complete "pessimistic" call graph of source, and it also gathers other information about exception try/catch blocks and where the function calls are made etc. I wont go into details about the rest of it because that is not the issue here, but in order to construct a call graph one of the things i need to do is to follow the CALL_EXPR's from say the main() function mentioned in my last email that actuall calls MyClass::__comp_ctor () to the fact that the users defined MyClass::MyClass(MyClass* this) function is being called. So i need to know that when in the main function for example i come across a CALL_EXPR and the function target for that is a FUNCTION_DECL node for the MyClass::__comp_ctor (MyClass* this), this will actually call: MyClass::MyClass(MyClass* this). This allows me to construct the call graph, otherwise I have a broken link that ends at the __comp_ctor(). Since in the tree there is no implementation for any of the __comp_ctor (), __base_ctor (), ... same for dtor() functions. In my data file i generate a "fake" call graph link which says that the __comp_ctor () calls the MyClass() method. If there is another way of achiving this I would love to hear it, but I have a mostly working implementation already, this is one of the few problems i have left to iron out. Thanks, Brendon.
Re: More __comp_ctor () woes
In order to help, I am posting the code I use to try and get a "user
constructor" FUNCTION_DECL node from a "__comp_ctor ()" FUNCTION_DECL
node as mentioned in previous emails. The code can be found at the end
of this email.
Also...
class MyClass
{
MyClass()
{}
};
int main()
{
MyClass c;
return 0;
}
This will produce at least 3 FUNCTION_DECL nodes:
1) main()
2) MyClass::MyClass(MyClass* this)
3) MyClass::__comp_ctor (MyClass* this)
I call (2) a "User Constructor" for want of a better name. But note that
BOTH (2) and (3) are considered "constructors" as returned by
DECL_CONSTRUCTOR_P(fndecl)
This comes from the fact ABI has two constructors, an in charge and an
out of charge and the orginal constructor is still there though 3 is a
clone of (2). (2) is never compiled or called.
As i understand it (2) is compiled, as that is the function that
contains the users code. I could be wrong here though as i have very
little experience hacking GCC.
The code I am using to obtain a "user constructor" FUNCTION_DECL from a
"__comp_ctor ()" FUNCTION_DECL looks as shown below. I really dont like
this code as it currently uses a strcmp in order to findwhat it is after
and it also does not work completely. I have also placed some code at
the very end of this email which is a small test case of code that this
fails for.
Thanks,
Brendon
I call the function: GetCtorEquivilent(tree fndecl) with the fndecl node
for the "__comp_ctor()" i am looking for the associated "User
constructor" for.
static tree GetCtorEqvProcMethod(tree fndecl, tree method,
const char* context_string, int context_len);
/*==*/
tree GetCtorEquivilent(tree fndecl)
{
tree context = NULL_TREE;
tree method = NULL_TREE;
int context_len = 0;
const char* context_string = NULL;
tree ret = NULL_TREE;
context = DECL_CONTEXT(fndecl);
BJC_ASSERT(TYPE_P(context), "Should be a TYPE object");
BJC_ASSERT(CLASS_TYPE_P(context), "Should be a CLASS TYPE object");
/* Get list of classes methods that we will search for a
constructor in. */
method = TYPE_METHODS(context);
context_string = IDENTIFIER_POINTER(
DECL_NAME(TYPE_NAME(context)));
context_len = strlen(context_string);
while(method)
{
ret = GetCtorEqvProcMethod(fndecl, method,
context_string, context_len);
if (ret)
{
return ret;
}
method = TREE_CHAIN(method);
}
return NULL_TREE;
}
/*==*/
static tree GetCtorEqvProcMethod(tree fndecl, tree method,
const char* context_string, int context_len)
{
tree ret = NULL_TREE;
tree list = NULL_TREE;
int decl_len = 0;
const char* decl_string = NULL;
/* We are only interested in constructors */
if (!DECL_CONSTRUCTOR_P(method))
{
return NULL_TREE;
}
/* Ensure we do not look at ourself */
if (method == fndecl)
{
return NULL_TREE;
}
/* If is a template decl then process all instanciations */
if (TREE_CODE(method) == TEMPLATE_DECL)
{
list = DECL_TEMPLATE_SPECIALIZATIONS(method);
while (list)
{
/* The TREE_VALUE should be eithre a FUNCTION_DECL
or a TEMPLATE_DECL process it recursivly. */
ret = GetCtorEqvProcMethod(fndecl, constructor,
TREE_VALUE(list), context_string, context_len);
if (ret)
{
return ret;
}
list = TREE_CHAIN(list);
}
return NULL_TREE;
}
/* Template decls are handled above, at this point we
should only ever see function decls. */
BJC_ASSERT(TREE_CODE(method) == FUNCTION_DECL, "");
/* This is dodgy there has to be a way to do this
without using string compare of the first part. I.e.
we are comparing without looking at the template data.*/
/* I.e. ::Container<::int>::Container() is the correct
constructor NOT
::Container<::int>::Container<::int>() which will never occur
*/
decl_string = IDENTIFIER_POINTER(DECL_NAME(method));
decl_len = strlen(decl_string);
if (strncmp(context_string, decl_string, decl_len))
{
/*decl has a different name than the context. */
return NULL_TREE;
}
if (context_len != decl_len)
{
if (context_string[decl_len] != '<')
{
/*decl has a different name than the context. */
return NULL_TREE;
}
}
/* Got a method with the same name as the class that
encapsulates it. Now checking parameter types to see if
they are the same */
/* This function is defined elsewhere and will compare
parameters of functions/methods ignoring the
in_charge_identifier, vtt_parm_identifier nodes
if the 3rd arg is true*/
if (!FunctionsHaveSameArgs(fndecl, method, true))
{
return NULL_TREE;
}
return method;
}
---
This is a simple test case which causes the above to fail to find a
"user constructor" for the associated "__comp_
