Re: Warning on C++ catch by value on non primitive types
[EMAIL PROTECTED] (Thomas Costa) wrote on 13.10.05 in <[EMAIL PROTECTED]>:
> On 13 Oct 2005, at 7:41 AM, Benjamin Kosnik wrote:
>
> >
> >
> >> yeah, if it were in one of those books it could be added to the -
> >> weff-c+
> >> + option. It doesn't seem sensible to add a different option for an
> >> alternative (set of?) coding rule(s).
> >>
> >
> > FYI this is item 13 in MEC++.
> >
>
> It is on just about any decent modern C++ coding guide/list somewhere.
>
> > I think this would be a good error to have. My suggestion is to
> > file an
> > enhancement request in gcc bugzilla, with this code:
> >
> > #include
> >
> > void
> > foo()
> > {
> > try
> > {
> > }
> > catch (std::logic_error e)
> > {
> > }
> > }
So what you say is that any decent modern C++ coding guide/list wants to
forbid catching the C++ standard exceptions, and anything derived from
them?
How on earth can that count as "decent"?!
MfG Kai
Re: Warning on C++ catch by value on non primitive types
Kai Henningsen wrote: So what you say is that any decent modern C++ coding guide/list wants to forbid catching the C++ standard exceptions, and anything derived from them? no, only catch by value is problematic, as it can lead to slicing. catch by reference is perfectly fine.
Final Subversion testing this week
CVS write access users should give the subversion setup a try this week. Directions on how to do common operations are at http://gcc.gnu.org/wiki/SvnHelp I have placed the repo in exactly the place on gcc.gnu.org it will end up in during the final conversion, and in the exact condition (IE tags, branches, etc) it will be in when we convert, minus the changes over the next week I have converted the update_version script in maintainer-scripts and checked it in under the name update_version_svn I tested it from the gccadmin account on gcc.gnu.org, as well as remotely (while the old update_version pretends to support remote updating, it doesn't). Note that this is a pretty straightforward conversion, but the whole script is really overkill for the following reason: We can now identify the exact version of gcc t have simply by the revision number and branch name. So maintaining all this stuff in a DATESTAMP, etc, is severe overkill when you could simply use the result of "svnversion .' and commit that to a file, or do it client side). see http://svnbook.red-bean.com/en/1.1/re57.html for more details on the output of svnversion. I will finish updating the gcc_release script today. The other contrib scripts have been updated by Ben Elliston, and were posted to gcc-patches. --Dan
CVS access to the uberbaum tree
Does the uberbaum tree exist on savanna, or is it only on sources.redhat.com? If so, what is the procedure for accessing it? Thanks in advance... -- Peter Barada [EMAIL PROTECTED]
Re: Final Subversion testing this week
On Sun, 16 Oct 2005, Daniel Berlin wrote: > Note that this is a pretty straightforward conversion, but the whole > script is really overkill for the following reason: > > We can now identify the exact version of gcc t have simply by the > revision number and branch name. So maintaining all this stuff in a > DATESTAMP, etc, is severe overkill when you could simply use the result > of "svnversion .' and commit that to a file, or do it client side). I think we want a meaningful version in the --version output regardless of how someone got GCC (including where what they have is not an SVN tree and so can't have svnversion run in it; e.g. obtained with svn export). If a hook can make every commit update (on whatever branch or branches are affected by that commit) a checked in file with the output of svnversion in, in addition to the files explicitly modified by that commit, that would suffice. Otherwise I think we want to keep a checked in datestamp file. I do think the LAST_UPDATED file created if someone uses gcc_update should be replaced with a file with information on the branch and revision number instead. Unlike the present situation where LAST_UPDATED can be misleading if a repository mirror is used (checkout sometime after the mirror is updated, in which time the master repository has had some more commits), information with branch and revision number would be accurate even with repository mirrors. > I will finish updating the gcc_release script today. Presumably, no longer tagging any snapshots, instead just reporting the revision number and branch name in the snapshot announcements? > The other contrib scripts have been updated by Ben Elliston, and were > posted to gcc-patches. And the other maintainer-scripts scripts (update_web_docs*)? -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
[cft] aligning main's stack frame
So remember all that stuff I said earlier about it being intractibly
hard to realign the current stack frame? It appears that the generic
bits of the compiler have improved since I last tried it. In
particular, the argument pointer can now be a pseudo register. I
think we had to add this for hppa64, but I'm not sure.
The realignment isn't free, and does disable tail-calls, so I wouldn't
suggest changing the current 16-byte preferred-stack-alignment. But
it may be possible to use this on any function with at least one free
register on entry (i.e. regparm < (3 - need_static_chain_p)).
I don't do it here, but it *would* be possible to add an attribute to
enable this for any random function, or even (gasp) a command-line flag
that turns it on for sse-using functions with preferred-stack-alignment
back down to 4. Something like this wouldn't be appropriate for gcc 4.1.
So given
void dummy (void);
int main1(int, char **);
int main(int ac, char **av)
{
dummy ();
return main1(ac, av);
}
we emit -mtune=pentium4 -O2,
main:
leal4(%esp), %ecx # create argument pointer
andl$-16, %esp # align stack
pushl -4(%ecx)# copy return address
pushl %ebp
movl%esp, %ebp
pushl %esi
pushl %ebx
pushl %ecx# save argument pointer
subl$12, %esp
movl(%ecx), %esi# load arguments via arg pointer
movl4(%ecx), %ebx
calldummy
movl%ebx, 4(%esp)
movl%esi, (%esp)
callmain1
addl$12, %esp
popl%ecx
popl%ebx
popl%esi
popl%ebp
leal-4(%ecx), %esp # restore post-call stack pointer
ret
There are a number of constraints that must be satisfied here. The
argument pointer in pseudo code doesn't allow an offset, so we can't
just do straight movs between ecx and esp at the beginning and the
end of the function. Copying the return address tremendously
simplifies the unwinding data we generate. Which for this function is
DW_CFA_advance_loc: 4 to 0004
DW_CFA_def_cfa: r1 ofs 0
DW_CFA_register: r4 in r1
DW_CFA_advance_loc: 6 to 000a
DW_CFA_def_cfa: r4 ofs 4
DW_CFA_advance_loc: 1 to 000b
DW_CFA_def_cfa_offset: 8
DW_CFA_offset: r5 at cfa-8
DW_CFA_advance_loc: 2 to 000d
DW_CFA_def_cfa_reg: r5
DW_CFA_advance_loc: 3 to 0010
DW_CFA_offset: r4 at cfa-20
DW_CFA_offset: r3 at cfa-16
DW_CFA_offset: r6 at cfa-12
Finally, this code allows -fomit-frame-pointer to be effective in
main again.
This should get more than just bootstrap testing. Anyone care to
help out here?
r~
* dwarf2out.c (dwarf2out_reg_save_reg): New.
(dwarf2out_frame_debug_expr): Return after dwarf_handle_frame_unspec.
* function.c (assign_parms): Use calls.internal_arg_pointer.
(expand_main_function): Remove FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN
code.
* target-def.h (TARGET_INTERNAL_ARG_POINTER): New.
(TARGET_CALLS): Add it.
* target.h (struct gcc_target): Add calls.internal_arg_pointer.
* targhooks.c (default_internal_arg_pointer): New.
* targhooks.h (default_internal_arg_pointer): Declare.
* tree.h (dwarf2out_reg_save_reg): Declare.
* doc/tm.texi (FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN): Remove.
* config/i386/i386.c (dbx_register_map): Add return column.
(dbx64_register_map, svr4_dbx_register_map): Likewise.
(TARGET_INTERNAL_ARG_POINTER, ix86_internal_arg_pointer): New.
(TARGET_DWARF_HANDLE_FRAME_UNSPEC, ix86_dwarf_handle_frame_unspec): New.
(ix86_function_ok_for_sibcall): Disable if force_align_arg_pointer.
(ix86_save_reg): Save force_align_arg_pointer.
(ix86_emit_save_regs): Make regno unsigned.
(ix86_emit_save_regs_using_mov): Likewise.
(ix86_expand_prologue): Handle force_align_arg_pointer.
(ix86_expand_epilogue): Likewise.
* config/i386/i386.h: (dbx_register_map): Update.
(dbx64_register_map, svr4_dbx_register_map): Update.
(struct machine_function): Add force_align_arg_pointer.
* config/i386/i386.md (UNSPEC_REG_SAVE, UNSPEC_DEF_CFA): New.
(UNSPEC_TP, UNSPEC_TLS_GD, UNSPEC_TLS_LD_BASE): Renumber.
(TARGET_PUSH_MEMORY peepholes): Disable if RTX_FRAME_RELATED_P.
Index: dwarf2out.c
===
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.615
diff -u -p -d -r1.615 dwarf2out.c
--- dwarf2out.c 6 Oct 2005 19:33:02 - 1.615
+++ dwarf2out.c 16 Oct 2005 19:29:44 -
@@ -1271,6 +1271,30 @@ clobbers_queued_reg_save (rtx insn)
return false;
}
+/* Entry point for saving the first register into the second. */
+
+void
+dwarf2out_reg_save_reg (const cha
Re: Final Subversion testing this week
> Presumably, no longer tagging any snapshots, instead just reporting the > revision number and branch name in the snapshot announcements? Uh, tags are cheap, it can tag them if it likes. Who cares. > > > The other contrib scripts have been updated by Ben Elliston, and were > > posted to gcc-patches. > > And the other maintainer-scripts scripts (update_web_docs*)? Those too
Re: Final Subversion testing this week
Daniel Berlin <[EMAIL PROTECTED]> writes: > CVS write access users should give the subversion setup a try this week. Is there a branch that represents the tip of the old-gcc repository? It appears that premerge-fsf-branch is intented to be this, but it is missing many files from old-gcc repository. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [cft] aligning main's stack frame
This should get more than just bootstrap testing. Anyone care to help out here? I'm bringing my mainline tree up to speed, as all the porting work I recently did was on the 4.0 branch, but once that's done I'll be glad to help out. Aside from the full testsuite, I will compile up Xorg and an internal package I have which is a collection of about 70 different open source libraries (gtk, cairo, libxml2 etc) and perl and apache/php. If that all works, then thats about as well tested as I can think to get. Its a lot of code, some of which really stresses the compiler (Xorg and Perl in particular). Kean
Re: Final Subversion testing this week
On Sun, 2005-10-16 at 22:19 +0200, Andreas Schwab wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > > CVS write access users should give the subversion setup a try this week. > > Is there a branch that represents the tip of the old-gcc repository? No. old-gcc got merged into the current gcc completely. > It > appears that premerge-fsf-branch is intented to be this, but it is missing > many files from old-gcc repository. This just happens to be how the merge turned out using iant's stuff. >From the perspective of annotate and log, everything should look okay, but if you are browsing using viewcvs or checking out tags in old-cvs, i don't think they all work :( > > Andreas. >
Re: Update on GCC moving to svn
On Fri, 2005-10-14 at 11:40 +, Joseph S. Myers wrote: > On Fri, 14 Oct 2005, Kaveh R. Ghazi wrote: > > > their corresponding svn commands posted on the website? Hmm, I guess > > we would need to update these pages to the svn equivalents which would > > pretty much cover the basics of a how-to guide: > > > > http://gcc.gnu.org/cvs.html > > http://gcc.gnu.org/cvswrite.html > > I understand patches for at least some of (contrib, maintainer-scripts, > wwwdocs) to convert to svn are ready. Could whichever patches are ready > be posted to gcc-patches? That way people can test them, and see if > anything still needs converting. (In the case of > maintainer-scripts/gcc_release, all of the mainline, 4.0 and 3.4 versions > are relevant as each branch's version is used for releases from that > branch. In the case of contrib/gcc_update each active branch will need > its version patched but the same patch should work in each case. > Otherwise I think only mainline versions are relevant.) > I should probably note again that i don't plan to convert wwwdocs to svn right now, because the checkout scripts are a bit hard to follow, etc.
Re: Final Subversion testing this week
On Sun, 2005-10-16 at 23:20 +0200, Florian Weimer wrote: > * Daniel Berlin: > > > CVS write access users should give the subversion setup a try this week. > > > > Directions on how to do common operations are at > > http://gcc.gnu.org/wiki/SvnHelp > > > > I have placed the repo in exactly the place on gcc.gnu.org it will end > > up in during the final conversion, and in the exact condition (IE tags, > > branches, etc) it will be in when we convert, minus the changes over the > > next week > > Is it okay to make an unreviewed test commit? > > I might be have missed something, but the ChangeLogs will still be > maintained, will they? Uh, commit all you want. Yes, changelogs wil still be maintained.
Re: Final Subversion testing this week
Andreas Schwab <[EMAIL PROTECTED]> writes: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > > CVS write access users should give the subversion setup a try this week. > > Is there a branch that represents the tip of the old-gcc repository? It > appears that premerge-fsf-branch is intented to be this, but it is missing > many files from old-gcc repository. Yes, premerge-fsf-branch is supposed to be a branch holding all revisions of files changed at the FSF sources after the merge from the FSF sources into the EGCS sources. Now I see that I failed to add the branch tag to files in old-gcc which were not modified after the merge. I updated the cvs sources on gccmerge-branch, and regenerated /pool/ian/repo. I tested a checkout of premerge-fsf-branch, and the only differences I saw were due to RCS keyword expansion. Hopefully Danny can incorporate this change into the final subversion conversion. Thanks for noticing. Ian
Re: Final Subversion testing this week
* Daniel Berlin: >> Is it okay to make an unreviewed test commit? > Uh, commit all you want. Permissions don't seem to be set correctly: SendingChangeLog Sendinglibgcc2.h Transmitting file data ..svn: Commit failed (details follow): svn: Can't create directory '/svn/gcc/db/transactions/105361-1.txn': Permission denied (My user account is "fw", in case this matters.)
Re: Final Subversion testing this week
On Sun, 2005-10-16 at 23:59 +0200, Florian Weimer wrote: > * Daniel Berlin: > > >> Is it okay to make an unreviewed test commit? > > > Uh, commit all you want. > > Permissions don't seem to be set correctly: > > SendingChangeLog > Sendinglibgcc2.h > Transmitting file data ..svn: Commit failed (details follow): > svn: Can't create directory '/svn/gcc/db/transactions/105361-1.txn': > Permission denied > > (My user account is "fw", in case this matters.) Oh, hold on, yer right. Okay, fixed.
[Fwd: ezmlm warning]
Hi, Is this spam, a temporary glitch at gcc-central or what? I checked my mailbox and all is well. Paul Thomas --- Begin Message --- Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. Messages to you from the fortran mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the fortran mailing list, without further notice. I've kept a list of which messages from the fortran mailing list have bounced from your address. Copies of these messages may be in the archive. To retrieve a set of messages 123-145 (a maximum of 100 per request), send an empty message to: <[EMAIL PROTECTED]> To receive a subject and author list for the last 100 or so messages, send an empty message to: <[EMAIL PROTECTED]> Here are the message numbers: 8038 8148 8149 8147 8152 8153 8154 8151 8155 8150 8157 8156 8158 8159 8160 8161 8162 8163 8164 8165 8166 8167 8168 8169 8170 8171 8172 --- Enclosed is a copy of the bounce message I received. Return-Path: <> Received: (qmail 10817 invoked for bounce); 5 Oct 2005 03:43:27 - Date: 5 Oct 2005 03:43:27 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1128213407sourceware.org22936393" Subject: failure notice Hi. This is the qmail-send program at sourceware.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: Sorry, no mailbox here by that name. (#5.1.1) --- End Message ---
Re: [Fwd: ezmlm warning]
Paul Thomas <[EMAIL PROTECTED]> writes: > Is this spam, a temporary glitch at gcc-central or what? I checked my > mailbox and all is well. This type of message is best sent to [EMAIL PROTECTED]; thanks. As far as I can tell, e-mail messages to you are going through fine. You are still on the fortran mailing list. We only have a few days of e-mail logs--they don't go back to October 5, so I don't know what was happening back then. It may have been a glitch of some sort, although I haven't seen this sort of glitch before. Ian
Re: Final Subversion testing this week
> > We can now identify the exact version of gcc t have simply by the > > revision number and branch name. So maintaining all this stuff in a > > DATESTAMP, etc, is severe overkill when you could simply use the result > > of "svnversion .' and commit that to a file, or do it client side). > > I think we want a meaningful version in the --version output regardless of > how someone got GCC (including where what they have is not an SVN tree and > so can't have svnversion run in it; e.g. obtained with svn export). If a > hook can make every commit update (on whatever branch or branches are > affected by that commit) a checked in file with the output of svnversion > in, in addition to the files explicitly modified by that commit, that > would suffice. A close approximation to that could be had by enabling keyword substitution for DATESTAMP and changing its content to "$Rev$". We'd then get version strings like "4.1.0 $Rev: 105363$ (experimental)", which I think would be fine. The magic for getting rid of the stamp in an official release is all in gcc/Makefile.in and shouldn't be affected. The catch, though, is DATESTAMP is also used to set the value of __GLIBCXX__ over in c++config.h (see libstdc++-v3/include/Makefile.am). I'm not sure what to do about that. zw
Minor Tree-SSA Documentation Oddities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Can someone familiar with Tree-SSA please fix the following documentation oddities? In tree-ssa-operands.c, the comment for the function update_stmt_operands() seems to be wrong - it's referring to get_stmt_operands(), which is nowhere to be found. This reference is present inside in the function body as well. I could have done a "s/get_stmt_operands/update_stmt_operands/g" myself, but I was not completely sure of the veracity of the resulting sentences. The "TODOs" and the "CROSSREFs" in this section need to be cleaned up: http://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html Thanks in advance, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDU0WRYb1hx2wRS48RAgXNAJwK1K9/m6rfL+U3XIikRPm22MteRACfXU9X IJT+KmEBPMB4HXMueUtQcZA= =d6gR -END PGP SIGNATURE-
