RE: ARM FLOOR_MOD_EXPR?
in calls.c: tfom = lang_hooks.types.type_for_mode (outmode, 0); if (aggregate_value_p (tfom, 0)) for 64bit mod, outmode ends up TImode. Our frontend doesn't support TImode -- reasonable? -- and so type_for_mode returns NULL here. aggregate_value_p then derefences that NULL. At least that's what happens in 4.3. I tried hacking the C frontend to interpret % as FLOOR instead of TRUNC. It works though -- the C frontend supports TImode. Seems a little bit odd to depend on that? - Jay > From: jay.kr...@cornell.edu > To: gcc@gcc.gnu.org > Subject: ARM FLOOR_MOD_EXPR? > Date: Sat, 19 Jun 2010 08:17:16 + > > > Do FLOOR_DIV_EXPR and FLOOR_MOD_EXPR work on ARM, for 64bit signed integer? > I have a front end (sort of), using gcc 4.3, generates trees, doesn't work. >type_for_mode(TImode) is NULL and that is dereferenced. > I realize TRUNC_* would be far more "normal", but I can't change that. > I guess I'll just go back to generating function calls. > > - Jay >
Re: About the "info locals" command of gdb and python pretty printer
Hi, all. About the "info locals" and python pretty printer problem I post here: http://sourceware.org/ml/gdb/2010-06/msg00080.html see the result here: http://forums.codeblocks.org/index.php/topic,12747.msg86443.html#msg86443 I have solved this problem by hacking the GDB source code. You can see the changed code here: http://sourceware.org/bugzilla/show_bug.cgi?id=11407#c33 Asmwarrior (ollydbg from codeblocks' forum)
Re: Can GCC emit debug information to support debug uninitialized local variables
On 2010-6-20 14:18, Ian Lance Taylor wrote: asmwarrior writes: My question is: Is there any possible that GCC can emit some debug information to indicate that one variable is initialed or not.(at least in the DEBUG build mode) You didn't mention which version of gcc you are testing. With current gcc see if the -fvar-tracking option helps. Ian Hi, Ian. I have solved this problem by hacking the GDB source code. You can see my report here: http://forums.codeblocks.org/index.php/topic,12747.msg86443.html#msg86443 Now, only the variables been initialized will be shown in the "info locals" command. I will publish the related GDB code to GDB maillist. Thanks Asmwarrior ollydbg from codeblocks' forum
Re: ChangeLog licensing issues
Joseph S. Myers wrote: >> But if identifieres were OK, wouldn't that mean that auto-generating >> documentation that shows hook names along with argument types and names >> are also OK? > > I do not see any copyright issues with the hook names and argument types > and names. With the bodies of the descriptions of the semantics of the > hooks (in .texi or comments), yes, but not with the names and types of > hooks and their arguments. I agree. Joern, I don't think anything in the ChangeLogs that you are writing is going to be a problem. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
gcc-4.3-20100620 is now available
Snapshot gcc-4.3-20100620 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100620/ 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/branches/gcc-4_3-branch revision 161055 You'll find: gcc-4.3-20100620.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100620.tar.bz2 C front end and core compiler gcc-ada-4.3-20100620.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100620.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100620.tar.bz2 C++ front end and runtime gcc-java-4.3-20100620.tar.bz2 Java front end and runtime gcc-objc-4.3-20100620.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100620.tar.bz2The GCC testsuite Diffs from 4.3-20100613 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.
targethook argument names (Was: Re: ChangeLog licensing issues)
Quoting "Joseph S. Myers" : I do not see any copyright issues with the hook names and argument types and names. With the bodies of the descriptions of the semantics of the hooks (in .texi or comments), yes, but not with the names and types of hooks and their arguments. If that is actually the case, then there is a bit more code that I could consolidate between the struct targetm definition and its documentation. For some hooks, however, we'd have to decide on a single name for some arguments first: declare_constant_name expression: exp or expr? print_operand, print_operand_address FILE *: file or stream? print_operand_address address: addr or x? dfa_new_cycle dump file: dump_file or dump? last_sched_cycle or last_clock? cur_cycle or clock? resolve_overloaded_builtin parameter list: params or arglist? fold_builtin nargs or n_args? builtin_reciprocal tm_fn or md_fn? memory_move_cost register class: rclass or class
Re: ChangeLog licensing issues
On 20 June 2010 16:37, Joern Rennecke wrote: > > I spent a lot of time before getting the target hook code, comments and > documentation consistent, only to be told that the GCC maintainers have > no authority to move information from code or comments into documentation > or vice versa. For what is worth, as a GCC contributor, I really appreciate what you are trying to do and it is really sad that contributors have to fight to contribute to a project, specially in areas where the project is generally acknowledged as deficient and way behind alternative ones. Cheers, Manuel.
Re: ChangeLog licensing issues
On Sun, 20 Jun 2010, Joern Rennecke wrote: > Quoting "Joseph S. Myers" : > > > I suggest you recalibrate your understanding of the scope of copyright to > > be less expansive rather than supposing it to apply to "file names, > > function names and identifiers". > > But if identifieres were OK, wouldn't that mean that auto-generating > documentation that shows hook names along with argument types and names > are also OK? I do not see any copyright issues with the hook names and argument types and names. With the bodies of the descriptions of the semantics of the hooks (in .texi or comments), yes, but not with the names and types of hooks and their arguments. -- Joseph S. Myers jos...@codesourcery.com
Re: ChangeLog licensing issues
Quoting "Joseph S. Myers" : I suggest you recalibrate your understanding of the scope of copyright to be less expansive rather than supposing it to apply to "file names, function names and identifiers". But if identifieres were OK, wouldn't that mean that auto-generating documentation that shows hook names along with argument types and names are also OK? I don't see any fundamental difference between writing stuff like 'change type of argument foo of func to bar and rename to baz' to put it into a ChangeLog, and running a program to adjust a piece of documentation to reflect such a change. Arguing for its application to such elements may be accepted in certain industries based around the use of copyright, patent and trademark laws, DRM and closed software and devices against the public interest; it is not appropriate for work as part of the Free Software Movement. It's not that I want copyright be applied so broadly, but I'm trying to avoid a situation where my patch becomes unusable because of such issues. I spent a lot of time before getting the target hook code, comments and documentation consistent, only to be told that the GCC maintainers have no authority to move information from code or comments into documentation or vice versa. If the FSF wants its maintainers to have certain freedoms when handling the source code they handle on behalf of the FSF, it is best if this is spelled out in licences and/or policies, since national copyright regimes vary, contain legal uncertainties, and are subject to change.
Re: ChangeLog licensing issues
On Sun, 20 Jun 2010, Joern Rennecke wrote: > So it appears that writing ChangeLog entries for code from a branch where > I have no (longer) a connection with the original submitter requires > getting permission from the FSF to use the file names, function names > and identifiers mentioned, at least to the extent that they haven't been > mentioned in a ChangeLog before. I suggest you recalibrate your understanding of the scope of copyright to be less expansive rather than supposing it to apply to "file names, function names and identifiers". Arguing for its application to such elements may be accepted in certain industries based around the use of copyright, patent and trademark laws, DRM and closed software and devices against the public interest; it is not appropriate for work as part of the Free Software Movement. -- Joseph S. Myers jos...@codesourcery.com
Re: ChangeLog licensing issues
Quoting "Joseph S. Myers" : On Sun, 20 Jun 2010, Joern Rennecke wrote: What license / licenses are the ChangeLogs of GCC distributed under? ChangeLogs are licensed under the permissive terms given in the license notices at the bottom of each ChangeLog file, Oops, I missed that bit. So it appears that writing ChangeLog entries for code from a branch where I have no (longer) a connection with the original submitter requires getting permission from the FSF to use the file names, function names and identifiers mentioned, at least to the extent that they haven't been mentioned in a ChangeLog before. Lest someone things ChangeLog entries are trivial, I'm currently working on a patch of over 600 KB, and after going through 6% of that, I've gathered some 6KB of ChangeLog entry so far. Although the branch has ChangeLogs, they are not covering all new file & function names (with deadlines and company 'restructuring', this is sometimes unavoidable), and what there is also has some back-and-forth changes, and things that got moved into different functions and files during merges. So what should I do in this situation? Spend some days to write a new, proper ChangeLog entry to then wait some month for the FSF to authorize - or not - its use in a ChangeLog? Spend even more effort to censor anything from the ChangeLog entry that was not previously mentioned in a ChangeLog entry? Or should I just slap a laconic 'merge from XXX branch' on an indented version top of the old branch-specific ChangeLog entries?
Re: ChangeLog licensing issues
On Sun, 20 Jun 2010, Joern Rennecke wrote: > What license / licenses are the ChangeLogs of GCC distributed under? ChangeLogs are licensed under the permissive terms given in the license notices at the bottom of each ChangeLog file, which were the terms the FSF recommended for "rough documentation" at the time I added the notices to the files. (Since then, an additional sentence "This file is offered as-is, without any warranty." has been added to the recommended notice, though the instructions say "There is no urgent need to update existing files".) -- Joseph S. Myers jos...@codesourcery.com
ChangeLog licensing issues
What license / licenses are the ChangeLogs of GCC distributed under?
This is of practical importance when I want to amend incomplete ChangeLogs
or use information from a ChangeLog to complete comments and/or documentation,
or want to write a ChangeLog for fixing a misspelling in code or documentation
that is not replicated in the ChangeLog entry for the original contribution.
Can I use function names from GPLed code to put them in a ChangeLog?
Can I use names of sections or concepts, or misspellings in GFDLed
documentation (like {trunk,branch}/gcc/doc/*.texi, which shares its
ChangeLog with GPLed code in {trunk,branch}/gcc), to put them in a ChangeLog?
Can I use narrative text from a ChangeLog to put it into a comment in GPLed
code or in GFDLed documentation?
Note, I do not reside in the USA, so AFAIC I can't use the USA's 'fair use'
provisions directly. (If someone else uses them to effectively relicense
affected matter, I suppose I can work with the resulting work).
