Q: whole program entry point in SSA?
Hello, (I'm still a newbie in gcc) I am interested in -fwhole-program analysis (flag_whole_program) and I know that with -O3 -fwhole-program the cgraph_nodes is cleaned (in cgraphunit.c probably by cgraph_varpool_remove_unreferenced_decls) so that only functions callable from main are kept (as a counter example, compile with -fwhole-program -O3 a test.c file without any main function, you'll get a nearly empty test.s without any code; I even submitted a trivial patch http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00626.html to gcc-patches@ adding a warning in that case) But I do not understand exactly where in the GCC source code the main entry point is used as a starting point for this call graph analysis. I guess that it is in the decide_is_function_needed function of cgraphunit.c (with a MAIN_NAME_P test). Could someone confirm my partial understanding please? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
g++ -print-prefix or -print-install-prefix
For testing outside of the build directory, it would be convenient to have $SUBJECT. This could be used in conjunction with -dumpversion to create on-the-fly include and library directory paths for C++ includes in a sane manner, much like the following: %g++ -print-install-prefix /mnt/share/bld/H-x86-gcc %g++ -dumpversion 4.2.0 Then it'd be trivial to construct things like /mnt/share/bld/H-x86-gcc/include/c++/4.2.0 Anyway. I suppose there's a way to get at this via g++ -print-libgcc-file-name but in the meantime, I'm wondering if there is a much easier way to go about this that I'm currently overlooking. Thoughts? -benjamin
Issue with hard regs
Hi there
i'm in the process of coding a GCC backend for a certain RISC-like architecture.
Its register architecture consists of an integer register file (32 regs) and two
additional hard regs that should be programmer visible. Accesses to these hard
regs are also emitted related to certain RTL patterns (divmoddi4 and udivmoddi4
for which these two hard regs should be written). Split 64-bit moves may or may
not use these regs as well.
I thought i had added the necessary information (new register classes, character
to match for the reg class) however i get the following error message:
"unable to find a register to spill in class"
Can i disable filling/spilling for this register class?
Further, the actual error occurs at reload.c:find_reloads().
The context is the following:
<--
/* The operands don't meet the constraints.
goal_alternative describes the alternative
that we could reach by reloading the fewest operands.
Reload so as to fit it. */
if (best == MAX_RECOG_OPERANDS * 2 + 600)
{
/* No alternative works with reloads?? */
if (insn_code_number >= 0)
fatal_insn ("unable to generate reloads for:", insn);
error_for_asm (insn, "inconsistent operand constraints in an `asm'");
/* Avoid further trouble with this insn. */
PATTERN (insn) = gen_rtx_USE (VOIDmode, const0_rtx);
n_reloads = 0;
return 0;
}
<--
Thank you in advance
Nikolaos Kavvadias
Shared Objects with GCOV
Hi all, I 'm making a shared object for ARM9 with -fprofile-arcs and -ftest-coverage options. GCC version 3.3.2 I 'm making the shared object with in 2 cases : 1) By doing an -fpic over the files to be included in the shared object. 2) By not doing an -fpic over the files to be included in the shared object. In the first case ... I get a segmentation fault at the point where it tries to access the symbol from the shared object. In the second case ... the executable runs like honey. Doubt : Why such a difference? In fact the 1st option should have worked properly? Any special thing done by the Dynamic Linker which the Static Linker does or Dosen't do? Please help. Thanks. Regards -- wrr
Abt RTL expression
hello all,
Sorry i am asking this kind of question.This might be weird to most of you but
i am new to GCC.
Can somebody tell me how to analyze the below instruction pattern
(insn 8 6 9 1 (parallel [
(set (reg/f:SI 32)
(symbol_ref:SI ("t") ))
(clobber (reg:CC 21 cc))
]) -1 (nil)
(nil))
Will i be able to find this pattern in .md files?
what does insn 8 6 9 1 mean?
reg/f ?
for varible declaration why is it needed to clobber CC?
Hope somebody will help me.
Thanks in advance.
Regards,
Shafi
Abt RTL expression
(insn 8 6 9 1 (parallel [
(set (reg/f:SI 32)
(symbol_ref:SI ("t") ))
(clobber (reg:CC 21 cc))
]) -1 (nil)
(nil))
Here is an answer to your first question:
8 6 9 are the serial numbers of the current, previous and next instructions
in the instructions link list;
1 is the serial number of the instruction basic block.
You can read more about the RTL representation of insn in
http://gcc.gnu.org/onlinedocs/gccint/Insns.html.
Also, the following are taken from http://gcc.gnu.org/onlinedocs/gccint/:
clobber indicates something is clobbered in a way that we don't want to
explain.
For example, subroutine calls will clobber some physical registers.
reg/f - In reg expressions, 1 means that the register holds a pointer.
Revital
Re: Abt RTL expression
On Mon, Oct 16, 2006 at 05:20:44AM -0700, Mohamed Shafi wrote:
> hello all,
>
> Sorry i am asking this kind of question.This might be weird to most of you
> but i am new to GCC.
> Can somebody tell me how to analyze the below instruction pattern
>
> (insn 8 6 9 1 (parallel [
> (set (reg/f:SI 32)
> (symbol_ref:SI ("t") ))
> (clobber (reg:CC 21 cc))
> ]) -1 (nil)
> (nil))
>
> Will i be able to find this pattern in .md files?
Probably. Look for at pattern with "movsi" in the name.
> what does insn 8 6 9 1 mean?
8 is the number of the insn, 6 is the number of the previous insn, 9 is
the number of the next insn and 1 is the number of the basic block to which
the insn belongs.
> reg/f ?
This is actually documented (look for REG_POINTER):
http://gcc.gnu.org/onlinedocs/gccint/Flags.html#Flags>.
> for varible declaration why is it needed to clobber CC?
It depends on the target. Some targets modify the condition codes when
copying a value into a register while other targets don't. A third
possibility is that of the m68k, where storing a value in a data register
sets the condition codes while storing a value in an address register leaves
the condition codes unmodified. A fourth possibility is that of the PowerPC,
where this is optional on a per insn basis, but then you wouldn't normally
include the (clobber (reg:CC 21 cc)) version in the machine description.
--
Rask Ingemann Lambertsen.
Control Flow Graphs
Hi, Does anyone know if it is possible to view/access/print out the control flow graphs produced by GCC, either at compilation time, or after compilation has taken place? Thanks for your time. Rob
Re: Control Flow Graphs
Call dump_flow_info() defined in cfg.c to output the pred and succ of each block. You can use this output to construct the CFG. Maybe the software graphviz can help you to visualize the CFG. On 10/16/06, Rob Quill <[EMAIL PROTECTED]> wrote: Hi, Does anyone know if it is possible to view/access/print out the control flow graphs produced by GCC, either at compilation time, or after compilation has taken place? Thanks for your time. Rob -- Paul Yuan www.yingbo.com
Re: g++ -print-prefix or -print-install-prefix
> but in the meantime, I'm wondering if there is a much easier way to go > about this that I'm currently overlooking. ...instead I will rip off comp_base_dir from libgloss.exp. -benjamin
Re: Proposed semantics for attributes in C++ (and in C?)
Mark Mitchell wrote: Yes, I would be happy to explicitly ignore semantic attributes in typedefs as well, with a warning (or even an error). However, I had not realized that we ever did that; I'm surprised that the change that instituted this is so recent. I suppose that explains why we're suddenly seeing a rash of such problems. Jason, as you made this change, do you have any comments on the proposal? I don't think my patch changed the handling of class typedefs; certainly my intent was only to change how we handle class __attribute ((foo)) C Previously we rejected it, now we apply the attributes to the class. Which PRs are you referring to? I'd be inclined to prohibit semantic attributes on typedefs in general. Extending the type system to handle attribute types seems excessively complicated. I think we should define a set of attributes which prevent us from taking the address of a variable with that attribute (packed...anything else?) and check for them at the same places we check for taking the address of a bitfield. Jason
Re: Control Flow Graphs
Thanks very much. I am planning to use this output to help me add some debugging features to GDB, involving temporal logic, but the optimizations involve using a CFG. The dream for my project would be to add an option to GC to print the CFG data to a file, and then parse it and do some analysis on it, and pass it on do GDB to go some light formal methods. I attach below my email to the GDB mailinglist about the aims of the project, for those who are interseted and have not seen it already. Any feedback you have is much appreciated. - Hi, The principle works as follows: It it possible to create an automaton from an LTL formula, with expressions for values of variables as the transitions from one state to the next. Then the tricky part is building an automaton which represents the program. But once you have these it is possible to see if the automaton 'match' and if they do then the property holds. With regards to building the system automaton, at the very simplest you could single step the code, get values of variables at each step and make an appropriate transition on the automaton. However, this is obviously very inefficient, and improvements would most likely be made by building a control flow graph of the program (in some way) and use the nodes of that graph as the points get get values, or something like that. The advantage of including something like this in GDB is that once the property that the programmer expected to hold becomes false, program execution can stop and he programmer can use the standard GDB tools. Well, that'd be the idea anyway. The original idea was to do the same thing but for concurrent programs because there is research which says that using LTL formulas and the automaton technique, you can say whether properties of concurrent programs hold for all the possible interleavings. However, it was decided that that was too complicated, so it was narrowed to non-concurrent programs. --- Thanks again. Rob On 16/10/06, Paul Yuan <[EMAIL PROTECTED]> wrote: Call dump_flow_info() defined in cfg.c to output the pred and succ of each block. You can use this output to construct the CFG. Maybe the software graphviz can help you to visualize the CFG. On 10/16/06, Rob Quill <[EMAIL PROTECTED]> wrote: > Hi, > > Does anyone know if it is possible to view/access/print out the > control flow graphs produced by GCC, either at compilation time, or > after compilation has taken place? > > Thanks for your time. > > Rob > -- Paul Yuan www.yingbo.com
Re: Proposed semantics for attributes in C++ (and in C?)
On Mon, 16 Oct 2006, Jason Merrill wrote: > Mark Mitchell wrote: > > Yes, I would be happy to explicitly ignore semantic attributes in typedefs > > as well, with a warning (or even an error). However, I had not realized > > that we ever did that; I'm surprised that the change that instituted this is > > so recent. I suppose that explains why we're suddenly seeing a rash of such > > problems. Jason, as you made this change, do you have any comments on the > > proposal? > > I don't think my patch changed the handling of class typedefs; certainly my > intent was only to change how we handle > > class __attribute ((foo)) C > > Previously we rejected it, now we apply the attributes to the class. I was referring to the change in extend.texi -the closing brace. It is ignored if the content of the structure, union -or enumerated type is not defined in the specifier in which the -attribute specifier list is used---that is, in usages such as [EMAIL PROTECTED] __attribute__((foo)) bar} with no following opening brace. +the closing brace. The former syntax is preferred. (note that r115086 changed extend.texi but extend.texi doesn't appear to be mentioned in the log message). The old text only covered some of the problem cases, but the statement that attributes were ignored in such cases was still removed. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Proposed semantics for attributes in C++ (and in C?)
Jason Merrill wrote: I don't think my patch changed the handling of class typedefs; certainly my intent was only to change how we handle class __attribute ((foo)) C Previously we rejected it, now we apply the attributes to the class. OK, that certainly makes sense. (That's one of the items in the proposal I wrote up: that you can apply attributes at the point of declaration of a class.) Which PRs are you referring to? One example is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558 However, this is a problem with non-semantic attributes, and not related to your patch. So, I apologize for any aspersions cast. But, it does motivate for writing something down about what we want semantics we want. Here, what I think we want is (as per the proposal) to create a new anonymous typedef for "__attribute__((unused)) A", but consider that the same type as "A". I was pretty sure there were other PRs, but I'm not able to find them now, so perhaps I was dreaming. I thought there were also PRs about typeid and mangling failing (and/or doing the wrong thing) for types with attributes (including scalars with attributes). I'd be inclined to prohibit semantic attributes on typedefs in general. That's certainly simpler. I'm happy to be talked out of that idea. :-) Extending the type system to handle attribute types seems excessively complicated. I think we should define a set of attributes which prevent us from taking the address of a variable with that attribute (packed...anything else?) and check for them at the same places we check for taking the address of a bitfield. That seems like a good idea to me. However, one consequence is that a packed class cannot have member functions (since you'd never be able to get a "this" pointer for them); do you think that's OK? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: FW: How does GCC implement dynamic binding?
My apologies for even bringing it up. It appears we'll most likely do our own analysis. Regards, Greg >The enclosed unclassified technical data / software is being transmitted under License Exception "NLR" and is to be used solely by the individual / organization to whom it is addressed. Diversion contrary to U.S. Export Administration Regulations is prohibited. -Original Message- From: Robert Dewar [mailto:[EMAIL PROTECTED] Sent: Saturday, October 14, 2006 10:27 AM To: David Daney Cc: Michael Eager; Lacefield, Greg (CNS COE); gcc@gcc.gnu.org Subject: Re: FW: How does GCC implement dynamic binding? David Daney wrote: > Perhaps you are right, but it would not surprise me if there were > commercial entities based around FOSS that would provide that type of > support. Certainly for instance AdaCore is able to provide this kind of certification for its customers using its commercial version of GNAT Pro (an Ada compiler based on GNAT Pro), and perhaps for example Code Sourcery might be able to provide similar certification for a product that they provide, but if you are looking for certification of some publicly available version, I think you are out of luck. It reminds me of a time in 1999, when someone demanded that we provide Y2K compliance guarantees for the public version of GNAT. Of course I declined (for one thing I had no way of knowing exactly what he was using). He was outraged, and said "well in that case I will have to stop using this version". I explained that this was indeed the case, and offered the possibility of using the commerical version supported by us, but that's not he wanted to hear, he wanted to use the freely available public version (which is fine if it meets someones needs), but wanted someone to guarantee compliance (which is not fine).
Re: Dead include file: dwarf.h ?
Steven Bosscher <[EMAIL PROTECTED]> writes: > As far as I can tell, dwarf.h is not included anywhere in gcc/ > or any of its subdirectories. Is there any reason not to remove > this file? I think dwarf.h was orphaned when dwarfout.c was removed in 2003. I think we should remove it. Ian
Re: Issue with hard regs
[EMAIL PROTECTED] writes: > i'm in the process of coding a GCC backend for a certain RISC-like > architecture. > Its register architecture consists of an integer register file (32 regs) and > two > additional hard regs that should be programmer visible. Accesses to these hard > regs are also emitted related to certain RTL patterns (divmoddi4 and > udivmoddi4 > for which these two hard regs should be written). Split 64-bit moves may or > may > not use these regs as well. Sounds like MIPS. > I thought i had added the necessary information (new register classes, > character > to match for the reg class) however i get the following error message: > > "unable to find a register to spill in class" Note that that error message is very general and can have a number of different underlying causes. > Can i disable filling/spilling for this register class? Sure: make the registers fixed. Or look at how the MIPS port handles HI and LO, with particular reference to mips_secondary_reload_class. Ian
Re: Proposed semantics for attributes in C++ (and in C?)
Joseph S. Myers wrote:
I was referring to the change in extend.texi
-the closing brace. It is ignored if the content of the structure, union
-or enumerated type is not defined in the specifier in which the
-attribute specifier list is used---that is, in usages such as
[EMAIL PROTECTED] __attribute__((foo)) bar} with no following opening brace.
+the closing brace. The former syntax is preferred.
That passage has nothing to do with typedefs. The change is that
previously, if we saw
class __attribute ((visibility (hidden))) C;
we would ignore the attribute, now we record it.
My change to the previous paragraph now seems excessive, however:
-You may specify the @code{aligned} and @code{transparent_union}
-attributes either in a @code{typedef} declaration or just past the
-closing curly brace of a complete enum, struct or union type
[EMAIL PROTECTED] and the @code{packed} attribute only past the closing
-brace of a definition.
+You may specify type attributes either in a @code{typedef} declaration
+or in an enum, struct or union type declaration or definition.
I didn't notice the distinction this passage was trying to make between
packed and other attributes, just that it was an incomplete list. In
removing the incomplete list I also removed the useful separation.
Jason
Re: [PATCH] Relocated compiler should not look in $prefix.
"Carlos O'Donell" <[EMAIL PROTECTED]> writes: > A relocated compiler should not look in $prefix. I agree. I can't approve your patches, though. Ian
How can a front-end know what integer mode corresponds to int_fastN_t?
Hi all, For Fortran 2003 standard conformance, the Fortran front-end has to know at compile-time what integer mode corresponds to some C99 types, like intmax_t, intN_t, int_leastN_t, int_fastN_t. For intN_t and int_leastN_t, I can see how to get them by looking at the width of the different integer modes. For intmax_t, it is defined in c-common.h as: #define INTMAX_TYPE ((INT_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \ ? "int"\ : ((LONG_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \ ? "long int"\ : "long long int")) But I cannot see how the front-end can know the integer mode for int_leastN_t. We're likely to include this functionality for the 4.3 release, so I'll be happy to get a large number of suggestions around on how to implement that. FX
Re: g++ -print-prefix or -print-install-prefix
Benjamin Kosnik wrote: For testing outside of the build directory, it would be convenient to have $SUBJECT. This could be used in conjunction with -dumpversion to create on-the-fly include and library directory paths for C++ includes in a sane manner, much like the following: Why do you need this? For installed-compiler testing, the compiler already searches the obvious places. (I'm not trying to be cute: I'm genuinely curious.) I agree that it would be nice if -print-search-dirs listed include directories. It already lists the paths searched for programs and libraries, so that seems like a logical place to add header directories. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: make bootstrap .. success SUSE 9.3
[EMAIL PROTECTED]:/e/gcc/test_pg> ../gcc-4.1.1/config.guess i686-pc-linux-gnu [EMAIL PROTECTED]:/e/gcc/test_pg> /e/gcc4.1.1_install/usr/local/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure Thread model: posix gcc version 4.1.1 [EMAIL PROTECTED]:/e/gcc/test_pg> cat /etc/issue Welcome to SuSE Linux 9.3 (i586) - Kernel \r (\l). [EMAIL PROTECTED]:/e/gcc/test_pg> uname --version uname (GNU coreutils) 5.3.0 Written by David MacKenzie. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:/e/gcc/test_pg> uname -a Linux linux 2.6.16-rt20-default #1 PREEMPT Fri Aug 4 13:03:21 CDT 2006 i686 i686 i386 GNU/Linux [EMAIL PROTECTED]:/e/gcc/test_pg> rpm -q glibc glibc-2.3.4-23 Question: gprof is not included as part of the bin utils but gcov is? Elden Crom Tucson Embedded Systems, Inc 520-575-7283 x141 Fax: 520-575-5563 Cell: 520-429-2771 Email:[EMAIL PROTECTED] 5620 N. Kolb Road Suite 160 Tucson, AZ 85750-1384
Re: [PATCH] Relocated compiler should not look in $prefix.
Ian Lance Taylor wrote: "Carlos O'Donell" <[EMAIL PROTECTED]> writes: A relocated compiler should not look in $prefix. I agree. I can't approve your patches, though. This patch is OK, once we reach Stage 1. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Issue with hard regs
Hi Ian > > > Can i disable filling/spilling for this register class? > > Sure: make the registers fixed. > > Or look at how the MIPS port handles HI and LO, with particular > reference to mips_secondary_reload_class. > > Ian what i'm trying to do is to code a backend for a "standard" DLX. Most things work (everything operating on SI,HI,QI types) but i have problems specifically with "long division". I.e. there is something wrong with either "libgcc2.c" (most improbable) or my backend. I thought borrowing the HI/LO concept for passing the remainder/quotient when "emulating" the 64-bit divisions by "[u]divsi3" (which calls udivmoddi4). I have resorted to s'thing like this that doesn't need hi-lo registers. I have t8/t9 fixed for this: return "bnez\t%2,4\n\tbreak\t7\n1:\n\tadd\t%0, $zero, $t8\n\tadd\t%3, $zero, $t9"; (as in MIPS' mips_output_division()) I'll have a look to mips_secondary_reload_class, however now i don't get spilling/filling errors. I have a question: libgcc2.c is pretty stable, right? I mean i shouldn't looking for something going wrong with it. thanks in advance Nikolaos Kavvadias
Re: Issue with hard regs
[EMAIL PROTECTED] writes: > I'll have a look to mips_secondary_reload_class, however now i don't get > spilling/filling errors. I have a question: libgcc2.c is pretty stable, right? > I mean i shouldn't looking for something going wrong with it. Right, libgcc2.c is quite stable. In a normal build it is the first complicated code to be compiled with the new compiler, so it is a normal place for reload problems to arise. Ian
Re: How can a front-end know what integer mode corresponds to int_fastN_t?
FX Coudert <[EMAIL PROTECTED]> writes: > Hi all, > > For Fortran 2003 standard conformance, the Fortran front-end has to > know at compile-time what integer mode corresponds to some C99 types, > like intmax_t, intN_t, int_leastN_t, int_fastN_t. > > For intN_t and int_leastN_t, I can see how to get them by looking at > the width of the different integer modes. For intmax_t, it is defined > in c-common.h as: > > #define INTMAX_TYPE ((INT_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \ > ? "int"\ > : ((LONG_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \ > ? "long int"\ > : "long long int")) > > But I cannot see how the front-end can know the integer mode for > int_leastN_t. We're likely to include this functionality for the 4.3 > release, so I'll be happy to get a large number of suggestions around > on how to implement that. It's a property of the ABI on the target. The only way to know is to have someone (or something) tell you. Even the macro above can be redefined by a target. One nice thing would be that if we actually had GCC know about all the contents of stdint.h, then maybe GCC could provide it; we have a policy that GCC provides all the headers of a freestanding implementation, and this is the only one missing.
Re: Proposed semantics for attributes in C++ (and in C?)
Mark Mitchell <[EMAIL PROTECTED]> writes:
> We have a number of C++ PRs open around problems with code like this:
>
>struct S {
> void f();
> virtual void g();
>};
>
>typedef __attribute__((...)) struct S T;
>
> If the attribute makes any substantive change to S (e.g., changes its
> size, alignment, etc.) then bad things happen. For example, the
> member functions of "S" have expectations about the layout of "S" that
> are not satisfied if they are called with a "T". Depending on the
> attribute and circumstances, we do all manner of bad things, including
> ICE, generate wrong code, etc.
>
> For a while now, I've been promising to propose semantics for these
> constructs. Here is a sketch of the semantics that I think we should
> have. (I say a sketch because I have not attempted to write
> standardese.)
>
> All attributes must be classified as either "semantic" or
> "non-semantic" attributes. A "semantic" attribute is one which might
> affect code-generation in any way. A "non-semantic" attribute cannot
> affect code-generation. For example, "used" and "deprecated" are
> non-semantic attributes; there is no way to observe, by looking at an
> object file, whether or not a class has been marked with one of these
> attributes. In contrast, "packed" is a semantic attribute; the size
> of a class is different depending on whether or not it is "packed".
>
> Any attribute may be applied at the point of definition of a
> class. These attributes (whether semantic or non-semantic) apply to
> the class. For example, if the class is packed, then the member
> functions expect the "this" pointer to point to the packed class.
>
> A typedef declaration which adds only non-semantic attributes is
> always valid. As with other typedefs, the typedef declaration creates
> a new name for an existing type. The type referred to by that name is
> the same type as the original type. However, the *name* has
> additional properties, implied by the (non-semantic) attributes. For
> example, using a "deprecated" name for a type results in a deprecation
> warning. But, a function declared to take a parameter with the
> non-deprecated name may be passed a parameter with the "deprecated"
> name.
>
> A typedef declaration which adds semantic attributes to a class type,
> other than POD classes with no explicitly declared members other than
> data members, to arrays of such classes, to arrays of such arrays,
> etc., is invalid. (POD-ness alone is not satisfactory, as PODs may
> contain function members, and I think dealing with static data members
> and typedef members is not worth the trouble.)
>
> A typedef declaration which adds semantic attributes to a POD class
> type with no function members is valid, but creates an entirely new
> type, different from all other types except others formed by adding
> the same combination of semantic attributes to the same original class
> type. In the example above, if the typedef adds a semantic attribute,
> you may not pass an "S" to a function expecting a "T" or vice versa.
> Neither may you pass an "S*" to a function expecting a "T*", without
> an explicit reinterpret_cast. The name of "T", for linkage purposes,
> is "T", and there is no implicit "T::S" type; instead, however, there
> is a "T::T" type. (Various consequences follow; for example,
> typeid(T) gives you a type_info object that indicates that the name of
> the type is "T".) References to the original type from within the
> types of the members of the class still refer to the original class.
> For example, in:
>
>struct S {
> char c;
> S* next;
>};
>typedef __attribute__((packed)) S T;
>
> the data member T::next has type "S*", not "T*".
>
> A typedef declaration which adds semantic attributes to a non-class
> type is valid, but again creates an entirely new type. (We might want
> a special exception to the "entirely new type" rule for the "mode"
> attribute, declaring that "typedef __attribute__((mode(DI))) int LL"
> is equivalent to "typedef long long LL;" on platforms where "long
> long" has DImode.) So,
>
>typedef S* P;
>typedef __attribute__((...)) P Q;
>
> creates a type "Q" that is incompatible with "S*" if the attribute is
> semantic. However, the type of "*Q" is still "S". It is invalid to
> do anything that would require either type_info or a mangled name for
> "Q", including using it as an argument to typeid, thowing an exception
> of a type involving "Q", or declaring a template to take a parameter
> of a type involving "Q". (We could relax some of these restrictions
> in future, if we add mangling support for attributes.)
Declaring a function which takes a 'Q' also requires the mangled name of 'Q'.
> A variable declaration involving attributes, like:
>
>__attribute__((...)) S v;
>
> is treated as syntactic sugar for:
>
>typedef __attribute__((...)) S T;
>T v;
>
> where T is some invented type name different from all others
Re: Abt RTL expression
A lot of thanks for the pointer...
>Probably. Look for at pattern with "movsi" in the name.
In th document
http://gcc.gnu.org/onlinedocs/gccint/Insns.html#Insns
it is said that "An integer that says which pattern in the machine description
matches
this insn, or −1 if the matching has not yet been attempted.Such matching is
never attempted and this field remains −1 on an insn
whose pattern consists of a single use, clobber "
The integer in my pattern is -1. In fact integer for all the insn for a program
(980602-2.c) like
struct {
unsigned bit : 30;
} t;
int main()
{
if (!(t.bit++))
exit (0);
else
abort ();
}
is -1 for my target. Can you explain this?
Thanks in advance.
Regards,
Shafi
- Original Message
From: Rask Ingemann Lambertsen <[EMAIL PROTECTED]>
To: Mohamed Shafi <[EMAIL PROTECTED]>
Cc: gcc@gcc.gnu.org
Sent: Monday, October 16, 2006 7:28:42 PM
Subject: Re: Abt RTL expression
On Mon, Oct 16, 2006 at 05:20:44AM -0700, Mohamed Shafi wrote:
> hello all,
>
> Sorry i am asking this kind of question.This might be weird to most of you
> but i am new to GCC.
> Can somebody tell me how to analyze the below instruction pattern
>
> (insn 8 6 9 1 (parallel [
> (set (reg/f:SI 32)
> (symbol_ref:SI ("t") ))
> (clobber (reg:CC 21 cc))
> ]) -1 (nil)
> (nil))
>
> Will i be able to find this pattern in .md files?
Probably. Look for at pattern with "movsi" in the name.
> what does insn 8 6 9 1 mean?
8 is the number of the insn, 6 is the number of the previous insn, 9 is
the number of the next insn and 1 is the number of the basic block to which
the insn belongs.
> reg/f ?
This is actually documented (look for REG_POINTER):
http://gcc.gnu.org/onlinedocs/gccint/Flags.html#Flags>.
> for varible declaration why is it needed to clobber CC?
It depends on the target. Some targets modify the condition codes when
copying a value into a register while other targets don't. A third
possibility is that of the m68k, where storing a value in a data register
sets the condition codes while storing a value in an address register leaves
the condition codes unmodified. A fourth possibility is that of the PowerPC,
where this is optional on a per insn basis, but then you wouldn't normally
include the (clobber (reg:CC 21 cc)) version in the machine description.
--
Rask Ingemann Lambertsen.
