Re: Re; Maintaining, was: Re: Reduce Dwarf Debug Size
Manuel López-Ibáñez wrote: On 02/03/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: A week is too short of time to ping a patch. Ups! I actually believed that a week was the recommended time to ping a patch. What is it then? I remembered a week as well, but http://gcc.gnu.org/contribute.html says two weeks. I agree with Joe that you can't always expect an answer within a week, but I don't think that necessarily means that pinging after a week or so is a bad thing; it just means that patches are likely to get pinged sometimes. It seems to me that pings work reasonably well in practice to deal with the "someone else should review this" problem. - Brooks
I need an advice about duplication of input arguments in secondary registers
Hi, Is there somebody who is able to give me a hint, how to manage it to pass register passed arguments in two different registers ? I need this for the x86_64 port. The MS ABI passes floating-points in XMM registers, but additionally for va-sake within the standard integer registers as shadows. Is there in gcc an example, which may can help ? Regards, i.A. Kai Tietz Kai Tietz - Software engineering OneVision Software Entwicklungs GmbH & Co KG Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany Phone: +49-941-78004-0 FAX: +49-941-78004-489 WWW: http://www.OneVision.com
Re: Re; Maintaining, was: Re: Reduce Dwarf Debug Size
On 02/03/07, Brooks Moses <[EMAIL PROTECTED]> wrote: Manuel López-Ibáñez wrote: > On 02/03/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: >> A week is too short of time to ping a patch. > > Ups! I actually believed that a week was the recommended time to ping > a patch. What is it then? I remembered a week as well, but http://gcc.gnu.org/contribute.html says two weeks. I agree with Joe that you can't always expect an answer within a week, but I don't think that necessarily means that pinging after a week or so is a bad thing; it just means that patches are likely to get pinged sometimes. It seems to me that pings work reasonably well in practice to deal with the "someone else should review this" problem. That is what I think. Although I am going to change my frequency to two weeks from now on to comply with contribute.html Thanks for the info. Manuel.
RFC: Adding VxWorks PIC support to various backends
CodeSourcery is gearing up to submit support for the VxWorks RTP PIC
model. Six targets are affected: arm, i386, mips, rs6000, sh and sparc.
All this code is conditional on TARGET_VXWORKS_RTP being true and refers
to two other macros: VXWORKS_GOTT_BASE and VXWORKS_GOTT_INDEX.
Before submitting patches, I just wanted to ask how this code should
be integrated into the surrounding non-VxWorks code. Some obvious
alternatives are:
1) Wrap it in #ifdef TARGET_VXWORKS_RTP.
2) Provide an always-false definition of TARGET_VXWORKS_RTP in
arm.h, i386.h, etc. Also provide dummy definitions of the
VXWORKS_GOTT_* macros.
3) Provide an always-false definition of TARGET_VXWORKS_RTP in
defaults.h. Also provide dummy definitions of the VXWORKS_GOTT_*
macros.
4) Like (3), but provide the real VxWorks default values of the
VXWORKS_GOTT_* macros (rather than dummy ones).
but I'm open to others.
FWIW, I've attached a proto-patch for (4) below. One good thing about
(4) is that it seems to be the least redundant option. One bad thing
is that it leaks OS-specific stuff into the main part of the compiler.
I suppose we do have some precedent for that with the ELF-related code,
but I can see that it's not something we want to encourage.
Richard
gcc/
* defaults.h (TARGET_VXWORKS_RTP, VXWORKS_GOTT_BASE)
(VXWORKS_GOTT_INDEX): Define.
* config/vxworks.h (VXWORKS_GOTT_BASE, VXWORKS_GOTT_INDEX): Delete.
* doc/tm.texi (TARGET_VXWORKS_RTP, VXWORKS_GOTT_BASE
(VXWORKS_GOTT_INDEX): Document.
Index: gcc/defaults.h
===
--- gcc/defaults.h (revision 122476)
+++ gcc/defaults.h (working copy)
@@ -906,4 +906,14 @@ #define HARD_REGNO_NREGS_HAS_PADDING(REG
#define HARD_REGNO_NREGS_WITH_PADDING(REGNO, MODE) -1
#endif
+#ifndef TARGET_VXWORKS_RTP
+#define TARGET_VXWORKS_RTP false
+#endif
+#ifndef VXWORKS_GOTT_BASE
+#define VXWORKS_GOTT_BASE "__GOTT_BASE__"
+#endif
+#ifndef VXWORKS_GOTT_INDEX
+#define VXWORKS_GOTT_INDEX "__GOTT_INDEX__"
+#endif
+
#endif /* ! GCC_DEFAULTS_H */
Index: gcc/config/vxworks.h
===
--- gcc/config/vxworks.h(revision 122473)
+++ gcc/config/vxworks.h(working copy)
@@ -97,11 +97,4 @@ #define TARGET_ASM_DESTRUCTOR vxworks_as
extern void vxworks_asm_out_constructor (rtx symbol, int priority);
extern void vxworks_asm_out_destructor (rtx symbol, int priority);
-/* The name of the symbol for the table of GOTs in a particular
- RTP. */
-#define VXWORKS_GOTT_BASE "__GOTT_BASE__"
-/* The name of the symbol for the index into the table of GOTs for the
- GOT associated with the current shared library. */
-#define VXWORKS_GOTT_INDEX "__GOTT_INDEX__"
-
#define VXWORKS_KIND VXWORKS_KIND_NORMAL
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 122473)
+++ gcc/doc/tm.texi (working copy)
@@ -53,6 +53,7 @@ through the macros defined in the @file{
* MIPS Coprocessors:: MIPS coprocessor support and how to customize it.
* PCH Target:: Validity checking for precompiled headers.
* C++ ABI:: Controlling C++ ABI changes.
+* VxWorks:: VxWorks-specific macros.
* Misc::Everything else.
@end menu
@@ -9176,6 +9177,29 @@ defined. Use this hook to make adjustme
visibility or perform any other required target modifications).
@end deftypefn
[EMAIL PROTECTED] VxWorks
[EMAIL PROTECTED] VxWorks-specific Parameters
[EMAIL PROTECTED] VxWorks
+
+Several backends have code to support the VxWorks PIC model.
+Rather than hide this code in preprocessor conditions, it is
+convenient to ensure that certain cross-target macros are always
+defined.
+
[EMAIL PROTECTED] TARGET_VXWORKS_RTP
+True if generating code for a VxWorks RTP.
[EMAIL PROTECTED] defmac
+
[EMAIL PROTECTED] VXWORKS_GOTT_BASE
+A symbol that points to the table of GOTs used in RTP PIC.
+The default is @code{__GOTT_BASE__}.
[EMAIL PROTECTED] defmac
+
[EMAIL PROTECTED] VXWORKS_GOTT_INDEX
+A symbol that gives the index of the current module's GOT in
[EMAIL PROTECTED] The default is @code{__GOTT_INDEX__}.
[EMAIL PROTECTED] defmac
+
@node Misc
@section Miscellaneous Parameters
@cindex parameters, miscellaneous
Accessing function code from CFG
Hi all, In an IPA pass, for each CFG node, I have a tree decl member from which I can access the return type, name of the function, argument names and its types, but I can't seem to find a way to get the function code. I would guess it would be a basic block list but I don't know where I can get it. Any suggestions? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: I need an advice about duplication of input arguments in secondary registers
Kai Tietz <[EMAIL PROTECTED]> writes: > Is there somebody who is able to give me a hint, how to manage it to pass > register passed arguments in two different registers ? I need this for the > x86_64 port. The MS ABI passes floating-points in XMM registers, but > additionally for va-sake within the standard integer registers as shadows. > Is there in gcc an example, which may can help ? Look at the documentation for FUNCTION_ARG, which specific reference to the use of PARALLEL. Ian
Re: Accessing function code from CFG
Paulo J. Matos wrote on 03/02/07 10:12: In an IPA pass, for each CFG node, I have a tree decl member from which I can access the return type, name of the function, argument names and its types, but I can't seem to find a way to get the function code. I would guess it would be a basic block list but I don't know where I can get it. You need to get at the function structure from the cgraph node with DECL_STRUCT_FUNCTION (cgraph_node->decl). Then you can use one of the CFG accessors like basic_block_info_for_function().
Re: RFC: Adding VxWorks PIC support to various backends
Richard Sandiford <[EMAIL PROTECTED]> writes: > 1) Wrap it in #ifdef TARGET_VXWORKS_RTP. > > 2) Provide an always-false definition of TARGET_VXWORKS_RTP in > arm.h, i386.h, etc. Also provide dummy definitions of the > VXWORKS_GOTT_* macros. > > 3) Provide an always-false definition of TARGET_VXWORKS_RTP in > defaults.h. Also provide dummy definitions of the VXWORKS_GOTT_* > macros. > > 4) Like (3), but provide the real VxWorks default values of the > VXWORKS_GOTT_* macros (rather than dummy ones). Provide an always-false definition of TARGET_VXWORKS_RTP in arm.h, i386.h, etc. Define the other macros in config/vxworks.h. Add vxworks.h to config.gcc for the appropriate targets. (I assume here that you otherwise only need to change the files in config/i386, config/arm, etc.) Ian
Re: Re; Maintaining, was: Re: Reduce Dwarf Debug Size
> >http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html This patch looks wrong to me. I don't understand how it could be correct in the presence of __attribute__ ((aligned (N))). It checks TYPE_PACKED but not TYPE_ALIGN or TYPE_USER_ALIGN. The default hook assumes that objects larger than pointers are not naturally aligned, which does not make sense to me: given a type, we know the alignment, and we should use that. This patch for the cases when alignment is *not known* at compile time. is_packed is for targets that support various alignment rules for packed structs. See http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html for more discussion on this topic. - Devang I don't know whether this is still a problem. If it is, I hope the IBM Haifa folks will look at the test cases. Thanks for pointing out the patch. :REVIEWURL http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html: Ian
Re: RFC: Adding VxWorks PIC support to various backends
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > Richard Sandiford <[EMAIL PROTECTED]> writes: >> 1) Wrap it in #ifdef TARGET_VXWORKS_RTP. >> >> 2) Provide an always-false definition of TARGET_VXWORKS_RTP in >> arm.h, i386.h, etc. Also provide dummy definitions of the >> VXWORKS_GOTT_* macros. >> >> 3) Provide an always-false definition of TARGET_VXWORKS_RTP in >> defaults.h. Also provide dummy definitions of the VXWORKS_GOTT_* >> macros. >> >> 4) Like (3), but provide the real VxWorks default values of the >> VXWORKS_GOTT_* macros (rather than dummy ones). > > Provide an always-false definition of TARGET_VXWORKS_RTP in arm.h, > i386.h, etc. Define the other macros in config/vxworks.h. Add > vxworks.h to config.gcc for the appropriate targets. OK. If I've understood you correctly, the difference between that and (2) is that you wouldn't have the dummy definitions of the VXWORKS_GOTT_* macros in arm.h, etc. Is that right? So by appropriate targets, do you mean all arm, i386, etc. targets? It's just that if there are no definitions of the VXWORKS_GOTT_* macros, you'll get a compilation error. Richard
Re: Accessing function code from CFG
On 3/2/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote on 03/02/07 10:12: > In an IPA pass, for each CFG node, I have a tree decl member from > which I can access the return type, name of the function, argument > names and its types, but I can't seem to find a way to get the > function code. I would guess it would be a basic block list but I > don't know where I can get it. You need to get at the function structure from the cgraph node with DECL_STRUCT_FUNCTION (cgraph_node->decl). Then you can use one of the CFG accessors like basic_block_info_for_function(). Great! :-) Thank you! -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Reduce Dwarf Debug Size
[ Moving from gcc-patches to gcc ] Chris Lattner <[EMAIL PROTECTED]> writes: > The LLVM dev policy does not to try to define common sense. It is a > rough guideline which can be deviated from when it makes sense. > > "Trust but verify" starts with trust. What I am about to say is probably an overstatement. And obviously I am not on the steering committee and do not speak for it. There are many significant gcc contributors with a commercial interest in gcc. One thing we have learned over the years is that when there is money at stake, there is a change in the line between "patch is ready" and "patch is a good start which we can fix up later." This applies to me as much as to anybody else; those of us with commercial interests try to wear two hats when discussing gcc, but frankly money has a way of focusing attention. We have also learned is that it is difficult to strip somebody of maintainership status--that is a harsh statement about that person, justified only by egregious actions. In fact, while people have resigned maintainerships, I'm not sure we have ever stripped maintainership from a person. And we have learned that while it is easy to revert a patch because it breaks things, it is difficult to revert a patch because it is ugly or difficult to maintain; complaints in that area are met with disagreement or requests to fix the patch, rather than remove it. A major reason that it is difficult to strip maintainership and difficult to reject an ugly patch is that, for better or for worse, we rejected the benevolent dictatorship development model in the egcs split. And indeed, while this is a controversial statement with which some people will disagree, I believe that that split was caused in part by commercial interests on both sides of the split (and I was there at the time). After the split, we set up a hierarchy of cooperating maintainers. During negotations to end the split, a steering committee appointed itself (I was not much involved in this part, and may be misstating slightly), taking the blessing of the FSF to be its authority. The steering committee explicitly handed technical decisions to the maintainers, with the general understanding that there was no single chief maintainer. Lacking a benevolent dictator means that "trust but verify" does not work, because there is no way to implement the "verify" step. Or, rather: if "verify" fails, there is no useful action to take, except in the most obvious of cases. So my conclusion is that, for gcc, it is wise to require a formal confirmation process before somebody is allowed to approve patches or commit patches without approval from others. Ian
Re: Reduce Dwarf Debug Size
> And indeed, while this is a controversial statement with which > some people will disagree, I believe that that split was caused in > part by commercial interests on both sides of the split (and I was > there at the time). Indeed I disagree. I'm not aware of any commercial interests on the FSF GCC side. As far as I can recall, the split was between the commercial interests on the EGCS side and the non-commercial interests on the FSF side. > Lacking a benevolent dictator means that "trust but verify" does not > work, because there is no way to implement the "verify" step. Or, > rather: if "verify" fails, there is no useful action to take, except > in the most obvious of cases. I disagree here too. Anybody has the right and ability to look at a patch that was already committed, decide they don't like it, and say why. And they can patch the patch. We see people doing this for spelling and whitespace errors all the time. > So my conclusion is that, for gcc, it is wise to require a formal > confirmation process before somebody is allowed to approve patches or > commit patches without approval from others. However, I certainly agree with that!
Re: Re; Maintaining, was: Re: Reduce Dwarf Debug Size
Ian Lance Taylor writes: Kazu Hirata <[EMAIL PROTECTED]> writes: > > I am aware of the define_constraints patch. I am thinking about > working on the H8 and M68K ports at least. How urgent is this? FWIW, > I've reproduced the ICE that Zack mentioned, but I haven't > investigated it. It's not urgent at all. For what it's worth, I was hoping to get some traction on converting all ports to the new scheme in the 4.3 cycle, but as I don't have any time to work on it myself, I haven't been advocating it either. I think that in general GCC could use a less bureaucratic review process - I think the only reason it used to work okay is that we had Jeff Law and then Richard Henderson making valiant efforts to review everything - but I'm not convinced it's the biggest problem we have. I'd suggest the bug backlog, and the difficulty of implementing new features without creating more bugs, as bigger problems ... of course, not getting code reviewed doesn't help with either. zw
Re: Re; Maintaining, was: Re: Reduce Dwarf Debug Size
"Devang Patel" <[EMAIL PROTECTED]> writes: > > > > > >http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html > > > > This patch looks wrong to me. I don't understand how it could be > > correct in the presence of __attribute__ ((aligned (N))). It checks > > TYPE_PACKED but not TYPE_ALIGN or TYPE_USER_ALIGN. The default hook > > assumes that objects larger than pointers are not naturally aligned, > > which does not make sense to me: given a type, we know the alignment, > > and we should use that. > > This patch for the cases when alignment is *not known* at > compile time. > > is_packed is for targets that support various alignment rules for packed > structs. > > See > http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html > for more discussion on this topic. Thanks for the pointer. It seems to me that the way to fix this problem is to know the alignment. For any type there is the ideal alignment and there is the minimum supported alignment. Currently TYPE_ALIGN for a scalar type holds the ideal alignment. I think that given an arbitrary pointer with no alignment attributes, we may correctly assume that that pointer has the minimum supported alignment. So what we need is a backend hook to return the minimum supported alignment for a type. The ideal alignment and the minimum supported alignment will always be the same *except* when the target defines BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN. So I think a better fix here would be a target hook or macro which returns the minimum supported alignment given a type. If it is a hook, the default version could use BIGGEST_FIELD_ALIGNMENT. Special versions would be required for each target which defines ADJUST_FIELD_ALIGN (there are only three). Ian
Re: RFC: Adding VxWorks PIC support to various backends
Richard Sandiford <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Richard Sandiford <[EMAIL PROTECTED]> writes: > >> 1) Wrap it in #ifdef TARGET_VXWORKS_RTP. > >> > >> 2) Provide an always-false definition of TARGET_VXWORKS_RTP in > >> arm.h, i386.h, etc. Also provide dummy definitions of the > >> VXWORKS_GOTT_* macros. > >> > >> 3) Provide an always-false definition of TARGET_VXWORKS_RTP in > >> defaults.h. Also provide dummy definitions of the VXWORKS_GOTT_* > >> macros. > >> > >> 4) Like (3), but provide the real VxWorks default values of the > >> VXWORKS_GOTT_* macros (rather than dummy ones). > > > > Provide an always-false definition of TARGET_VXWORKS_RTP in arm.h, > > i386.h, etc. Define the other macros in config/vxworks.h. Add > > vxworks.h to config.gcc for the appropriate targets. > > OK. If I've understood you correctly, the difference between that > and (2) is that you wouldn't have the dummy definitions of the > VXWORKS_GOTT_* macros in arm.h, etc. Is that right? > > So by appropriate targets, do you mean all arm, i386, etc. targets? > It's just that if there are no definitions of the VXWORKS_GOTT_* macros, > you'll get a compilation error. Oh, right. I guess I would be inclined to use a #ifdef. Or maybe write functions for VXWORKS_GOTT_* and stash them in varasm.c and have them use a #ifdef. I don't know. I hope somebody else sees a less ugly solution. Ian
Re: Reduce Dwarf Debug Size
[EMAIL PROTECTED] (Richard Kenner) writes: > > And indeed, while this is a controversial statement with which > > some people will disagree, I believe that that split was caused in > > part by commercial interests on both sides of the split (and I was > > there at the time). > > Indeed I disagree. I'm not aware of any commercial interests on the FSF > GCC side. As far as I can recall, the split was between the commercial > interests on the EGCS side and the non-commercial interests on the FSF > side. I don't need or want to dig this up yet again. I'll just reaffirm that my beliefs are what they are, and that others disagree. > > Lacking a benevolent dictator means that "trust but verify" does not > > work, because there is no way to implement the "verify" step. Or, > > rather: if "verify" fails, there is no useful action to take, except > > in the most obvious of cases. > > I disagree here too. Anybody has the right and ability to look at a patch > that was already committed, decide they don't like it, and say why. And > they can patch the patch. We see people doing this for spelling and > whitespace errors all the time. Of course. But what we can not do, in practice, is revert a patch which does not actually break anything. Heck, sometimes we can't even revert a patch which *does* break things. Ian
Inconsistent next_bb info when EXIT is a successor
Hello,
During my work on the selective scheduler I have triggered an assert in
our code saying that a fall-through edge should have e->src->next_bb ==
e->dest. This was for a bb with EXIT_BLOCK as its fall-through
successor, but its next_bb pointing to another block.
I was wondering why verify_flow_info didn't catch this issue. The code
starting at cfgrtl.c:1973 (in the January 03 trunk) does check this, but
only when e->src != ENTRY_BLOCK_PTR && e->dest != EXIT_BLOCK_PTR.
I have tried to reorganize the check so that the "e->src->next_bb ==
e->dest" condition is checked for all edges (see the patch below). Of
course, GCC does not bootstrap with this patch, triggering an assert of
incorrect fallthru block in cfg_layout_finalize, after RTL loop
optimizations. In my case, combine has broken that condition.
Does this ring any bells to anybody? Is this a bug, or should this
condition not be checked for edges pointing to the exit block at all?
Thanks, Andrey
--- cfgrtl.c(revision 24203)
+++ cfgrtl.c(local)
@@ -1969,8 +1969,7 @@ rtl_verify_flow_info (void)
break;
}
}
- else if (e->src != ENTRY_BLOCK_PTR
- && e->dest != EXIT_BLOCK_PTR)
+ else
{
rtx insn;
@@ -1981,7 +1980,9 @@ rtl_verify_flow_info (void)
e->src->index, e->dest->index);
err = 1;
}
- else
+
+ if (e->src != ENTRY_BLOCK_PTR
+ && e->dest != EXIT_BLOCK_PTR)
for (insn = NEXT_INSN (BB_END (e->src)); insn != BB_HEAD
(e->dest);
insn = NEXT_INSN (insn))
if (BARRIER_P (insn) || INSN_P (insn))
Re: Reduce Dwarf Debug Size
On Fri, 2 Mar 2007, Ian Lance Taylor wrote: > [ Moving from gcc-patches to gcc ] > > Chris Lattner <[EMAIL PROTECTED]> writes: > > > The LLVM dev policy does not to try to define common sense. It is a > > rough guideline which can be deviated from when it makes sense. > > > > "Trust but verify" starts with trust. > > What I am about to say is probably an overstatement. And obviously I > am not on the steering committee and do not speak for it. > > There are many significant gcc contributors with a commercial interest > in gcc. One thing we have learned over the years is that when there > is money at stake, there is a change in the line between "patch is > ready" and "patch is a good start which we can fix up later." This > applies to me as much as to anybody else; those of us with commercial > interests try to wear two hats when discussing gcc, but frankly money > has a way of focusing attention. > > [...] > Lacking a benevolent dictator means that "trust but verify" does not > work, because there is no way to implement the "verify" step. Or, > rather: if "verify" fails, there is no useful action to take, except > in the most obvious of cases. > > So my conclusion is that, for gcc, it is wise to require a formal > confirmation process before somebody is allowed to approve patches or > commit patches without approval from others. > Ian Perhaps a middle ground between what we have now, and "trust but verify", would be to have a "without objection" rule. I.e. certain people are authorized to post patches and if no one objects within say two weeks, then they could then check it in. I think that would help clear up the backlog while still allowing people to comment *before* the patch goes in. I think it would be fair to directly CC: relevant maintainers in these cases so they don't miss the patch by accident. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
ancient history (was re: reduce dwarf debug size)
On Fri, Mar 02, 2007 at 11:10:22AM -0500, Richard Kenner wrote: > > And indeed, while this is a controversial statement with which > > some people will disagree, I believe that that split was caused in > > part by commercial interests on both sides of the split (and I was > > there at the time). > > Indeed I disagree. I'm not aware of any commercial interests on the FSF > GCC side. As far as I can recall, the split was between the commercial > interests on the EGCS side and the non-commercial interests on the FSF > side. It was not anywhere near that simple; there were a number of disputes that had nothing to do with commercial interests (particularly the very sorry state of C++). If your interpretation were correct, then after the split, the non-commercial idealists would have stayed with the FSF side of the split, but this didn't happen for the most part. You are right that there were concerns when it started that egcs would just be the Cygnus compiler, and one of the main purposes of the steering committee was precisely to prevent Cygnus from controlling it; the goal was to unify Cygnus "devo", pgcc, and f77, as well as have a portable compiler that worked on Linux: at the time, no FSF release would work on Linux, particularly for C++, you needed a bunch of horrible patches from HJ Lu. I could say much more (there are interesting stories about the behind-the-scenes politics) but it's off-topic.
Re: Reduce Dwarf Debug Size
On 02/03/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: Perhaps a middle ground between what we have now, and "trust but verify", would be to have a "without objection" rule. I.e. certain people are authorized to post patches and if no one objects within say two weeks, then they could then check it in. I think that would help clear up the backlog while still allowing people to comment *before* the patch goes in. I am new here but since my recent ping-floods have been used as arguments to foster some opinions, I think I will give my opinion. I think the "without objection rule" is a bad idea. As it has been said already, relevant maintainers may be on vacation, may be busy during 2 weeks, or the patch may have fallen through the cracks. And precisely the latter is what I perceive as the real problem that a "without objection rule" will not solve and will actually introduce another problem: undesirable unreviewed patches get committed. The problem is not that reviewers do not review, they do. If you ping a patch it will get reviewed sooner or later. The problem is that if the submitter does not insist, the patch will go unnoticed. I guess there may be many reasons for not insisting and many reasons why the patches go unnoticed. Some reasons have been pointed out already: reviewers waiting for other reviewers to step in, submitter losing interest from lack of feedback, submitters ignore that they need to ping or how often, lack of reviews from non-maintainers, reviewers tend to focus on recent patches, ... Neither "trust but verify" or "without objection rule" would solve any of these problems. Just an uninformed opinion from a newbie, Manuel.
Re: ancient history (was re: reduce dwarf debug size)
What an interesting and unproductive discussion but I hope it ends here or should I call somebody "a member of a German political party very popular around 1940"? :-) Cheers, Manuel. On 02/03/07, Joe Buck <[EMAIL PROTECTED]> wrote: On Fri, Mar 02, 2007 at 11:10:22AM -0500, Richard Kenner wrote: > > And indeed, while this is a controversial statement with which > > some people will disagree, I believe that that split was caused in > > part by commercial interests on both sides of the split (and I was > > there at the time). > > Indeed I disagree. I'm not aware of any commercial interests on the FSF > GCC side. As far as I can recall, the split was between the commercial > interests on the EGCS side and the non-commercial interests on the FSF > side. It was not anywhere near that simple; there were a number of disputes that had nothing to do with commercial interests (particularly the very sorry state of C++). If your interpretation were correct, then after the split, the non-commercial idealists would have stayed with the FSF side of the split, but this didn't happen for the most part. You are right that there were concerns when it started that egcs would just be the Cygnus compiler, and one of the main purposes of the steering committee was precisely to prevent Cygnus from controlling it; the goal was to unify Cygnus "devo", pgcc, and f77, as well as have a portable compiler that worked on Linux: at the time, no FSF release would work on Linux, particularly for C++, you needed a bunch of horrible patches from HJ Lu. I could say much more (there are interesting stories about the behind-the-scenes politics) but it's off-topic.
Re: ancient history (was re: reduce dwarf debug size)
> I could say much more (there are interesting stories about the > behind-the-scenes politics) but it's off-topic. Please think about writing a book telling the whole story when the dust will have settled. :-) -- Eric Botcazou
bootstrap failure on real-install-headers-cpio
Has anyone seen this bootstrap failure? I only get it on my hppa*-hp-hpux*
builds, not on ia64-hp-hpux* or on Linux builds. I assume it is related
to the include-fixed changes but I don't know why I only get it for some
platforms. I get it with parallel and non-parallel builds.
Steve Ellcey
[EMAIL PROTECTED]
.
.
.
/bin/sh /proj/opensrc/nightly/src/trunk/gcc/../move-if-change tmp-macro_list
macro_list
echo timestamp > s-macro_list
rm -rf include-fixed; mkdir include-fixed
chmod a+rx include-fixed
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc && \
make real-install-headers-cpio DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
(TARGET_MACHINE='hppa1.1-hp-hpux11.11'; srcdir=`cd
/proj/opensrc/nightly/src/trunk/gcc; ${PWDCMD-pwd}`; \
SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
cd ../build-hppa1.1-hp-hpux11.11/fixincludes && \
/bin/sh ./fixinc.sh ../../gcc/include-fixed \
`echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` ); \
rm -f include-fixed/syslimits.h; \
if [ -f include-fixed/limits.h ]; then \
mv include-fixed/limits.h include-fixed/syslimits.h; \
else \
cp /proj/opensrc/nightly/src/trunk/gcc/gsyslimits.h
include-fixed/syslimits.h; \
fi; \
fi
make[4]: Entering directory
`/proj/opensrc/nightly/build-hppa1.1-hp-hpux11.11-trunk/obj_gcc/prev-gcc'
cd `${PWDCMD-pwd}`/include ; \
find . -print | cpio -pdum
/proj/opensrc/nightly/build-hppa1.1-hp-hpux11.11-trunk/obj_gcc/prev-gcc/../gcc/./include
cannot write in
make[4]: *** [real-install-headers-cpio] Error 2
make[4]: Leaving directory
`/proj/opensrc/nightly/build-hppa1.1-hp-hpux11.11-trunk/obj_gcc/prev-gcc'
make[3]: *** [stmp-fixinc] Error 2
make[3]: Leaving directory
`/proj/opensrc/nightly/build-hppa1.1-hp-hpux11.11-trunk/obj_gcc/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory
`/proj/opensrc/nightly/build-hppa1.1-hp-hpux11.11-trunk/obj_gcc'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory
`/proj/opensrc/nightly/build-hppa1.1-hp-hpux11.11-trunk/obj_gcc'
make: *** [bootstrap] Error 2
Google Summer of Code 2007
Dear all, Google Summer of Code 2007 is on [1] and I hope GCC will participate again [2]. This year the program starts much earlier [3]. Mentoring organisations are expected to apply from March 5 until March 12 (that is, next week!), while student applications will be accepted from March 14 until March 24. I am looking forward to participating as a student (I am already thinking about potential projects) but for that, I need that GCC participates as a mentoring organisation. Regards, Manuel. [1] http://code.google.com/soc/ [2] http://gcc.gnu.org/wiki/SummerOfCode [3] http://code.google.com/support/bin/answer.py?answer=60325&topic=10729
Re: vcond implementation in altivec
> Devang Patel writes: >> Is there a reason why op0 is V4SF Devang> It is destination so, yes this is wrong. >> and op1 is V4SI (and not V8HI)? Devang> condition should be v4si, but it is not op1. So this is also not correct. >> And also, why not use if_then_else instead of unspec (in all vcond's)? Devang> I did not try that path. May be I did not know about it at that time. Patches welcome. David
Re: Reduce Dwarf Debug Size
On Mar 2, 2007, at 7:57 AM, Ian Lance Taylor wrote: [ Moving from gcc-patches to gcc ] Chris Lattner <[EMAIL PROTECTED]> writes: The LLVM dev policy does not to try to define common sense. It is a rough guideline which can be deviated from when it makes sense. "Trust but verify" starts with trust. Lacking a benevolent dictator means that "trust but verify" does not work, because there is no way to implement the "verify" step. Or, rather: if "verify" fails, there is no useful action to take, except in the most obvious of cases. So my conclusion is that, for gcc, it is wise to require a formal confirmation process before somebody is allowed to approve patches or commit patches without approval from others. You are right that LLVM development and GCC development have many differences in structure. As you say, having a benevolent dictator simplifies things a lot, and I would argue that incremental development has an impact that is just as large. Others have said that an intermediate may exist between the two sides, one which is more suitable for the GCC development process. I agree, but I'll step out of the discussion and let you guys figure it out :) -Chris
Re: RFC: Adding VxWorks PIC support to various backends
On Fri, Mar 02, 2007 at 02:12:30PM +, Richard Sandiford wrote: > CodeSourcery is gearing up to submit support for the VxWorks RTP PIC > model. Six targets are affected: arm, i386, mips, rs6000, sh and sparc. > All this code is conditional on TARGET_VXWORKS_RTP being true and refers > to two other macros: VXWORKS_GOTT_BASE and VXWORKS_GOTT_INDEX. > > Before submitting patches, I just wanted to ask how this code should > be integrated into the surrounding non-VxWorks code. Some obvious > alternatives are: > > 1) Wrap it in #ifdef TARGET_VXWORKS_RTP. > > 2) Provide an always-false definition of TARGET_VXWORKS_RTP in > arm.h, i386.h, etc. Also provide dummy definitions of the > VXWORKS_GOTT_* macros. > > 3) Provide an always-false definition of TARGET_VXWORKS_RTP in > defaults.h. Also provide dummy definitions of the VXWORKS_GOTT_* > macros. > > 4) Like (3), but provide the real VxWorks default values of the > VXWORKS_GOTT_* macros (rather than dummy ones). How about (3), but instead of putting them in defaults.h, put them in config/vxworks-dummy.h, and include that in the relevant cpu.c files? I am fond of dummy versions like #define VXWORKS_GOTT_BASE (gcc_unreachable(), "") r~
Re: Google Summer of Code 2007
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: > Google Summer of Code 2007 is on [1] and I hope GCC will participate > again [2]. This year the program starts much earlier [3]. Mentoring > organisations are expected to apply from March 5 until March 12 (that > is, next week!), while student applications will be accepted from > March 14 until March 24. > > I am looking forward to participating as a student (I am already > thinking about potential projects) but for that, I need that GCC > participates as a mentoring organisation. Indeed, we do plan to participate again this year. Thanks for the reminder. As Manuel says, anybody who is interested in participating as a mentor or a student can read the information at http://code.google.com/soc/ now and get ready to apply. We'll also need suggestions for ideas to work on. Anybody who is interested please take a look at http://gcc.gnu.org/wiki/SummerOfCode and update it as needed. Thanks! Ian
Re: ancient history (was re: reduce dwarf debug size)
> > Indeed I disagree. I'm not aware of any commercial interests on the FSF > > GCC side. As far as I can recall, the split was between the commercial > > interests on the EGCS side and the non-commercial interests on the FSF > > side. > > It was not anywhere near that simple; there were a number of disputes > that had nothing to do with commercial interests (particularly the very > sorry state of C++). If your interpretation were correct, then after > the split, the non-commercial idealists would have stayed with the FSF > side of the split, but this didn't happen for the most part. I wasn't clear. I agree with you. What I meant was "to the extent that the split was motivated by commercial interests, I saw it as more commercial vs. non-commercial than two competing commercial interests", but indeed agree that was not the only (and probably not even the primary) reason for the split.
Ignore source file's directory feature of -I-
Hello, I have only recently begun to test using gcc version 4.0 and later and have found that the -I- option has been deprecated. The documentation in these later releases indicates that one part of the -I- option has been replaced with a new option, namely -iquote. Unfortunately, that is not the feature of -I- that I have been using extensively for compiling code in a VPATH environment. I have searched the bug archive as well as the mailing lists to see whether I could find more information about whether the second feature of -I- will continue to be supported (and, if so, under what option). I found one bug in the database: #19541, which describes the feature I need and references a patch to implement that feature (the patch is dated 2006-04-12). After scanning the patches mailing list, I did not see any further reference to this issue, particularly whether or not the patch would be applied to the gcc mainline or any of its releases. I also searched the main gcc mailing list (this one) and found some references to the same problem, particularly one from the maintainers of nmake (a thread of which eventually also points to the above bug number). There haven't been many messages discussing this issue since February of 2006, except for a few problems with the -iquote feature that are unrelated to the issue I have. Is there a resolution on the issue of the -I- feature of ignoring the source file's directory (for example, a statement that a new flag will be added)? I don't have the option of using my own version of gcc with the patch applied; the build system I maintain has to be able to use the version of gcc installed with the operating system. -Peter
Re: Inconsistent next_bb info when EXIT is a successor
On 3/2/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote: I have tried to reorganize the check so that the "e->src->next_bb == e->dest" condition is checked for all edges (see the patch below). Of course, GCC does not bootstrap with this patch, triggering an assert of incorrect fallthru block in cfg_layout_finalize, after RTL loop optimizations. In my case, combine has broken that condition. No. The condition you're checking is simply not true in cfglayout mode. The whole point of cfglayout mode is to get rid of the requirement that basic blocks are serial. That means a fallthru edge in cfglayout mode doesn't have to go to next_bb. It can go to *any* bb. Gr. Steven
Re: Reduce Dwarf Debug Size
Kaveh R. GHAZI wrote: Perhaps a middle ground between what we have now, and "trust but verify", would be to have a "without objection" rule. I.e. certain people are authorized to post patches and if no one objects within say two weeks, then they could then check it in. I think that would help clear up the backlog while still allowing people to comment *before* the patch goes in. I think it would be fair to directly CC: relevant maintainers in these cases so they don't miss the patch by accident. This is not too far off what the new "non-algorithmic maintainer" class is designed for, it seems to me. It broadens the class of people who can check in unreviewed patches (and review patches) without giving them full algorithmic-maintainer status. My understanding is that, although so far there are only three non-algorithmic maintainers, the intent was that there would be a fair number of them. My view might be affected somewhat by the fact that the "without objection" rule you describe is pretty close to how many of the GFortran maintainers seem to work, in my experience -- they usually post patches for discussion before committing them, and then check them in when they seem to have been discussed a reasonable amount. That seems to work quite well. - Brooks
Re: Ignore source file's directory feature of -I-
On Mar 2, 2007, at 11:18 AM, Peter Leven wrote: I have searched the bug archive as well as the mailing lists to see whether I could find more information about whether the second feature of -I- will continue to be supported (and, if so, under what option). I found one bug in the database: #19541, which describes the feature I need and references a patch to implement that feature (the patch is dated 2006-04-12). After scanning the patches mailing list, I did not see any further reference to this issue, particularly whether or not the patch would be applied to the gcc mainline or any of its releases. Feel free to comment in the bug database if you find the patch useful or not useful and if it satisfies your needs if -I- goes away. Feel free to post a ping to the gcc-patches list asking for someone to review the patch.
Help with GCC functions.
Hello Everyone, I am trying to understand GCC further, and I would like to know how GCC calls the parser from the main function in gcc.c. I looked at the YACC/BISON file and found that c_parse_file called yyparse(). Can anyone please tell me which function calls c_parse_file and how I can get to that file from the main function? Similarly, I owuld like to know how it reaches the functions in passes.c I am compiling my programs using -O3 optimization. Any help is highly appreciated. Thanks, Balaji V. Iyer. PS. Please CC me in response since I am not a subscribed member for this mailing list. Balaji V. Iyer PhD Student, Center for Efficient, Secure and Reliable Computing Department of Electrical and Computer Engineering North Carolina State University.
Re: Inconsistent next_bb info when EXIT is a successor
Steven Bosscher wrote: No. The condition you're checking is simply not true in cfglayout mode. The whole point of cfglayout mode is to get rid of the requirement that basic blocks are serial. That means a fallthru edge in cfglayout mode doesn't have to go to next_bb. It can go to *any* bb. Yes, but I'm not in cfglayout mode, because I'm either in sched1 or sched2. In that case, should this condition be preserved or not? Andrey
gcc-4.3-20070302 is now available
Snapshot gcc-4.3-20070302 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070302/ 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 122493 You'll find: gcc-4.3-20070302.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070302.tar.bz2 C front end and core compiler gcc-ada-4.3-20070302.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070302.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070302.tar.bz2 C++ front end and runtime gcc-java-4.3-20070302.tar.bz2 Java front end and runtime gcc-objc-4.3-20070302.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070302.tar.bz2The GCC testsuite Diffs from 4.3-20070223 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Help with GCC functions.
Balaji Viswanathan Iyer <[EMAIL PROTECTED]> writes: > I am trying to understand GCC further, and I would like to know how > GCC calls the parser from the main function in gcc.c. The gcc driver execs another program, which for C is called cc1. The main function in cc1 winds up calling the parser. To see how, run gcc -v to see how cc1 is invoked, and run gdb on cc1, set a breakpoint, and do a backtrace. > I looked at the > YACC/BISON file and found that c_parse_file called yyparse(). Note that this is gone in current gcc sources. The parser has been rewritten to use recursive descent rather than bison. Ian
Failed
-> http://www.gnu.org/software/gcc/gcc.html Failed Validation of W3C ! This page is not Valid XHTML 1.0 Transitional ! W3C rules specify that XHTML tags have to be written in lowercase. You have just to replace every "DIV" by "div" and validation will succeed. All the best. :-) _ Gagnez des pc Windows Vista avec Live.com http://www.image-addict.fr/
Re: Failed
On 3/2/07, Michel Pellegrin <[EMAIL PROTECTED]> wrote: -> http://www.gnu.org/software/gcc/gcc.html Failed Validation of W3C ! This page is not Valid XHTML 1.0 Transitional ! W3C rules specify that XHTML tags have to be written in lowercase. You have just to replace every "DIV" by "div" and validation will succeed. As far as I can tell this is correct in the cvs holding the html. Plus http://gcc.gnu.org/ valids as valid XHTML 1.0 Transitional. So something in the conversion method that www.gnu.org does to the web pages break the validation. Thanks, Andrew Pinski
Massive SPEC failures on trunk
Hi, Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level. Regression introduced somewhere between revision 122487 and 122478. There are three checkins, candidates for the root of regression: http://gcc.gnu.org/viewcvs?view=rev&revision=122487 http://gcc.gnu.org/viewcvs?view=rev&revision=122484 http://gcc.gnu.org/viewcvs?view=rev&revision=122479 Here is the list of failures: CPU2006/464.h264ref: GCC ICE image.c: In function 'UnifiedOneForthPix': image.c:1407: internal compiler error: in set_value_range, at tree-vrp.c:267 CPU2006/447.dealII: GCC ICE fe_tools.cc: In static member function 'static void FETools::get_projection_matrix(const FiniteElement&, const FiniteElement&, FullMatrix&) [with int dim = 3, number = double]': fe_tools.cc:322: error: definition in block 47 does not dominate use in block 49 for SSA_NAME: NMT.4199_484 in statement: NMT.4199_645 = PHI PHI argument NMT.4199_484 for PHI node NMT.4199_645 = PHI fe_tools.cc:322: internal compiler error: verify_ssa failed CPU2000/186.crafty: killed with signal 11 CPU2000/178.galgel: killed with signal 11 CPU2006/403.gcc: runtime error CPU2006/416.gamess: killed with signal 11 CPU2006/434.zeusmp: killed with signal 11 CPU2006/465.tonto: killed with signal 11 - Grigory
