Re: Bootstrap comparison failure
Paolo, what do you think? I think I agree. After all when I added the "ln -s" support we did not have anything remotely similar to the current logic for "make all", "make unstage", "make stage". Paolo
Re: Found error in g77 documentation
> Sorry for wrting to this mail address, but I did not find anywhere > in the bug reporting documentation how to report a bug on > the...documentation itself You can report documentation bugs in the GCC Bugzilla bug tracking system. You can read more on the subject at: http://gcc.gnu.org/bugs.html Thanks for taking the time! Ben
Re: Bootstrap comparison failure
On Sun, 2005-12-18 at 16:49, Daniel Jacobowitz wrote:
> On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> > Looks like the new toplevel bootstrap infrastructure broke
> > bootstrapping on OpenBSD. I get a bootstrap comparison which is
> > caused by differences in the compilation directory encoded in the
> > object files from different stages.
> >
> > Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
> >
> > gcc_cv_prog_ln_s_dir=${gcc_cv_prog_ln_s_dir=no}
> >
> > fixes things. I'm not sure what's the source for this problem, but
> > obviously somewhere OpenBSD is canonicalising a path where most other
> > OSes aren't.
> >
> > This is on OpenBSD/amd64 3.8-current (for which I'm hacking up GCC
> > support right now), but no doubt this won't be different on other
> > OpenBSD ELF platforms, such as OpenBSD/i386.
> >
> > Based on what I see on OpenBSD I fail to understand how the "ln -s"
> > approach could ever work on any OS. Assuming that I'm not the only
> > one trying to bootstrap GCC, I'm obviously missing something, so any
> > hints would be appreciated.
>
> I'm sure you have access to some non-OpenBSD platforms; try it and see
> :-) My guess is that you're using a shell that does not set the
> environment variable 'PWD', or sets it to a canonicalized path; see
> libiberty/getpwd.c.
I think the problem is PWDCMD (defaults to pwd) in the top-level
makefile. If your shell builds in pwd, then things will work. If it
doesn't then you'll get /bin/pwd which gives the canonical path. Bash
has a built-in pwd, and since on Linux /bin/sh is bash in disguise, it
still uses the builtin. A traditional Berkeley sh doesn't do this.
'info pwd' on Linux says:
`pwd' prints the fully resolved name of the current directory.
That is, all components of the printed name will be actual
directory names--none will be symbolic links.
I suspect that if you run a bootstrap of gcc on Linux with
PWDCMD=/bin/pwd it will fail too.
R.
Re: Add revision number to gcc version?
On Fri, 2005-12-16 at 05:02, H. J. Lu wrote: > > In my patch, gcc/REVISION is created by gcc_update. If you don't use > gcc_update, gcc/REVISION may not be there. > > In any case, when we agree on what to put in gcc/REVISION, I can > provide a new patch. Maybe we should just set up the commit filters so that a new version of REVISION is committed with each check-in. That way it will work with every check-out method, and what's more we get the date/time of the commit rather than the date/time of the checkout. R.
Re: Huge compile time regressions
Daniel Berlin wrote: On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote: Hi, Someone caused a >10% compile time regression yesterday for CSiBE, see http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs Gr. Steven This is very very bad. Joern, i'd imagine this was your patch. I think this is related to using register liveness information from flow. My original if-conversion patch http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03281.html used a simple linear-time algorithm to identify registers that are local to each basic block. I can think of two things that could cause a noticable slowdown: - comparison of global_live_at_end in struct_equiv_init. Most call sites call gcc_unreachable when struct_equiv_init fails. If an additional parameter is passed into struct_equiv_init to tell if the the comparison may fail, we can optimize the sanity check out for !ENABLE_CHECKING. - The call to update_life_info_in_dirty_blocks when one of the compared blocks is dirty. I'm not sure if we could get away with doing a local update, and/or starting the update only for the blocks under consideration. If we don't have to do the global_live_at_end comparison, we can probably also skip the update if only one of the blocks is dirty, and use the global_live_at_end from the block that is not dirty. A further improvement might be to remove the regset comparison from struct_equiv_init altogether, and only make sure we use a global_live_at_end that is right for at least one of the blocks. The regsets can be compared later when we have matched all the edges, maybe even the entire block. We could also go back to makling sure we have consistent data flow information at the start of the pass, and keep the bits that we need up-to-date as we go along.
Re: How to rebuild stage 1?
(But let's give Paolo some time to address the technical issues first; we are still in stage 1, so only developers, packagers, and brave testers are supposed to use what is going to become GCC 4.2. ;-) Also the reason why I've been collecting issues so far, instead of posting all patches for approval, is that you can still use --disable-bootstrap to get the old scheme. Paolo
Re: Bootstrap comparison failure
On Mon, Dec 19, 2005 at 01:18:21PM +, Richard Earnshaw wrote: > I think the problem is PWDCMD (defaults to pwd) in the top-level > makefile. If your shell builds in pwd, then things will work. If it > doesn't then you'll get /bin/pwd which gives the canonical path. Bash > has a built-in pwd, and since on Linux /bin/sh is bash in disguise, it > still uses the builtin. A traditional Berkeley sh doesn't do this. > > 'info pwd' on Linux says: > > `pwd' prints the fully resolved name of the current directory. > That is, all components of the printed name will be actual > directory names--none will be symbolic links. > > I suspect that if you run a bootstrap of gcc on Linux with > PWDCMD=/bin/pwd it will fail too. Yes, I saw a suggestion about this on IRC, but I tried it - it doesn't fail. The path that matters is not one ever returned by PWDCMD but the one seen in $PWD by GCC; the only cd that's happened at that point is done in the shell, by the toplevel Makefile, into 'gcc'. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Add revision number to gcc version?
On Mon, Dec 19, 2005 at 01:26:18PM +, Richard Earnshaw wrote: > On Fri, 2005-12-16 at 05:02, H. J. Lu wrote: > > > > > In my patch, gcc/REVISION is created by gcc_update. If you don't use > > gcc_update, gcc/REVISION may not be there. > > > > In any case, when we agree on what to put in gcc/REVISION, I can > > provide a new patch. > > Maybe we should just set up the commit filters so that a new version of > REVISION is committed with each check-in. That way it will work with > every check-out method, and what's more we get the date/time of the > commit rather than the date/time of the checkout. What do you put in REVISION? Can you ask svn for revision number before check-in? If not, do you need 2 check-ins to update REVISION for each check-in? H.J.
An odd behavior of dynamic_cast
Hi all,
This is my first post. :-)
Recently, I found an odd behavior about dynamic_cast
across shared libraries.
This is my box:
linux kernel-2.4.21
gcc-3.4.3
(Check out my test_case.tar.bz2 for complete source
codes.)
I defined these classes and functions in libbase.so:
struct Base; // <- polymorphic
struct Tag; // <- non-polymorphic
struct VirtualTag; // <- polymorphic
Tag* getTag(Base* base)
{
return dynamic_cast(base);
}
VirtualTag* getVirtualTag(Base*)
{
return dynamic_cast(base);
}
I also defined these derived classes in libderived.so:
struct Derived0 : Base, Tag;
struct Derived1 : Base, VirtualTag;
Then I tested getTag() and getVirtualTag() in two ways:
test0: linked to libderived.so (and libbase.so) at
build time.
test1: dynamically loads libbase.so and libderived.so
by using dlopen() at runtime.
These two test cases basically does the same thing:
1. create Derived(0|1) instance.
2. do dynamic_cast by using get[Virtual]Tag()
function.
In test0, both getTag() and getVirtual() are ok (returns
non-NULL value).
But in test1, getTag() returns NULL while getVirtualTag()
returns non-NULL.
I expected that I got the same results in both cases...
In test1, typeid(Tag) is not unique.
Could anyone tell which behavior is right or bug?
Thanks.
--
STOP HIV/AIDS.
Yahoo! JAPAN Redribbon Campaign 2005
http://pr.mail.yahoo.co.jp/redribbon/
test_cast.tar.bz2
Description: test_cast.tar.bz2
Re: creating a new branch webpage
On Fri, 16 Dec 2005 [EMAIL PROTECTED] wrote: > I'm opening a new branch and would like to request some assistance > updating the online material. Specifically, how do I add the branch > information to http://gcc.gnu.org/svn.html#devbranches. Also, would it be > possible to create an associated project page (e.g., > http://gcc.gnu.org/projects/tree-profiling.html)? I saw the responses you got, and that you checked in patches already. These look fine; would you mind sending them to gcc-patches as well? And have you considered adding a link from projects/index.html to your new page as well? That will help make it more public, I hope. Gerald
Re: Bootstrap comparison failure
On Mon, 2005-12-19 at 13:58, Daniel Jacobowitz wrote: > > I suspect that if you run a bootstrap of gcc on Linux with > > PWDCMD=/bin/pwd it will fail too. > > Yes, I saw a suggestion about this on IRC, but I tried it - it doesn't > fail. The path that matters is not one ever returned by PWDCMD but the > one seen in $PWD by GCC; the only cd that's happened at that point is > done in the shell, by the toplevel Makefile, into 'gcc'. Hmm, so it's cd that's 'at fault'... Here's a snippet from the NetBSD sh(1) man page: pwd [-LP] Print the current directory. If -L is specified the cached value (initially set from PWD) is checked to see if it refers to the current directory, if it does the value is printed. Otherwise the current directory name is found using getcwd(3). The environment variable PWD is set to printed value. The default is pwd -L, but note that the builtin cd command doesn't currently support -L or -P and will cache (almost) the absolute path. If cd is changed, pwd may be changed to default to pwd -P.
RFC: peephole vs RTX_FRAME_RELATED_P
On i386 we replace (add sp -4) with (push reg). This generates faster
and smaller code.
However, we are not copying RTX_FRAME_RELATED_P from the old
instructions to the new, and so we are not emitting unwind information
for the stack pointer adjustment. The breaks stack traces on gcj, and
I suspect it breaks a bunch of stuff elsewhere too.
This very crude patch sets RTX_FRAME_RELATED_P on every one of the new
instructions if any of the old instructions had RTX_FRAME_RELATED_P
set. It seems to do the trick, but I suspect there must be a more
subtle way to do it.
Can anyone suggest a neater way to do this?
Without this patch, for
java.lang.Throwable.Throwable(java.lang.String) we get
00a326a8 :
a326a8: 56 push %esi
a326a9: 53 push %ebx
a326aa: 50 push %eax <=== ** This is the insn
generated by peephole **
a326ab: e8 00 00 00 00 call a326b0
a326b0: 5b pop%ebx
00058f08 001c 0003252c FDE cie=000269e0 pc=00a328f8..00a3292e
Augmentation data: 00 00 00 00
DW_CFA_advance_loc: 1 to 00a328f9
DW_CFA_def_cfa_offset: 8
DW_CFA_advance_loc: 1 to 00a328fa
DW_CFA_def_cfa_offset: 12
DW_CFA_offset: r3 at cfa-12
DW_CFA_offset: r6 at cfa-8
DW_CFA_nop
after the patch, we get
0005946c 0020 000328e4 FDE cie=00026b8c pc=00a326a8..00a326de
Augmentation data: 00 00 00 00
DW_CFA_advance_loc: 1 to 00a326a9
DW_CFA_def_cfa_offset: 8
DW_CFA_advance_loc: 1 to 00a326aa
DW_CFA_def_cfa_offset: 12
DW_CFA_advance_loc: 1 to 00a326ab
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r0 at cfa-16
DW_CFA_offset: r3 at cfa-12
DW_CFA_offset: r6 at cfa-8
Here's a trivial test case:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello, World!");
new Throwable().printStackTrace();
}
}
$ ~/gcc/install/bin/gcj Hello.java --main=Hello -g
$ LD_LIBRARY_PATH=~/gcc/install/lib ./a.out
Hello, World!
java.lang.Throwable
at Hello.main (Hello.java:5)
Andrew.
2005-12-19 Andrew Haley <[EMAIL PROTECTED]>
* recog.c (peephole2_optimize): Copy RTX_FRAME_RELATED_P from old
instructions to new instructions.
Index: recog.c
===
--- recog.c (revision 108424)
+++ recog.c (working copy)
@@ -3107,6 +3107,7 @@
int match_len;
rtx note;
bool was_call = false;
+ bool frame_related = false;
/* Record this insn. */
if (--peep2_current < 0)
@@ -3122,6 +3123,14 @@
try = peephole2_insns (PATTERN (insn), insn, &match_len);
if (try != NULL)
{
+ {
+ rtx old_insn = insn;
+ for (i = 0; i <= match_len; ++i)
+ {
+ frame_related |= RTX_FRAME_RELATED_P (old_insn);
+ old_insn = NEXT_INSN (old_insn);
+ }
+ }
/* If we are splitting a CALL_INSN, look for the CALL_INSN
in SEQ and copy our CALL_INSN_FUNCTION_USAGE and other
cfg-related call notes. */
@@ -3179,6 +3188,16 @@
break;
}
+ if (frame_related)
+ {
+ rtx new_insn = try;
+ while (new_insn != NULL_RTX)
+ {
+ RTX_FRAME_RELATED_P (new_insn) = true;
+ new_insn = NEXT_INSN (new_insn);
+ }
+ }
+
i = match_len + peep2_current;
if (i >= MAX_INSNS_PER_PEEP2 + 1)
i -= MAX_INSNS_PER_PEEP2 + 1;
Does lang_checks_parallel only support check-gcc?
There are [EMAIL PROTECTED] gcc]$ grep lang_checks Makefile.in lang_checks=check-gcc lang_checks_parallel = $(lang_checks:=//%) $(lang_checks_parallel): site.exp $(lang_checks): check-% : $(TESTSUITEDIR)/site.exp Will adding @check_languages@ to lang_checks to make it support other languages? H.J.
Re: RFC: peephole vs RTX_FRAME_RELATED_P
Andrew Haley <[EMAIL PROTECTED]> writes: > On i386 we replace (add sp -4) with (push reg). This generates faster > and smaller code. > > However, we are not copying RTX_FRAME_RELATED_P from the old > instructions to the new, and so we are not emitting unwind information > for the stack pointer adjustment. The breaks stack traces on gcj, and > I suspect it breaks a bunch of stuff elsewhere too. > > This very crude patch sets RTX_FRAME_RELATED_P on every one of the new > instructions if any of the old instructions had RTX_FRAME_RELATED_P > set. It seems to do the trick, but I suspect there must be a more > subtle way to do it. > > Can anyone suggest a neater way to do this? I don't have a suggestion for a neater way to do this, but I do want to note that, in the general case, just copying RTX_FRAME_RELATED_P is insufficient. We also need to copy any REG_FRAME_RELATED_EXPR reg notes. Ian
Re: RFC: peephole vs RTX_FRAME_RELATED_P
Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > On i386 we replace (add sp -4) with (push reg). This generates faster > > and smaller code. > > > > However, we are not copying RTX_FRAME_RELATED_P from the old > > instructions to the new, and so we are not emitting unwind information > > for the stack pointer adjustment. The breaks stack traces on gcj, and > > I suspect it breaks a bunch of stuff elsewhere too. > > > > This very crude patch sets RTX_FRAME_RELATED_P on every one of the new > > instructions if any of the old instructions had RTX_FRAME_RELATED_P > > set. It seems to do the trick, but I suspect there must be a more > > subtle way to do it. > > > > Can anyone suggest a neater way to do this? > > I don't have a suggestion for a neater way to do this, but I do want > to note that, in the general case, just copying RTX_FRAME_RELATED_P is > insufficient. We also need to copy any REG_FRAME_RELATED_EXPR reg > notes. Thanks for that. Yes, I see. gcc does seem to be able to get the information it needs to generate the unwinder by looking at the pattern, but I can imagine circumstances where that won't be appropriate. The problem that is bugging me is if there is more than one instruction in the repleacement sequence, which one do you copy the REG_FRAME_RELATED_EXPR to? Andrew.
Re: RFC: peephole vs RTX_FRAME_RELATED_P
Andrew Haley <[EMAIL PROTECTED]> writes: > The problem that is bugging me is if there is more than one > instruction in the repleacement sequence, which one do you copy the > REG_FRAME_RELATED_EXPR to? I think an algorithm which should work fairly reliably in the general case is: 1) Are there any old insns with RTX_FRAME_RELATED_P set? If no, stop. 2) For each old insn with RTX_FRAME_RELATED_P set: a) if insn has a REG_FRAME_RELATED_EXPR note, add it to the list; b) otherwise, insn should be a PARALLEL or SEQUENCE or SET; add the insn to the list. 3) Set RTX_FRAME_RELATED_P on last new insn. 4) If there is more than one entry on list, turn it into a PARALLEL (see dwarf2out_frame_debug_expr). Otherwise take first insn on list. 5) Put the result of 4 in a REG_FRAME_RELATED_EXPR note on last new insn. Ian
Re: Add revision number to gcc version?
Subversion provides an "opt-in" version of keyword substitution, and provides a $Revision$ keyword. It might take a little scriptery to get that into the form GCC wants. http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.keywords
Re: Add revision number to gcc version?
On Dec 19, 2005, at 2:56 PM, Jim Blandy wrote: Subversion provides an "opt-in" version of keyword substitution, and provides a $Revision$ keyword. But it doesn't do what people really want it to by design. :-(
Re: i was told that i could get a awnser to this question here.
On Dec 18, 2005, at 2:17 PM, Kevin Andrew Kaploe wrote: are they telling the truth? Simple answer, Yes. The long answer is off-topic for this list. A hint at the long answer lies in dependencies. If those are precisely in sync, then there is no point at recompilation. If they are out of sync, then recompilation brings them in sync.
Re: Add revision number to gcc version?
On 12/19/05, Mike Stump <[EMAIL PROTECTED]> wrote: > On Dec 19, 2005, at 2:56 PM, Jim Blandy wrote: > > Subversion provides an "opt-in" version of keyword substitution, and > > provides a $Revision$ keyword. > > But it doesn't do what people really want it to by design. :-( And that would be?
Re: Add revision number to gcc version?
On Dec 19, 2005, at 5:34 PM, Jim Blandy wrote: On 12/19/05, Mike Stump <[EMAIL PROTECTED]> wrote: But it doesn't do what people really want it to by design. :-( And that would be? http://subversion.tigris.org/faq.html#version-value-in-source I would like something, that substitutes automatically, works on svn co and svn up and can be used to obtain the exact sources I was playing with, given say a hard coded url and branch name. I can promise to only co or up the whole tree and to not have any modifications in the tree. Ideally, I'd like this to be stable, so that the number doesn't increment if there are no actual changes in my tree, though, this last point isn't critical.
#pragma pack vs. zero-width bitfields
PR 22275 is about a change in the structure layout used by GCC when #pragma pack is mixed with zero-width bitfields. In particular, in GCC 3.3 and earlier, zero-width bitfields still forced the next element to be placed on an alignment boundary, just as they do in unpacked structures. In GCC 3.4 and later, zero-width bitfields no longer have this effect, when used within a structure. I believe the older behavior was better. The entire purpose for a zero-width bitfield is to make an alignment request. So, we should assume that if the user wrote that, even within the scope of #pragma pack, they had a reason for doing so. #pragma pack should pack the things that are not explicitly aligned, but it should no more pack the field following a zero-width bitfield than it should a field that has an explicit alignment attribute. As a result, I believe that we should change the behavior back in GCC 4.1. We should not change GCC 3.4.x or GCC 4.0.x because that would be an ABI change within a single release branch. I know this was discussed previously to some extent, but I'm not sure if we reached consensus. I'm going to interpret silence as assent if nobody objects within a few days. So, any disagreements? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713
Re: make all vs make bootstrap
Hi Paolo > It supports all the bells and whistles like bubblestraps and > restageN, which help during development. make restrap (taking a > non-bootstrap build and using it as stage1) is not supported. make > restageN is called make all-stageN, and there is also make > all-stageN-gcc to rebuild gcc only. There is no equivalent to > quickstrap, even though it can be added if there's demand. I see that gcc/doc/makefile.texi is now out of date. Can you update it so that we have a reference for the new targets? Thanks, Ben
struct: link to next field
Hi everybody,
I am working on the intermediary tree representation of GCC right now
(writing a parser for it). I have a question regarding that.
If I declare a struct containing 2 fields like that in C:
struct foo {
int var_a;
char var_b;
} afoo;
afoo.var_a = 0;
afoo.var_b = 'a';
the abstract syntax tree I get (with -fdump-tree-original) does not
include information about the 2nd field (var_b) at the point of
declaration of the struct type. The declaration of 'var_b" is done only
at the point where I use it. That can be seen from the following struct
type declaration (in intermediary representation):
@147var_decl name: @149 type: @150 scpe: @1
srcp: InitAutoTestA.c:37 size: @6
algn: 32 used: 1
@149identifier_node strg: "afoo" lngt:4
@150record_type name: @153 size: @6 algn: 32
struct flds: @154 fncs: @155
binf: @156
@152expr_stmtline: 40 expr: @159 next: @160
@153type_declname: @161 type: @150 scpe: @1
srcp: InitAutoTestA.c:34 artificial
@154field_decl name: @162 type: @7 scpe: @150
srcp: InitAutoTestA.c:35 public
size: @10 algn: 32 bpos: @163
@155function_declname: @164 type: @165 scpe: @150
srcp: InitAutoTestA.c:34 artificial
operator assign member
public args: @166 undefined
static
@156binfotype: @150
@161identifier_node strg: "foo " lngt:3
@162identifier_node strg: "var_a " lngt:5
@163integer_cst type: @13 low : 0
the flds field of the record_type (@150) points to the field_decl of
var_a (@154), but there is not link to the field_decl of var_b at that
place.
However the GCC documentation (section 9.4.2 Classes) says: "Almost all
non-function members are available on the TYPE_FIELDS list. Given one
member, the next can be found by following the TREE_CHAIN." But I see no
chain or list in the present case.
I am using gcc version 3.3.5 (under Debian Linux).
Has anyone an idea why there is no link to the next field?
Cheers,
Pat
Re: Add revision number to gcc version?
On Mon, Dec 19, 2005 at 02:56:43PM -0800, Jim Blandy wrote: > Subversion provides an "opt-in" version of keyword substitution, and > provides a $Revision$ keyword. It might take a little scriptery to > get that into the form GCC wants. > > http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.keywords Assuming we put --- revision $Revision$ --- in gcc/REVISION. How will it be updated? H.J.
Re: Add revision number to gcc version?
On Mon, Dec 19, 2005 at 06:04:46PM -0800, Mike Stump wrote: > On Dec 19, 2005, at 5:34 PM, Jim Blandy wrote: > >On 12/19/05, Mike Stump <[EMAIL PROTECTED]> wrote: > >>But it doesn't do what people really want it to by design. :-( > > > >And that would be? > > http://subversion.tigris.org/faq.html#version-value-in-source > > I would like something, that substitutes automatically, works on svn > co and svn up and can be used to obtain the exact sources I was > playing with, given say a hard coded url and branch name. I can > promise to only co or up the whole tree and to not have any > modifications in the tree. Ideally, I'd like this to be stable, so > that the number doesn't increment if there are no actual changes in > my tree, though, this last point isn't critical. I don't see how the current svn supports updating a single file with the current revision number for each checkin. H.J.
A question about the global variables initialization.
Hello,
For such a program,
int a=0;
int main(void)
{
...
}
We will see the compiler put the variable 'a' into the bss section.
That means that 'a' is a non-initialized variable. I don't know if this
is the gcc's strategy.
Happy Christmas.
Eric.
Re: A question about the global variables initialization.
On Dec 20, 2005, at 2:02 AM, Eric Fisher wrote:
Hello,
For such a program,
int a=0;
int main(void)
{
...
}
We will see the compiler put the variable 'a' into the bss section.
That means that 'a' is a non-initialized variable. I don't know if this
is the gcc's strategy.
Yes for zero'd initialized variables, GCC puts them into BSS to say
space in the executable.
-- Pinski
A question about the global variables initialization.
>Yes for zero'd initialized variables, GCC puts them into BSS to say >space in the executable. Thanks. But, you say 'to say space in the executable'. I'm not clear what does it mean. Eric.
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, Dec 19, 2005 at 02:11:46PM -0800, Ian Lance Taylor wrote: > I think an algorithm which should work fairly reliably in the general > case is: > > 1) Are there any old insns with RTX_FRAME_RELATED_P set? > If no, stop. > 2) For each old insn with RTX_FRAME_RELATED_P set: > a) if insn has a REG_FRAME_RELATED_EXPR note, add it to the list; > b) otherwise, insn should be a PARALLEL or SEQUENCE or SET; > add the insn to the list. > 3) Set RTX_FRAME_RELATED_P on last new insn. > 4) If there is more than one entry on list, turn it into a PARALLEL > (see dwarf2out_frame_debug_expr). Otherwise take first insn on > list. > 5) Put the result of 4 in a REG_FRAME_RELATED_EXPR note on last new > insn. I think that this is all complicated enough that we should simply deny peepholing insns with RTX_FRAME_RELATED_P set. You'll note, for instance, that while we got results that were partially correct in the transformation, in that we recoginize that the cfa is at offset 16, we don't recognize that we shouldn't be generating a store of reg 0 in the state machine. In the specific instance here, where we'd like to use the push for space savings, we can simply generate it that way to begin with, with the appropriate REG_FRAME_RELATED_EXPR indicating that it's merely a stack adjustment. r~
Re: A question about the global variables initialization.
On Dec 20, 2005 08:17 AM, Eric Fisher <[EMAIL PROTECTED]> wrote: > >Yes for zero'd initialized variables, GCC puts them into BSS to say > >space in the executable. > > Thanks. But, you say 'to say space in the executable'. I'm not clear > what does it mean. "save space". Gr. Steven
