Re: gcc-gdb compatibilty
Thanks Daniel for the useful piece of information. Initially I thought of error from compiler side...Now I consider upgrading my gdb . Thanks, Sumanth Daniel Jacobowitz wrote: On Sat, Apr 25, 2009 at 10:35:07AM -0700, Ian Lance Taylor wrote: Yes, while there are of course occasional bugs and mismatches, in general all versions of gcc and gdb are compatible. That said, gdb 5.3 is old; it was released over five years ago. It will ignore some of the newer types of debugging information emitted by gcc. The current gdb release is 6.8, and is considerably enhanced over 5.3. You should consider upgrading if possible. Newer GDB almost always works with older GCC. Older GDB often does not work with newer GCC; I suspect 5.3 will crash and/or be useless with most GCC 4.x binaries. For instance, in that time we added location list support.
Re: Slush: Bug-Fixes Only for Middle End and Primary Platforms
On Tue, Apr 28, 2009 at 11:12 PM, Mark Mitchell wrote: > We're in Stage 1, and in Stage 1 big changes happen -- and then there is > naturally some instability. We clearly have some instability at > present, so we need to slow down until that's resolved. Bah. > With the benefit of hindsight, I think that committing both the SSA > expansion and type-checking changes in close succession was probably a > bit too much change a bit too quickly. When changes of this magnitude > go in, we should probably wait a few days to see if stabilization is > required before introducing another change of large magnitude. Many of the changes that have gone in simply lacked testing. You mention the type-checking changes, but that is probably the only big change that *was* properly tested and where the failures it has caused are just small but easily (and already) fixed. On the other hand: It cannot be that the SSA expansion goes in without working on half the primary targets. That means it just wasn't tested properly, for such a big-impact. Was it really only tested on x86-64 before going onto the trunk? Isn't there the "test-on-three-targets" rule for big-impact merges? Likewise for much of the pretty-ipa patches, which go in as "merges" but haven't been in the branch for more than a few days in some cases. Plus, many of the regressions were just test suite failures that, for some reason, were overlooked or ignored before committing the patches. Looks like the dump&go approach to me. By contrast: I held off the gcse DF-ify patch for two weeks because I found one (1) regression on an obscure libgomp test case during re-testing *after* the patch had been approved. I didn't want to cause breakage and so I first tracked down and fixed this one regression before committing. Now I have a backlog of ~5 tested patches to submit, but I have to wait thanks to less careful people :-( Next time, a much better approach IMHO would be to just revert the offending patches until they're properly tested and most issues are fixed *before* the patches go on the trunk. Ciao! Steven
gcc-4.4-20090428 is now available
Snapshot gcc-4.4-20090428 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090428/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 146916 You'll find: gcc-4.4-20090428.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090428.tar.bz2 C front end and core compiler gcc-ada-4.4-20090428.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090428.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090428.tar.bz2 C++ front end and runtime gcc-java-4.4-20090428.tar.bz2 Java front end and runtime gcc-objc-4.4-20090428.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090428.tar.bz2The GCC testsuite Diffs from 4.4-20090421 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: Documentation on running dejagnu with qemu?
On Tue, 2009-04-28 at 14:52 -0700, Doug Kwan (關振德) wrote: > I would like to run the testsuite using qemu as the gdb simulator does > not support newer ARMs. However, there does not seems to be any good > documents on that topic. Could someone give me a pointer or two? If you are running a full operating system image in qemu, the easiest way is to set it up with an FTP/telnet server (or SSH server) so that you can treat the system as a remote Unix system. It would probably be best to take follow-ups to the dejagnu list. Cheers, Ben
Documentation on running dejagnu with qemu?
I would like to run the testsuite using qemu as the gdb simulator does not support newer ARMs. However, there does not seems to be any good documents on that topic. Could someone give me a pointer or two? Thanks. -Doug
Slush: Bug-Fixes Only for Middle End and Primary Platforms
We're in Stage 1, and in Stage 1 big changes happen -- and then there is naturally some instability. We clearly have some instability at present, so we need to slow down until that's resolved. Therefore, effective immediately, please commit only bug fixes to the middle end and to architectures that are designated as primary platforms. Please hold off on new features for these areas of the compiler, until things stabilize. It's OK to continue to add new features to secondary platforms and front ends, but I suggest that we exercise caution there as well. We'll stay in this mode until we've gotten back to the point where test results are looking pretty good on all of the primary platforms -- hopefully just a few days. With the benefit of hindsight, I think that committing both the SSA expansion and type-checking changes in close succession was probably a bit too much change a bit too quickly. When changes of this magnitude go in, we should probably wait a few days to see if stabilization is required before introducing another change of large magnitude. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Checking for the Programming Language inside GCC
On Tue, Apr 28, 2009 at 7:50 PM, Shobaki, Ghassan wrote: > Hi, > > In some optimization passes it may be useful to know the programming > language that we are compiling. Is there a way to get that information > in the middle end and back end? There is no way that should be used in new code. Richard.
Re: conversion of .cc 3.3.5 files to gcc 4.3.2
My c++ sourcefiles that compile with gcc 3.3.5 generate hundreds of errors if compiled with gcc 4.3.2. Where can I find guidelines on how to change my files? http://gcc.gnu.org/gcc-3.4/changes.html http://gcc.gnu.org/gcc-4.0/changes.html etc... under the C++ sections. In my experience, most C++ changes came from 3.4 and 4.0. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
conversion of .cc 3.3.5 files to gcc 4.3.2
My c++ sourcefiles that compile with gcc 3.3.5 generate hundreds of errors if
compiled with gcc 4.3.2.
Where can I find guidelines on how to change my files?
Thanks
Nieuwenhuizen, J.K.
2009-04-28T22:23
+===+
| I start every day with the deletion of abt 200 spams and alike and |
| close the day similarly. |
| If you send me a non-spam, please make yourself recognizable in the |
| sender - address { and | or } the subject. |
| |
| |
| Nieuwenhuizen, Prof. Ir. J.K. email:j...@nieuwenhuizen-jk.nl |
| 5624 KZ 8 The Netherlands internet: www.nieuwenhuizen-jk.nl |
| Tel. [{..31 | 0}40] 2442226 |
+===+
Re: Checking for the Programming Language inside GCC
Basile STARYNKEVITCH wrote: > Shobaki, Ghassan wrote: >> In some optimization passes it may be useful to know the programming >> language that we are compiling. Is there a way to get that information >> in the middle end and back end? > > I am not sure that would be a good idea. In fact you are suggesting that > the intermediate representation[s] (ie Gimple) is not intermediate > enough, since you need something more (like the source language). I think some kind of optimization behaviour depends on the language used, but this should be represented in some way in the Gimple and not via some parsing of the programming language. One example is "-fcx-fortran-rules" which allows for complex multiplication and division to follow the Fortran rules - it is used when compiling the gfortran library, but I think it is also a good option for several C programs as it goes a middle way between strict IEEE and maximal optimization. Another example of language specifics is the handling of parenthesis: Fortran requires that they are honoured, e.g. for (a/b)/c the optimization a/(b*c) is not allowed. This is honoured via PAREN_EXPR and thus there is no need to know the programming language. Thus I'm in favour of programming language specific optimization - by having it expressed in the Gimple itself. Tobias PS: I think one exception are debugging symbols - there is some language dependence, but I think no plug-in support is planed for this.
Re: Checking for the Programming Language inside GCC
On Tue, Apr 28, 2009 at 10:50:52AM -0700, Shobaki, Ghassan wrote: > In some optimization passes it may be useful to know the programming > language that we are compiling. Is there a way to get that information > in the middle end and back end? Is that really a good idea? If a particular optimization, on the same middle-end structure, is valid in one language and not in another, that would suggest a problem with the implementation.
Re: Checking for the Programming Language inside GCC
Shobaki, Ghassan wrote: > In some optimization passes it may be useful to know the programming > language that we are compiling. Is there a way to get that information > in the middle end and back end? Hmm. I would rather that the amount of language-specific optimization were kept to an absolute minimum. I maintain the Java front-end, and the fact that the optimizers I use work the same way for C makes me very happy. I wouldn't do it if I were you. Better to find a way to describe what you need to do in a langauge-independent form. Andrew.
Re: Any plans to upgrade svn repository format to 1.5.0+ ?
Oh, OK. Apparently there is no way to query directly the repository version on a server, so I misused some dry-run merge command to find out. Anyway, I have tried svn trunk -> branch merge and it works, provided that at least 1.5.5 client is used. I haven't tested branch -> trunk (I wish I could :) with svn merge --reintegrate nor can I test svnmerge.py -> svn 1.5.0 merge upgrade. So, unless somebody objects (a lot of things are untested, after all), I will update http://gcc.gnu.org/wiki/SvnBranch to document how to use svn 1.5.5 to maintain branches. -- Laurynas 2009/4/26 Daniel Berlin : > Errr, the format is not pre-1.5.0 > It was svnadmin upgraded a while ago. > > > On Sat, Apr 25, 2009 at 5:06 AM, Laurynas Biveinis > wrote: >> Hi, >> >> Apparently the server is already running svn 1.5.5 but the repository >> format is pre-1.5.0. If the repository format was upgraded, we could >> start using proper svn merge support for branch maintenance and get >> rid of manual merges and svnmerge.py. There is even an upgrade path >> from the svnmerge.py to svn 1.5.0 merge support for existing branches. >> And the upgrade would not disturb those who are using pre-1.5.0 svn >> clients. >> >> Any thoughts? >> >> -- >> Laurynas >> >
Re: Checking for the Programming Language inside GCC
Shobaki, Ghassan wrote:
In some optimization passes it may be useful to know the programming
language that we are compiling. Is there a way to get that information
in the middle end and back end?
I am not sure that would be a good idea. In fact you are suggesting that
the intermediate representation[s] (ie Gimple) is not intermediate
enough, since you need something more (like the source language).
And there might be some scenarii where making a programming language
dependent optimization is wrong. Consider for example compiling with
your GCC the output of the old f2c (fortran to C) translator. Would you
consider that being C or Fortran?
I would believe you should at least explain what exactly are the
language dependent optimizations you are thinking of (is it for matrix
code in Fortran vs C?).
Still, I tend to believe that if you really need some language specific
information, that would be better settled in the long term thru an
evolution or enhancement of the middle end representations...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Checking for the Programming Language inside GCC
Hi, In some optimization passes it may be useful to know the programming language that we are compiling. Is there a way to get that information in the middle end and back end? Thanks in advance! -Ghassan
Re: Using MPC Library with GCC
From: "Mark Mitchell" That is not a decision, however, on whether using MPC is or is not a good idea. There have been objections raised to MPC, on the grounds that it may not build on all host systems, or that the costs it brings in terms of complexity of building GCC outweigh its benefits. We should reach consensus on those issues before making a decision about whether to depend upon it. Thanks Mark. Although I personally felt that the GPLv3-compatible license terms were sufficient from a legal and policy perspective, it's good to clarify this officially for future circumstances as well as retroactively for the libraries we already depend on. Also I agree that the remainder of the discussion (i.e. whether it's a "good idea" in this particular case) should be conducted in the public forum and that's what I asked for in my proposal to the SC. So to address the remaining concerns, I'll first note that the portability issue has been dealt with. The MPC developers adopted GCC's primary and secondary platform list to aid in the integration with GCC. Thanks to the participation of many developers on this list, MPC version 0.6 has been tested successfully on all of them as well as a long list of tertiary systems. One or two minor nits arose in mpc-0.6 however they are in parts of the library that I don't use inside GCC and anyway will be fixed in the forthcoming mpc-0.6.1. See: http://www.multiprecision.org/index.php?prog=mpc&page=platforms The second issue related to "cost" MPC brings vs "benefits". To fully explore this you have to compare it to the cost of not using MPC. If we don't use MPC, the fortran maintainers will have to replicate much of MPC's functionality to support intrinsics. It's already partially implemented for the "easy" cases so far but several harder bits remain. When I compare the fortran implementation with the MPC copies, the MPC versions include extra code to ensure last-bit accuracy whereas the fortran cases don't. IMHO we should leave these special math cases to experts in the field instead of rolling our own versions of this code. The second cost of not using MPC means that we'll have to fix bugs in the middle end ourselves in the folding of complex expressions. Again, we're not best equipped to understand the corner cases of this and why duplicate code that's already out there? After that, the optimizations I provided for complex builtins becomes gravy, and that doesn't even begin to explore future uses of MPC that I haven't thought of yet. Sure, if you don't use complex numbers in your code you probably won't care about this and everything becomes a "cost". But since complex numbers are part of the languages specs, we need to deal with it. So from a code-duplication standpoint, from a language conformance standpoint, from a bugfix standpoint, and finally from an optimization standpoint, all of these would be a win. The downside is that you have to build and install MPC one time, or unpack it in your GCC source dir since I provided support for in-tree building. Either way, it's not that hard. :-) --Kaveh
Re: gcc-gdb compatibilty
On Sat, Apr 25, 2009 at 10:35:07AM -0700, Ian Lance Taylor wrote: > Yes, while there are of course occasional bugs and mismatches, in > general all versions of gcc and gdb are compatible. That said, gdb 5.3 > is old; it was released over five years ago. It will ignore some of the > newer types of debugging information emitted by gcc. The current gdb > release is 6.8, and is considerably enhanced over 5.3. You should > consider upgrading if possible. Newer GDB almost always works with older GCC. Older GDB often does not work with newer GCC; I suspect 5.3 will crash and/or be useless with most GCC 4.x binaries. For instance, in that time we added location list support. -- Daniel Jacobowitz CodeSourcery
Re: Slush, please?
Hans-Peter Nilsson wrote: > I don't see a request, yet more than two people seem to agree, > so: can we have a slush (no new merges or features) while the > tree is stabilized? > > I'll let other people answer the "why" wrt. priority platforms; > the double breakages for cris-elf (PR39927, PR39938) don't > count. :/ Even if all the primary/secondary platforms were fixed right now, I think that it is good to slow down, since we found out the hard way that SSA expansion has relatively deep target-dependent ramifications. Paolo
Re: Slush, please?
On Tue, Apr 28, 2009 at 7:17 AM, Hans-Peter Nilsson wrote: > I don't see a request, yet more than two people seem to agree, > so: can we have a slush (no new merges or features) while the > tree is stabilized? > > I'll let other people answer the "why" wrt. priority platforms; > the double breakages for cris-elf (PR39927, PR39938) don't > count. :/ There are some testsuite failures on powerpc-darwin (there was a bootstrap failure but I just fixed that though). Thanks, Andrew Pinski
Slush, please?
I don't see a request, yet more than two people seem to agree, so: can we have a slush (no new merges or features) while the tree is stabilized? I'll let other people answer the "why" wrt. priority platforms; the double breakages for cris-elf (PR39927, PR39938) don't count. :/ brgds, H-P
Re: new offset outside bounds of constant string warning
2009/4/28 H.J. Lu : > 2009/4/27 Ben Elliston : >> On Manuel's recommendation, I have backed out revision 145102 for the >> time being. If someone wishes to have another go at it, the code is in >> svn. >> >> Cheers, Ben > > You should use "patch -E" apply any patches. I checked in revision 14689 > to remove the empty g++.dg/warn/pr35652.C and gcc.dg/pr35652.c. The tests could stay as XFAILED. Perhaps is too late... Cheers, Manuel.
Re: new offset outside bounds of constant string warning
2009/4/27 Ben Elliston : > On Manuel's recommendation, I have backed out revision 145102 for the > time being. If someone wishes to have another go at it, the code is in > svn. > > Cheers, Ben You should use "patch -E" apply any patches. I checked in revision 14689 to remove the empty g++.dg/warn/pr35652.C and gcc.dg/pr35652.c. -- H.J.
