Re: PATCH: m68k PIC touchup
Peter S. Mazinger wrote:
--- gcc-4.0.2/gcc/config/m68k/linux.h.mps 2006-01-08 23:02:06 +0100
+++ gcc-4.0.2/gcc/config/m68k/linux.h 2006-01-08 23:03:02 +0100
@@ -85,6 +85,11 @@
LINUX_TARGET_OS_CPP_BUILTINS(); \
builtin_define_std (mc68000); \
builtin_define_std (mc68020); \
+ if (flag_pic) \
+ { \
+ builtin_define (__PIC__); \
+ builtin_define (__pic__); \
+ } \
This shouldn't be needed on HEAD because c-cppbuiltin.c
already defines them globally for all targets.
In gcc-4_0-branch and gcc-4_1-branch, __PIC__ and __pic__ are
already defined appropriately for all subtargets by the
TARGET_CPU_CPP_BUILTINS macro in m68k.h.
@@ -98,10 +103,10 @@
#undef CPP_SPEC
#if TARGET_DEFAULT MASK_68881
#define CPP_SPEC \
- %{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic__}
%{!msoft-float:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE}
%{pthread:-D_REENTRANT}
+ %{!msoft-float:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE}
%{pthread:-D_REENTRANT}
#else
#define CPP_SPEC \
- %{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic__} %{m68881:-D__HAVE_68881__}
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
+ %{m68881:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE}
%{pthread:-D_REENTRANT}
#endif
Dropping these from 4.0/4.1 should be harmless because
they are clearly redundant, but it's not a regression
so I'd not bother.
--
// Bernardo Innocenti - Develer S.r.l., RD dept.
\X/ http://www.develer.com/
Factoring _POSIX_SOURCE (Was: PATCH: m68k PIC touchup)
Bernardo Innocenti wrote:
--- gcc-4.0.2/gcc/config/m68k/linux.h.mps2006-01-08 23:02:06 +0100
+++ gcc-4.0.2/gcc/config/m68k/linux.h2006-01-08 23:03:02 +0100
@@ -85,6 +85,11 @@
LINUX_TARGET_OS_CPP_BUILTINS(); \
builtin_define_std (mc68000); \
builtin_define_std (mc68020); \
+if (flag_pic) \
+ { \
+builtin_define (__PIC__); \
+builtin_define (__pic__); \
+ } \
This shouldn't be needed on HEAD because c-cppbuiltin.c
already defines them globally for all targets.
btw, a cool cleanup could be factoring the various
_POSIX_SOURCE definitions from the subtargets and
handle it in c-cppbuiltin.c.
A few years ago we were trying to get rid of the old
spec syntax, but there are still plenty of definitions
in the target subdirs.
--
// Bernardo Innocenti - Develer S.r.l., RD dept.
\X/ http://www.develer.com/
Re: keeping branch up to date with mainline
Diego Novillo wrote: On Tuesday 03 January 2006 12:17, [EMAIL PROTECTED] wrote: how to keep my branch updated with the mainline? The easiest way is using svnmerge.py (included in SVN's contrib directory). There's documentation in the GCC wiki: http://gcc.gnu.org/wiki/SvnBranch Just tried these instructions on the reload-branch, and it doesn't appear to be working as documented: [EMAIL PROTECTED]:/local/src/egcs/reload-branch svnmerge.py init property 'svnmerge-integrated' set on '.' [EMAIL PROTECTED]:/local/src/egcs/reload-branch svn status ? svnmerge-commit-message.txt M . [EMAIL PROTECTED]:/local/src/egcs/reload-branch cat svnmerge-commit-message.txt Initialized merge tracking via svnmerge with revisions 1-96656 from svn+ssh://gcc.gnu.org/svn/gcc/branches/CYGNUS/libjava/testsuite/libjava.lang/Invoke_1.out [EMAIL PROTECTED]:/local/src/egcs/reload-branch svn diff Property changes on: . ___ Name: svnmerge-integrated + /branches/CYGNUS/libjava/testsuite/libjava.lang/Invoke_1.out:1-96656 [EMAIL PROTECTED]:/local/src/egcs/reload-branch svn commit -F svnmerge-commit-message.txt Sending. Committed revision 109540. [EMAIL PROTECTED]:/local/src/egcs/reload-branch rm svnmerge-commit-message.txt [EMAIL PROTECTED]:/local/src/egcs/reload-branch cd .. [EMAIL PROTECTED]:/local/src/egcs cp -a reload-branch/ reload-branch-merged [EMAIL PROTECTED]:/local/src/egcs cd reload-branch-merged/ [EMAIL PROTECTED]:/local/src/egcs/reload-branch-merged svnmerge.py avail [EMAIL PROTECTED]:/local/src/egcs/reload-branch-merged svnmerge.py avail --diff [EMAIL PROTECTED]:/local/src/egcs/reload-branch-merged Help? (The commit -F/rm combination seems a bit arcane to me, what exactly am I doing there?) Bernd
Re: keeping branch up to date with mainline
Bernd Schmidt [EMAIL PROTECTED] wrote: Just tried these instructions on the reload-branch, and it doesn't appear to be working as documented: [EMAIL PROTECTED]:/local/src/egcs/reload-branch svnmerge.py init property 'svnmerge-integrated' set on '.' This was the correct command to do, assuming that you *never* merged your branch since its original creation. I inspected the history of the branch (through 'svn log') and it seems this assumption is correct. So let's spot the problem... [EMAIL PROTECTED]:/local/src/egcs/reload-branch svn status ? svnmerge-commit-message.txt M . [EMAIL PROTECTED]:/local/src/egcs/reload-branch cat svnmerge-commit-message.txt Initialized merge tracking via svnmerge with revisions 1-96656 from svn+ssh://gcc.gnu.org/svn/gcc/branches/CYGNUS/libjava/testsuite/libjava.lang /Invoke_1.out [EMAIL PROTECTED]:/local/src/egcs/reload-branch svn diff You see that svnmerge believes that the head of your branch is svn+ssh://gcc.gnu.org/svn/gcc/branches/CYGNUS/libjava/testsuite/libjava.lan g/Invoke_1.out. This is obviously incorrect: it is a branch of the trunk, so this message should say svn+ssh://gcc.gnu.org/svn/gcc/trunk instead. This appears to be a bug in svnmerge: it is confused by the weird history created by cvs2svn. Look at the confusing output of svn log -v -r96657 svn://gcc.gnu.org/svn/gcc/branches/reload-branch, which is the commit that created the branch. It should just list A /branches/reload-branch (from /trunk:96656) and instead it contains many other entries. Anyway, I have fixed the bug in svnmerge and attached a new version for you in this mail. I have verified that running svnmerge init in a checkout of the reload-branch now does the right thing. Before doing that, remember to cleanup the wrong commit you did before: you can remove the svnmerge property, with this command: svn propdel svnmerge-integrated ., followed by a commit. For curiosity: you could have worked around this auto-detection problem by manually specifying the head of the branch and the branch point: svnmerge init /trunk -r1-96656. (The commit -F/rm combination seems a bit arcane to me, what exactly am I doing there?) Nothing special. The svnmerge tool *never* commits anything on your behalf: it always modifies your working copy and lets you review what it did and do the actual commit. To ease your work, it generates a simple commit message in a text file. When you say svn ci -F svnmerge-commit-message.txt, you're just telling svn to grab the commit message from the text file that svnmerge generated for you. Then, you can simply remove the file as it's useless. Feel free to mail me with other svnmerge problems, I'm happy to provide you with support. -- Giovanni Bajo #!/usr/bin/env python # -*- coding: utf-8 -*- # Copyright (c) 2005, Giovanni Bajo # Copyright (c) 2004-2005, Awarix, Inc. # All rights reserved. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA # # Author: Archie Cobbs archie at awarix dot com # Rewritten in Python by: Giovanni Bajo rasky at develer dot com # # Acknowledgments: # John Belmonte john at neggie dot net - metadata and usability # improvements # Blair Zajac blair at orcaware dot com - random improvements # # $HeadURL: http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge.py $ # $LastChangedDate: 2006-01-07 18:36:59 +0100 (Sat, 07 Jan 2006) $ # $LastChangedBy: giovannibajo $ # $LastChangedRevision: 18013 $ # # Differences from official svnmerge: # - More portable: tested as working in FreeBSD and OS/2. # - Add double-verbose mode, which shows every svn command executed (-v -v). # - svnmerge avail now only shows commits in head, not also commits in other # parts of the repository. # - Add svnmerge block to flag some revisions as blocked, so that # they will not show up anymore in the available list. Added also # the complementary svnmerge unblock. # - svnmerge avail has grown two new options: # -B to display a list of the blocked revisions # -A to display both the the blocked and the available revisions. # - Improved generated commit message to make it machine parsable even when # merging commits which are themselves merges. # - Add --force option to skip working copy check # # TODO: # - Add svnmerge avail -R: show logs in reverse order import sys, os, getopt, re,
Re: keeping branch up to date with mainline
This was the correct command to do, assuming that you *never* merged your branch since its original creation. I inspected the history of the branch (through 'svn log') and it seems this assumption is correct. Yes. Anyway, I have fixed the bug in svnmerge and attached a new version for you in this mail. Thanks for the quick fix. This seems to be working now (svnmerge.py avail gives me a rather enormous list of revision numbers). For curiosity: you could have worked around this auto-detection problem by manually specifying the head of the branch and the branch point: svnmerge init /trunk -r1-96656. That complains about svnmerge: /trunk is not a valid URL or working directory but no big deal since the other method works. (The commit -F/rm combination seems a bit arcane to me, what exactly am I doing there?) Nothing special. The svnmerge tool *never* commits anything on your behalf: it always modifies your working copy and lets you review what it did and do the actual commit. To ease your work, it generates a simple commit message in a text file. When you say svn ci -F svnmerge-commit-message.txt, you're just telling svn to grab the commit message from the text file that svnmerge generated for you. Then, you can simply remove the file as it's useless. Ah ok. Somehow I got confused with my old CVS mindset of no files changed, what am I committing, but I assume it's this property thing. Feel free to mail me with other svnmerge problems, I'm happy to provide you with support. Thanks! Bernd
Re: keeping branch up to date with mainline
One additional question, suppose I don't want to merge a huge number of revisions in one go, and I do svnmerge.py merge -r a-small-list-of-revisions svn diff ;; to verify everything is OK Do I then have to commit the merge so far before running svnmerge.py again, or can it get all the information it needs from the local repository? Bernd
Re: keeping branch up to date with mainline
Bernd Schmidt [EMAIL PROTECTED] wrote: Anyway, I have fixed the bug in svnmerge and attached a new version for you in this mail. Thanks for the quick fix. This seems to be working now (svnmerge.py avail gives me a rather enormous list of revision numbers). Yes. It'll take some time to merge them, even if it'll go through a single merge operation. You can use -v -v to add some debug message and see the exact svn commands issued, so that you can double check that it'll use a single merge operation for all of them. If you're curious, it displays an enormous list of revisions instead of a single revision range because svnmerge avail prunes it from commits happened in other branches, thus showing you only the list of actual commits to the trunk. This is more useful for release branches, where you want to review the single changes and cherry-pick the ones you like more (of couse, it makes more sense for smaller projects anyway). But when you do an actual merge, it realizes it is sufficient to call svn merge just once with a single range of revisions (since svn will ignore commits in other parts of the repository and merge just the changes from the trunk). For curiosity: you could have worked around this auto-detection problem by manually specifying the head of the branch and the branch point: svnmerge init /trunk -r1-96656. That complains about svnmerge: /trunk is not a valid URL or working directory but no big deal since the other method works. Ah right, I fogot you need to use a full URL on the command line. It's rather clumsy though: I should add support for repository-relative paths as well. (The commit -F/rm combination seems a bit arcane to me, what exactly am I doing there?) Nothing special. The svnmerge tool *never* commits anything on your behalf: it always modifies your working copy and lets you review what it did and do the actual commit. To ease your work, it generates a simple commit message in a text file. When you say svn ci -F svnmerge-commit-message.txt, you're just telling svn to grab the commit message from the text file that svnmerge generated for you. Then, you can simply remove the file as it's useless. Ah ok. Somehow I got confused with my old CVS mindset of no files changed, what am I committing, but I assume it's this property thing. Yup :) svn status would show you what's changed: M . Notice the 'M' on the second column. Second column is for properties: Second column: Modifications of a file's or directory's properties ' ' no modifications 'C' Conflicted 'M' Modified -- Giovanni Bajo
Re: keeping branch up to date with mainline
Bernd Schmidt [EMAIL PROTECTED] wrote: One additional question, suppose I don't want to merge a huge number of revisions in one go, and I do svnmerge.py merge -r a-small-list-of-revisions svn diff ;; to verify everything is OK Do I then have to commit the merge so far before running svnmerge.py again, or can it get all the information it needs from the local repository? No need to commit, but you'll have to use --force (-F), as otherwise it'd abort saying that your working copy is dirty. -- Giovanni Bajo
Re: keeping branch up to date with mainline
Bernd Schmidt [EMAIL PROTECTED] wrote: One additional question, suppose I don't want to merge a huge number of revisions in one go, and I do svnmerge.py merge -r a-small-list-of-revisions svn diff ;; to verify everything is OK Do I then have to commit the merge so far before running svnmerge.py again, or can it get all the information it needs from the local repository? Also note that, theoretically, it's better to do it in one-go as you'd end up with less conflicts. This is why svnmerge does it that way (and goes through large extent to automatically minimize the number of merge operations it performs). But if you know what you're doing, you can merge as much as you want at each go. -- Giovanni Bajo
Re: keeping branch up to date with mainline
Giovanni Bajo wrote: Bernd Schmidt [EMAIL PROTECTED] wrote: One additional question, suppose I don't want to merge a huge number of revisions in one go, and I do svnmerge.py merge -r a-small-list-of-revisions svn diff ;; to verify everything is OK Do I then have to commit the merge so far before running svnmerge.py again, or can it get all the information it needs from the local repository? Also note that, theoretically, it's better to do it in one-go as you'd end up with less conflicts. Why is that - do you mean merge conflicts? I imagine that most of the revisions from trunk will just apply cleanly since the files are unchanged on the branch. For changes in reload*.*, I'd rather merge one revision at a time and make sure I update the affected files properly (I very much doubt any large change will apply cleanly in those files; they'll need manual intervention). I assume it'll be easier to correct merge errors for every individual change rather than trying to piece them together after a monster merge. Bernd
Re: keeping branch up to date with mainline
Bernd Schmidt [EMAIL PROTECTED] wrote: One additional question, suppose I don't want to merge a huge number of revisions in one go, and I do svnmerge.py merge -r a-small-list-of-revisions svn diff ;; to verify everything is OK Do I then have to commit the merge so far before running svnmerge.py again, or can it get all the information it needs from the local repository? Also note that, theoretically, it's better to do it in one-go as you'd end up with less conflicts. Why is that - do you mean merge conflicts? Yes. I'm speaking of the general case, of course. Think of two trunk commits modifying the same file at the same place: if you merge in one go, you'll end up with a single conflict. If you do more merge operations, the file might conflict twice, ending up with two sets of merge markers (and two set .rXXX files, ecc.). If you clean up after each merge, it's of course better, but you'll still have to clean up twice instead of once. But of course, it's up to you to decide what's the best for you branch. I imagine that most of the revisions from trunk will just apply cleanly since the files are unchanged on the branch. For changes in reload*.*, I'd rather merge one revision at a time and make sure I update the affected files properly (I very much doubt any large change will apply cleanly in those files; they'll need manual intervention). I assume it'll be easier to correct merge errors for every individual change rather than trying to piece them together after a monster merge. I understand, and I reckon this is the best for your situation. svnmerge can handle range of changes as well as cherry-picking single changes, and will correctly keep track of everything. Let me know if it works out correctly. -- Giovanni Bajo
Re: Memory leak in bt-load.c ?
* Christophe Jaillet ([EMAIL PROTECTED]) [20060109 20:00]: in file 'bt-load.c', in function 'augment_live_range', some memory is xmalloc'ed. It seems to be possible to never free it, if all the first tests are true. This is now PR 25739. Philipp
Broken Links on Your Online Docs Web Page?
Hi. On your online docs web page (http://gcc.gnu.org/onlinedocs/), all the links for GCC 3.4.5 GNAT User's Guide bring up a message that the page cannot be found. The paths for the links look consistent in their format to other links that work, which makes me wonder if the docs just aren't there or are there, but with filenames or directory names that don't match the link. I was interested in having access to the PDF and HTML links for the 3.4.5 GNAT User's Guide. Can you help? Thanks, Chris Miller Technical Publications LynuxWorks, Inc.
Re: matrix linking
In short, you are proposing that instead of linking an executable, it be made into a bunch of shared libraries. The function calls between these shared libraries be arbitrated by a dispatcher which can dynamically reroute function calls. There already exists a technique to do this if you're willing to restart your app: incremental linking. Many IDEs support something like this (it's called ZeroLink in Apple's Xcode, for example), and even GNU ld has the -r option, which makes an object file relocatable, making it quicker to link. If you want to be able to do this without restarting, there are some challenges: 1) Static variables in modules would present problems, as these would have to somehow be reinitialized to their values in the old module (for instance, if you have a static pointer to a malloc()ed data structure). 2) If you plan to interpret code, the C interpreter would have to be taught to access symbols in other modules if they are undefined in the module it is interpreting. 3) You would have to figure out how to interpose on functions called via function pointers. 4) In a multithreaded application, you'd have to make sure that module replacement is atomic and you handle the case of replacing a module at a time where a thread is executing a function in it. Perhaps others on this list can come up with more issues to resolve. If you can come up with a solid system that addresses the issues with dynamic replacement of code, you will probably be able to get at least a conference paper and possibly even a job out of it :) Sean On Jan 10, 2006, at 7:32 AM, [EMAIL PROTECTED] wrote: Dear Sirs. At the first, let me put a lot of appreciations for what you are doing. At the second, respecting your time, I will straight to the matter. I have some kind of an idea, which I called 'matrix linking'. It would appear this is a new kind of linking. Briefly it gives (C/C++) developer the opportunity to change the business logic of the application at run- time, neither recompilation nor restarting required. The point is that the approach makes possible to substitute any function of the code, in such wise some of them might be merely executed by means of a script machine (interpreter). The basic concept and the simple realization of the idea are represented here: http://www.georgeshagov.com/matrixlinking/MatrixLinking/ MatrixLinking.pdf. (I am attaching the article to the message) I had some ideas how to put the invention in solution (here: http://docs.georgeshagov.com/twiki/tiki-index.php, http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix +Linking+-+The+shortest+way+to+go). What do I want from you is some kind of assistance. Of cause I have GCC sources and manuals, theoretically it is enough to make the changes, yet, if someone from GCC team had assist me in that the result would be much better, since you know the compiler much better than I. For instance. By now I have these questions: * I am looking at build_function_call and start_function functions, these ones actively use 'tree'. I am not familiar with that. So,: ** Is there any documentation on that? ** Is there any help functions which works with 'tree', like doing iteration, dumping and so on. ** What are the external values for cc1? File name for instance, and so on. I do understand that these questions seem to be really abstract. But I think that to contact GCC team at the very beginning of the investigation should be a good idea. For it might be (I believe should be) some architectural solution, which might be offered by you will be really useful in the future. Therefore dear Sirs, if you find the idea interesting and some one of you will find a time and a wiliness to cooperate I would be really appreciate. Sincerely your, George. MatrixLinking.pdf
ggc 3.3.2 on aix 5.2 long long type?
I getting the following warning with unsigned long long world_wide_name; (scsi_buf.h). warning : integer constant is too large for long type. Is there a swich I need to add? I am just using: gcc -o test test.c Thanks! -- View this message in context: http://www.nabble.com/ggc-3.3.2-on-aix-5.2-long-long-type--t890504.html#a2308440 Sent from the gcc - Dev forum at Nabble.com.
Missing GNAT docs (was Broken Links on Your Online Docs Web Page?)
On Tue, Jan 10, 2006 at 10:28:26AM -0800, Chris Miller wrote: On your online docs web page (http://gcc.gnu.org/onlinedocs/), all the links for GCC 3.4.5 GNAT User's Guide bring up a message that the page cannot be found. The paths for the links look consistent in their format to other links that work, which makes me wonder if the docs just aren't there or are there, but with filenames or directory names that don't match the link. I was interested in having access to the PDF and HTML links for the 3.4.5 GNAT User's Guide. Can you help? Hi, I can't help to put the 3.4.5 docs there, but the 3.4.4 docs are available, just change the 5 in the broken URLs to a 4. I don't know for certain, but I doubt the changes were very significant. jon -- Anybody who hates dogs and loves whiskey can't be all bad. - W.C. Fields
Status of -fstack-usage?
Hello, whats the status of -fstack-usage? Will it output the real or worst case stack usage? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: keeping branch up to date with mainline
One more question (I'm experimenting... excuse the stupid questions but I'd rather not accidentally mess up the branch). What I did now was, first, ~/svnmerge.py merge -r 96659-96679 just to get started, then ~/svnmerge.py merge -F -r 96681,big list of numbers,9 with the list of numbers cutpasted from the output of ~/svnmerge.py avail. (That second command took a rather long time). What should be the contents of the svnmerge-integrated property after that? svn diff gives me: Property changes on: . ___ Name: svnmerge-integrated - /trunk:1-96656 + /trunk:1-10,snip,103808-103809,1 i.e. it seems to contain exactly the revision numbers I didn't want to merge yet. Is this expected? Bernd
gcc-3.4-20060110 is now available
Snapshot gcc-3.4-20060110 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060110/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 109554 You'll find: gcc-3.4-20060110.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20060110.tar.bz2 C front end and core compiler gcc-ada-3.4-20060110.tar.bz2 Ada front end and runtime gcc-g++-3.4-20060110.tar.bz2 C++ front end and runtime gcc-g77-3.4-20060110.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20060110.tar.bz2 Java front end and runtime gcc-objc-3.4-20060110.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20060110.tar.bz2The GCC testsuite Diffs from 3.4-20060103 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.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: libgcc.a, et. al.
Making slow progress... I now have libstdc++ compiled as standalone I am down to free, malloc, abort, and _restf4. free and malloc I can hook up to net_free and net_malloc. abort I can hook up to panic. Its the _restf14 that gets me. It is pulled in from unwind_dw2.o of libgcc_eh.a. The IBM pubs tells me its part of the floating point linkage convention. So, it sounds to me like I need to recompile libgcc_eh.a with the soft-float option. Can someone help me do this with minimal stress? Thanks, Perry On Jan 8, 2006, at 1:45 PM, David Edelsohn wrote: Perry Smith writes: Perry Maybe you can help on another item. I recall back around 1995 or so, Perry gcc could not be used for AIX device drivers because it did not Perry handle the floating point registers properly. I have only a vague Perry memory of this. Do you recall anything like that? GCC will generate uses of floating point registers from source code that only describes integer computations. GCC 4.1 will do so less often, but nothing has changed to prevent it. One can use the soft- float option, but this confuses people who want to use floating point registers in code that does describe floating point computations. David
Re: keeping branch up to date with mainline
Bernd Schmidt [EMAIL PROTECTED] wrote: One more question (I'm experimenting... excuse the stupid questions but I'd rather not accidentally mess up the branch). What I did now was, first, ~/svnmerge.py merge -r 96659-96679 just to get started, then ~/svnmerge.py merge -F -r 96681,big list of numbers,9 with the list of numbers cutpasted from the output of ~/svnmerge.py avail. (That second command took a rather long time). There is no need to cut paste the exact revision numbers. svnmerge avail shows you the exact revisions that are not merged yet, but svnmerge merge is smart and won't merge twice a revision already merged, nor a revision which does not refer to a commit to another branch. If you want to merge everything up to revision 10, you can just do: ~/svnmerge.py merge -r96681-10, or even ~/svnmerge.py merge -r1-10. Property changes on: . ___ Name: svnmerge-integrated - /trunk:1-96656 + /trunk:1-10,snip,103808-103809,1 i.e. it seems to contain exactly the revision numbers I didn't want to merge yet. Is this expected? Yes, even if it might look confusing. If you try svn log -r103809 http://gcc.gnu.org/svn/gcc/trunk;, you'll see that the log is empty. If you then try svn log -v -r103809 http://gcc.gnu.org/svn/gcc;, you'll see that it's a commit on the 4.0 branch. Basically, svnmerge is reporting as integrated revisions that won't ever need to be merged because they're not on trunk. It's doing it so that, when you are finished merging from trunk, your svnmerge-integrated property will be a solid range, like 1-108904 or whatever. In short: trust it :) As for the slowness, there are a couple of low-hanging fruits which I haven't address yet. One glaring issue is that generating the log message for a big merge operation can take longer than merging itself (e). If you feel familiar with Python, feel free to comment out the log generation code in action_merge. Giovanni Bajo
[Bug c/25732] New: Compiling GCC 3.3 per Definitive Guide to GCC book; directory layout per book
Halts compile with
In file included from ../../gcc-3.3/gcc/read-rtl.c:24:
../../gcc-3.3/gcc/rtl.h:132: warning: type of bit-field code is a GCC
extension
../../gcc-3.3/gcc/rtl.h:135: warning: type of bit-field mode is a GCC
extension
../../gcc-3.3/gcc/read-rtl.c: In function fatal_with_file_and_line:
../../gcc-3.3/gcc/read-rtl.c:53: warning: traditional C rejects ISO C style
function definitions
../../gcc-3.3/gcc/read-rtl.c: In function read_rtx:
../../gcc-3.3/gcc/read-rtl.c:653: error: invalid lvalue in increment
make[2]: *** [read-rtl.o] Error 1
make[2]: Leaving directory `/home/ldmiller/ldmiller/src/gccbuild/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/home/ldmiller/ldmiller/src/gccbuild/gcc'
make: *** [bootstrap] Error 2
[EMAIL PROTECTED]:~/ldmiller/src/gccbuild$
File rtl.c reads:
case 'E':
{
/* Obstack to store scratch vector in. */
struct obstack vector_stack;
int list_counter = 0;
rtvec return_vec = NULL_RTVEC;
c = read_skip_spaces (infile);
if (c != '[')
fatal_expected_char (infile, '[', c);
/* add expressions to a list, while keeping a count */
obstack_init (vector_stack);
while ((c = read_skip_spaces (infile)) c != ']')
{
ungetc (c, infile);
list_counter++;
obstack_ptr_grow (vector_stack, (PTR) read_rtx (infile));
COMPILE CRASHES HERE
}
if (list_counter 0)
{
return_vec = rtvec_alloc (list_counter);
memcpy (return_vec-elem[0], obstack_finish (vector_stack),
list_counter * sizeof (rtx));
}
XVEC (return_rtx, i) = return_vec;
obstack_free (vector_stack, NULL);
/* close bracket gotten */
}
break;
--
Summary: Compiling GCC 3.3 per Definitive Guide to GCC book;
directory layout per book
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ldmiller at rcn dot com
GCC build triplet: powerpc_unknown
GCC host triplet: powerpc_unknown
GCC target triplet: powerpc_unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25732
[Bug c/25733] New: missed diagnostic about assignment used as truth value.
int foo(int a, int b)
{
return ((a = b) ? 1 : 0); // = missed warning.
}
int bar(int a, int b)
{
if (a = b) // warning present.
return 1;
else
return 0;
}
--
Summary: missed diagnostic about assignment used as truth value.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug middle-end/25724] Emits call to __cmpdi2 for long long comparison
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-10 09:27 --- Yes, this sounds like the way to go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25724
[Bug fortran/25730] [4.1/4.2 Regression] ICE in gfc_conv_component_ref
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-01-10 09:59 --- (In reply to comment #5) This is a regression as it worked on 4.2.0 20051219 though it did not work with 4.2.0 20051231. Mea culpa - my patch fails to copy the character length backend declarations of components when it has found a matching derived type declaration. A patch is just now regtesting. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25730
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-10 10:17 --- Confirmed. Same in the C++ frontend. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pld-linux | GCC host triplet|i686-pld-linux | GCC target triplet|i686-pld-linux | Keywords||diagnostic Known to fail|3.4.5 4.1.0 |2.95.3 3.3.6 3.4.5 4.0.2 ||4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-01-10 10:17:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25732] Compiling GCC 3.3 per Definitive Guide to GCC book; directory layout per book
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-10 10:19 --- You need an older gcc to build this version of gcc. Or you need to build at least gcc 3.3.6. gcc 3.3.6 contain invalid C code that is now rejected. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25732
[Bug libstdc++/25306] fill_n, generate_n assume Size is modifiable
--- Comment #2 from chris at bubblescope dot net 2006-01-10 10:37 --- I'm unclear on why it should be convertable to one of the built-in integral types at all.. surely saying that iterator_traits_OutputIterator::difference_type (where _OutputIterator is the first parameter to the function) would make more sense? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug c++/25723] Segmentation Fault
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-01-10 11:24 --- Confirmed at -O0, but I cannot reproduce it with a cross-compiler. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.2 3.4.3 3.4.5 Known to work||3.2.2 4.0.2 Last reconfirmed|-00-00 00:00:00 |2006-01-10 11:24:47 date|| Summary|g++-3.4.5: Internal error: |Segmentation Fault |Segmentation Fault (program | |cc1plus)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25723
[Bug c/25734] New: ice for legal kernel code with -Os
just tried to compile a recent Linux kernel [ 2.6.15] with a recent GNU C compiler version 4.2 snapshot 20060107. It said fs/sysfs/inode.c:227: error: missing definition for SSA_NAME: entry_36 in statement: # sysfs_dir_cachep_65 = V_MAY_DEF sysfs_dir_cachep_64; sd_31-s_sibling.next = entry_36; fs/sysfs/inode.c:227: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [fs/sysfs/inode.o] Error 1 It seems the crash only appears when -Os flag is used. Preprocessed source code available on request. -- Summary: ice for legal kernel code with -Os Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_x64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug rtl-optimization/25367] -O1 -funroll-loops leads to segfault
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-01-10 11:58 --- Testing a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25367
[Bug rtl-optimization/25367] -O1 -funroll-loops leads to segfault
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-01-10 11:58 --- Testing a fix. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-13 11:36:07 |2006-01-10 11:58:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25367
[Bug bootstrap/24562] makebootstrap failed: make[3]: *** No rule to make target `../zlib/libz.a'
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-01-10 11:59 --- Not a GCC issue. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24562
[Bug c++/25735] New: Assignment operator broken with multidimensional array strings.
I am not sure if this is correct C++ code anyway, (so please correct me if not)
#include stdio.h
#include string
using namespace std;
struct TestStruct
{
string testStr[2][2];
/*
TestStruct operator= (const TestStruct src)
{
testStr[0][0] = src.testStr[0][0];
testStr[0][1] = src.testStr[0][1];
testStr[1][0] = src.testStr[1][0];
testStr[1][1] = src.testStr[1][1];
return *this;
}
*/
};
int main()
{
TestStruct a, b;
a.testStr[0][0] = 1234567890;
b = a;
printf(Done \n %s, b.testStr[0][0].c_str());
return 0;
}
With no assignment operator, the default generated one causes a double free or
corruption error. Single arrays work fine, but I am also unsure what the
correct C++ behaviour should be in this case.
--
Summary: Assignment operator broken with multidimensional array
strings.
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dtrebilco at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25735
[Bug c/25645] gcc search for header files in /usr/local/include before command-line specified directories
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-01-10 12:28 --- That's the documented behaviour of -I. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25645
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-01-10 12:32 --- According to the mail http://gcc.gnu.org/ml/fortran/2006-01/msg00123.html, it fails on x86-64 and SPARC64 too. I don't see the error on Linux/x86. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug c++/10349] testsuite failure in g++.dg/parse/stack1.C
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-01-10 12:35 --- Not really a GCC problem. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10349
[Bug tree-optimization/25734] ice for legal kernel code with -Os
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-10 12:38 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug c++/25735] Assignment operator broken with multidimensional array strings.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-10 12:45 --- I cannot reproduce this in 3.4.0, 3.4.5 or 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25735
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-01-10 12:48 --- I see it on SPARC64 and x86-64. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|hppa64-hp-hpux11.11 |64-bit platform GCC host triplet|hppa64-hp-hpux11.11 |64-bit platform GCC target triplet|hppa64-hp-hpux11.11 |64-bit platform Last reconfirmed|-00-00 00:00:00 |2006-01-10 12:48:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug rtl-optimization/25489] Suboptimal code generated for comparisons
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-01-10 13:03 --- Not very pretty indeed. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-10 13:03:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25489
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2006-01-10 13:04 --- Also, very telling, it fails for s390x-ibm-linux-gnu (64 bits) and *not* for s390-ibm-linux-gnu (32 bits). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug tree-optimization/25736] New: ACATS tests c45342a, c52102b and c52102d fail with struct aliasing enabled
,.,. C45342A ACATS 2.5 06-01-10 12:41:40 C45342A CHECK THAT CATENATION OF NON-NULL OPERANDS YIELDS CORRECT RESULT WITH CORRECT BOUNDS. raised CONSTRAINT_ERROR : c45342a.adb:83 length check failed ,.,. C52102B ACATS 2.5 06-01-10 12:43:29 C52102B CHECK THAT THE ASSIGNMENT OF OVERLAPPING SOURCE AND TARGET VARIABLES (INCLUDING ARRAYS AND SLICES IN VARIOUS COMBINATIONS) SATISFIES THE SEMANTICS OF COPY ASSIGNMENT (PART 2: DYNAMIC BOUNDS). raised CONSTRAINT_ERROR : c52102b.adb:114 length check failed ,.,. C52102D ACATS 2.5 06-01-10 12:43:34 C52102D CHECK THAT THE ASSIGNMENT OF OVERLAPPING SOURCE AND TARGET VARIABLES (INCLUDING ARRAYS AND SLICES IN VARIOUS COMBINATIONS) SATISFIES THE SEMANTICS OF COPY ASSIGNMENT WHEN INITIAL ASSIGNMENT VALUES ARE DYNAMIC (PART 2: DYNAMIC BOUNDS). raised CONSTRAINT_ERROR : c52102d.adb:122 length check failed -- Summary: ACATS tests c45342a, c52102b and c52102d fail with struct aliasing enabled Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25736
[Bug c++/25735] Assignment operator broken with multidimensional array strings.
--- Comment #2 from pcarlini at suse dot de 2006-01-10 13:07 --- (In reply to comment #1) I cannot reproduce this in 3.4.0, 3.4.5 or 4.1.0. Same here, mainline too. Valgrind is also fine, on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25735
[Bug tree-optimization/25737] New: ACATS tests c974001 and c974013 do not terminate with struct aliasing enabled
,.,. C974001 ACATS 2.5 06-01-10 12:54:17 C974001 Asynchronous Select: Trigger is delay_relative which completes before abortable part. (killed) ,.,. C974013 ACATS 2.5 06-01-10 13:57:39 C974013 Asynchronous Select: Trigger is delay_until which completes before abortable part. (killed) -- Summary: ACATS tests c974001 and c974013 do not terminate with struct aliasing enabled Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-10 13:08 --- I can reproduce it with a native compiler for powerpc-darwin but with -m64 which enables LP64 powerpc-Darwin. It is a segfault writting out the module. Backtrace: #0 0x00052ce0 in mio_symtree_ref (stp=0x42909e3c) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:2115 #1 0x00053898 in mio_expr (ep=0x42909ef0) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:2546 #2 0x00052424 in mio_array_ref (ar=0x42909ea4) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:1809 #3 0x0005310c in mio_ref (rp=0xb4a0) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:2257 #4 0x000531e0 in mio_ref_list (rp=0x42909df0) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:2286 #5 0x000539e4 in mio_expr (ep=0x42909bb0) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:2582 #6 0x00052054 in mio_charlen (clp=0x4290873c) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:1668 #7 0x00052200 in mio_typespec (ts=0x42908730) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:1726 #8 0x00053fc4 in mio_symbol (sym=0x42908720) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:2802 #9 0x00055270 in write_symbol (n=13, sym=0x42908720) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:3468 #10 0x000553dc in write_symbol0 (st=0x429087a0) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:3507 #11 0x000552c8 in write_symbol0 (st=0x42908840) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:3486 #12 0x000552d4 in write_symbol0 (st=0x429085f0) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:3487 #13 0x000552c8 in write_symbol0 (st=0x429016c0) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:3486 #14 0x000552c8 in write_symbol0 (st=0x42907780) at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:3486 #15 0x000558e4 in write_module () at /Users/pinskia/src/gcc/alias/gcc/gcc/fortran/module.c:3653 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC build triplet|64-bit platform | GCC host triplet|64-bit platform | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug tree-optimization/25738] New: ACATS test cc50a01 fails with struct aliasing enabled
,.,. CC50A01 ACATS 2.5 06-01-10 14:03:59 CC50A01 Check that a formal parameter of a library-level generic unit may be a formal tagged private type. - CC50A01 Testing definite tagged type... * CC50A01Wrong result after Pop of empty stack. - CC50A01 Testing indefinite tagged type... CC50A01 FAILED . -- Summary: ACATS test cc50a01 fails with struct aliasing enabled Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25738
[Bug rtl-optimization/24376] wrong-code unless -fno-sched-interblock
--- Comment #5 from nickc at redhat dot com 2006-01-10 13:15 --- Created an attachment (id=10605) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10605action=view) When computing region not to schedule, include earlier cc0 setters -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24376
[Bug ada/23519] Dividing fixed point number by zero returns zero.
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-10 13:16 --- No feedback in 3 months. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23519
[Bug rtl-optimization/24376] wrong-code unless -fno-sched-interblock
--- Comment #6 from nickc at redhat dot com 2006-01-10 13:19 --- Hi Libor, I have uploaded a patch which should fix the problem. It is not the most elegant solution but I believe that it should work for now. The patch amends the code in add_branch_dependencies() which searches back from the end of a block to the first instruction which is not a branch. call, cc0 setter, clobber or use. The amendment is that once such an instruction is found, the search is continued backwards until all cc0 setters have been found. In this way none of the cc0 setter/user pairs in the block are disturbed. Please let me know how you get on with this patch and if it solves the problem for you. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24376
[Bug c++/25735] Assignment operator broken with multidimensional array strings.
--- Comment #3 from dtrebilco at gmail dot com 2006-01-10 13:33 --- (In reply to comment #2) (In reply to comment #1) I cannot reproduce this in 3.4.0, 3.4.5 or 4.1.0. Same here, mainline too. Valgrind is also fine, on x86. If it helps I am using compile options: -O0 -g3 -Wall -c -fmessage-length=0 with Compiler 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) - Fedora Core 3 (x86) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25735
[Bug tree-optimization/25739] New: Memory leak in bt_load.c(augment_live_range)
As reported on gcc ml by Christophe Jaillet [EMAIL PROTECTED]:
gcc leaks memory augment_live_range
static void
augment_live_range (bitmap live_range, HARD_REG_SET *btrs_live_in_range,
basic_block head_bb, basic_block new_bb, int full_range)
{
basic_block *worklist, *tos;
tos = worklist = xmalloc (sizeof (basic_block) * (n_basic_blocks + 1));
if (dominated_by_p (CDI_DOMINATORS, new_bb, head_bb))
{
if (new_bb == head_bb)
{
if (full_range)
IOR_HARD_REG_SET (*btrs_live_in_range, btrs_live[new_bb-index]);
return; Here we leak
--
Summary: Memory leak in bt_load.c(augment_live_range)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pth at suse dot de
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25739
[Bug rtl-optimization/25739] Memory leak in bt_load.c(augment_live_range)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-10 14:06 --- I should note that bt-load.c is only invoked by default on sh-*. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25739
[Bug rtl-optimization/25739] Memory leak in bt_load.c(augment_live_range)
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-10 14:25 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-10 14:25:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25739
[Bug rtl-optimization/25739] Memory leak in bt_load.c(augment_live_range)
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-01-10 14:26 --- Created an attachment (id=10607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10607action=view) patch patch, untested but obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25739
[Bug c/25645] gcc search for header files in /usr/local/include before command-line specified directories
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-01-10 14:28 --- I was a bit terse: -I is ignored for $(prefix)/include. See the entry for --with-local-prefix in http://gcc.gnu.org/install/configure.html . If you don't want /usr/local/include to be searched, configure it away by specifying --with-local-prefix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25645
[Bug bootstrap/25740] New: Bus Error compiling gcc/config/sparc/sol2-c1.asm
Building GCC 3.4.5 on Solaris 2.10 Configure line: configure --prefix=/usr/local --enable-languages=c,c++ Directory: gcc-3.4.5/build/gcc Triggering line: /opt/apps/src/gcc-3.4.5/build/gcc/xgcc -B/opt/apps/src/gcc-3.4.5/build/gcc/ -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include -c -o crt1.o -x assembler-with-cpp ../../gcc/config/sparc/sol2-c1.asm Compiler Output: cc1: internal compiler error: Bus Error Please submit a full bug report, with preprocessed source if appropriate. Preprocessed source: None available from -save-temps -- Summary: Bus Error compiling gcc/config/sparc/sol2-c1.asm Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: darren at mambo dot net GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25740
[Bug testsuite/25741] New: Gcc testsuite isn't parallel build safe
Same filename is used in different tests. When make -j4 check was used, I got FAIL: g++.dg/debug/trivial.C -gstabs+1 execution test FAIL: gcc.dg/debug/trivial.c -gdwarf-2 execution test FAIL: gcc.dg/debug/trivial.c -gdwarf-2 -O3 execution test FAIL: g++.dg/debug/trivial.C -gstabs+1 -O3 execution test FAIL: gcc.dg/debug/trivial.c -gdwarf-23 execution test FAIL: g++.dg/debug/trivial.C -gstabs+ execution test FAIL: gcc.dg/debug/trivial.c -gdwarf-23 -O3 execution test FAIL: g++.dg/debug/trivial.C -gstabs+ -O2 execution test FAIL: gcc.dg/debug/trivial.c -gstabs1 execution test FAIL: gcc.dg/debug/trivial.c -gstabs1 -O (test for excess errors) FAIL: g++.dg/debug/trivial.C -gstabs+ -O3 execution test FAIL: gcc.dg/debug/trivial.c -gstabs1 -O3 execution test FAIL: g++.dg/debug/trivial.C -gstabs+3 execution test FAIL: gcc.dg/debug/trivial.c -gstabs -O execution test FAIL: g++.dg/debug/trivial.C -gstabs+3 -O2 execution test FAIL: gcc.dg/debug/trivial.c -gstabs -O3 execution test FAIL: gcc.dg/debug/trivial.c -gstabs3 (test for excess errors) Executing on host: /export/build/gnu/gcc-4.1/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-4.1/build-x86_64-linux/gcc/ /net/gnu-13/export/gnu/src/gcc-4.1/gcc/gcc/testsuite/gcc.dg/debug/trivial.c -gstabs1 -O -fno-show-column -lm -o ./trivial.exe(timeout = 300) /usr/local/bin/ld: reopening ./trivial.exe: Text file busy^M ^M /usr/local/bin/ld: final link failed: Text file busy^M collect2: ld returned 1 exit status^M compiler exited with status 1 -- Summary: Gcc testsuite isn't parallel build safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug bootstrap/25740] Bus Error compiling gcc/config/sparc/sol2-c1.asm
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-01-10 16:05 --- Please try again, GCC 3.4.5 is known to bootstrap fine on SPARC/Solaris 10. If it's reproducible, post a backtrace at the crashpoint. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25740
[Bug bootstrap/25740] Bus Error compiling gcc/config/sparc/sol2-c1.asm
--- Comment #2 from darren at mambo dot net 2006-01-10 16:12 --- Backtrace will take a few days - I'm on a deadline to get this system installed, so right now I'm compiling 3.4.4 and hoping it doesn't have the same bug. Once the system's ready, I'll re-try compiling 3.4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25740
[Bug libstdc++/25306] fill_n, generate_n assume Size is modifiable
--- Comment #3 from sebor at roguewave dot com 2006-01-10 16:14 --- (In reply to comment #2) I'm not sure what you mean. Could you show what one of the algorithms would look like with a Size that's not convertible to an integer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug target/25722] Stackpointer is not restored correct at end of function
--- Comment #2 from berndtrog at yahoo dot com 2006-01-10 16:56 --- Only 3.4.x seems allocate a frame pointer in the function 'Evaluate'. It would be interesting if this bug can be triggered in 4.x! -- berndtrog at yahoo dot com changed: What|Removed |Added CC||berndtrog at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25722
[Bug bootstrap/25740] Bus Error compiling gcc/config/sparc/sol2-c1.asm
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-01-10 16:58 --- Backtrace will take a few days - I'm on a deadline to get this system installed, so right now I'm compiling 3.4.4 and hoping it doesn't have the same bug. Well, unless proven otherwise, GCC 3.4.5 has no bug either. hikaru% uname -a SunOS hikaru 5.10 Generic sun4u sparc SUNW,Sun-Fire-V240 hikaru% gcc/xgcc -v Using built-in specs. Configured with: /home/eric/gcc-3.4.5/configure --prefix=/usr/local --enable-languages=c Thread model: posix gcc version 3.4.5 Once the system's ready, I'll re-try compiling 3.4.5 Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25740
[Bug libstdc++/25306] fill_n, generate_n assume Size is modifiable
--- Comment #4 from chris at bubblescope dot net 2006-01-10 17:00 ---
For the record, I was thinking of:
templatetypename _OutputIterator, typename _Size, typename _Tp
_OutputIterator
fill_n(_OutputIterator __first, _Size __n, const _Tp __value)
{
iterator_traits_OutputIterator::difference_type __count(__n)
for (; __count 0; --__count, ++__first)
*__first = __value;
return __first;
}
But now I've decided thats no good, as difference_type isn't designed for
OutputIterators. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug libstdc++/25306] fill_n, generate_n assume Size is modifiable
--- Comment #5 from gdr at cs dot tamu dot edu 2006-01-10 17:13 --- Subject: Re: fill_n, generate_n assume Size is modifiable chris at bubblescope dot net [EMAIL PROTECTED] writes: | But now I've decided thats no good, as difference_type isn't designed for | OutputIterators. Indeed; and that is arguably a bug in the standard specification. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug libstdc++/23591] exceptions in plugins in threads cause segmentation violation by leaving bad exit handler for the pthread
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-01-10 17:14 --- Subject: Bug 23591 Author: bkoz Date: Tue Jan 10 17:14:00 2006 New Revision: 109545 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109545 Log: 2006-01-10 Benjamin Kosnik [EMAIL PROTECTED] Ulrich Drepper [EMAIL PROTECTED] PR libstdc++/23591 * scripts/create_testsuite_files: Support for C test files. * testsuite/lib/libstdc++.exp: Same. * testsuite/libstdc++-dg/normal.exp: Same. * testsuite/ext/mt_allocator/22309_thread.cc: Update names. * testsuite/19_diagnostics/23591_thread-1.c: New. * testsuite/testsuite_shared.cc: Add tests, rename existing functions. * libsupc++/eh_globals.cc: Make global thread local if possible. * configure.ac: Use GCC_CHECK_TLS. * acinclude.m4: Include tls.m4. * configure: Regenerate. * config.h.in: Same. Added: branches/gcc-4_1-branch/libstdc++-v3/testsuite/19_diagnostics/23591_thread-1.c Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/Makefile.in branches/gcc-4_1-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_1-branch/libstdc++-v3/aclocal.m4 branches/gcc-4_1-branch/libstdc++-v3/config.h.in branches/gcc-4_1-branch/libstdc++-v3/configure branches/gcc-4_1-branch/libstdc++-v3/configure.ac branches/gcc-4_1-branch/libstdc++-v3/include/Makefile.in branches/gcc-4_1-branch/libstdc++-v3/libmath/Makefile.in branches/gcc-4_1-branch/libstdc++-v3/libsupc++/Makefile.in branches/gcc-4_1-branch/libstdc++-v3/libsupc++/eh_globals.cc branches/gcc-4_1-branch/libstdc++-v3/po/Makefile.in branches/gcc-4_1-branch/libstdc++-v3/scripts/create_testsuite_files branches/gcc-4_1-branch/libstdc++-v3/src/Makefile.in branches/gcc-4_1-branch/libstdc++-v3/testsuite/Makefile.in branches/gcc-4_1-branch/libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc branches/gcc-4_1-branch/libstdc++-v3/testsuite/lib/libstdc++.exp branches/gcc-4_1-branch/libstdc++-v3/testsuite/libstdc++-dg/normal.exp branches/gcc-4_1-branch/libstdc++-v3/testsuite/testsuite_shared.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23591
[Bug tree-optimization/25734] ice for legal kernel code with -Os
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug target/20016] Compiling libgcc2.c with -Os for avr-gcc?
--- Comment #4 from berndtrog at yahoo dot com 2006-01-10 17:19 --- Roger Sayle commited the patch on 2005-12-17. Thanks! -- berndtrog at yahoo dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20016
[Bug libstdc++/24345] libstdc++ build failure with IRIX ld(1)
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-01-10 17:22 --- I'd like to either close this or change it to bootstrap, in the attempt to flag the attention of the top-level build people for this bug. I don't consider this a libstdc++ problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24345
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
--- Comment #1 from steven at gcc dot gnu dot org 2006-01-10 17:25 --- One of trivial.[cC] has to be renamed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-10 17:25:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug libstdc++/23591] exceptions in plugins in threads cause segmentation violation by leaving bad exit handler for the pthread
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-01-10 17:25 --- Fixed in 4.1.x and mainline. There is another found while looking at this bug, in that multi-threaded apps with multiple, pending exceptions will leak active and in-flight exceptions at termination. I'll open a separate bug report for that. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23591
[Bug libstdc++/23591] exceptions in plugins in threads cause segmentation violation by leaving bad exit handler for the pthread
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-01-10 17:26 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23591
[Bug libstdc++/24345] libstdc++ build failure with IRIX ld(1)
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2006-01-10 17:32 --- (In reply to comment #5) I'd like to either close this or change it to bootstrap, in the attempt to flag the attention of the top-level build people for this bug. I don't consider this a libstdc++ problem. Ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24345
[Bug target/21715] [4.0/4.1 regression] code-generation performance regression
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-10 17:50 ---
The new reassociation pass, or the removal of DOM's reassociation bits, fixed
this on the trunk. We get poorer initial RTL generation out of GCC 4.1 and we
never manage to fix it up:
The .final_cleanup from GCC 4.1 and GCC 4.0:
;; Function foo (foo)
foo (v)
{
bb 0:
return v -v;
}
And the .final_cleanup from GCC 4.2:
;; Function foo (foo)
foo (v)
{
bb 2:
return -v v;
}
(insn 12 11 13 (parallel [
(set (reg:DI 60)
-(and:DI (reg/v:DI 59 [ v ])
-(reg:DI 61)))
+(and:DI (reg:DI 61)
+(reg/v:DI 59 [ v ])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
So this regression is not caused by the register allocator, but it does play a
role:
In the .combine and .ce2 RTL dumps, the difference is still there:
(insn 12 11 16 (parallel [
(insn 12 11 16 (parallel [
(set (reg:DI 60)
-(and:DI (reg/v:DI 59 [ v ])
-(reg:DI 61)))
+(and:DI (reg:DI 61)
+(reg/v:DI 59 [ v ])))
(clobber (reg:CC 17 flags))
-(expr_list:REG_DEAD (reg/v:DI 59 [ v ])
-(expr_list:REG_DEAD (reg:DI 61)
+(expr_list:REG_DEAD (reg:DI 61)
+(expr_list:REG_DEAD (reg/v:DI 59 [ v ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
Then in the .regmove RTL dump something changes:
(insn:HI 12 11 16 (parallel [
-(set (reg/v:DI 59 [ v ])
-(and:DI (reg/v:DI 59 [ v ])
-(reg:DI 61)))
+(set (reg:DI 61)
+(and:DI (reg:DI 61)
+(reg/v:DI 59 [ v ])))
(clobber (reg:CC 17 flags))
]) 297 {*anddi_1_rex64} (insn_list:REG_DEP_TRUE 11 (nil))
-(expr_list:REG_DEAD (reg:DI 61)
+(expr_list:REG_DEAD (reg/v:DI 59 [ v ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
This small difference eventually leads to a different choice of register
allocation. The choice that GCC 4.2 makes is superior because it makes the
move to the result a dead instruction. The .greg RTL dump shows this:
-(insn:HI 12 11 16 0 (parallel [
-(set (reg/v:DI 5 di [orig:59 v ] [59])
-(and:DI (reg/v:DI 5 di [orig:59 v ] [59])
-(reg:DI 0 ax [61])))
+(insn:HI 12 11 16 2 (parallel [
+(set (reg:DI 0 ax [61])
+(and:DI (reg:DI 0 ax [61])
+(reg/v:DI 5 di [orig:59 v ] [59])))
(clobber (reg:CC 17 flags))
]) 297 {*anddi_1_rex64} (insn_list:REG_DEP_TRUE 11 (nil))
(nil))
-(insn:HI 19 16 25 0 (set (reg/i:DI 0 ax [ result ])
-(reg/v:DI 5 di [orig:59 v ] [59])) 81 {*movdi_1_rex64}
-(insn_list:REG_DEP_TRUE 12 (nil))
-(nil))
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|18427 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug bootstrap/25740] Bus Error compiling gcc/config/sparc/sol2-c1.asm
--- Comment #4 from darren at mambo dot net 2006-01-10 17:52 --- Well, 3.4.4 craps out on the same file, unable to malloc after exhausting the 8Gb swap space. Note that the difference between your system and this one is I have --enable-languages=c,c++. I do have a running gcc 3.4.4 on the same system where I only had --enable-languages=c -bash-3.00$ /usr/local/bin/gcc -v ## Running version Reading specs from /usr/local/lib/gcc/sparcv9-sun-solaris2.10/3.4.4/specs Configured with: ./configure --prefix=/usr/local --enable-languages=c sparcv9-sun-solaris2.10 Thread model: posix gcc version 3.4.4 -bash-3.00$ uname -a SunOS challenger 5.10 Generic_118822-20 sun4u sparc SUNW,Ultra-250 Line that dies: /opt/apps/src/gcc-3.4.4/build/gcc/xgcc -B/opt/apps/src/gcc-3.4.4/build/gcc/ -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include -c -o crt1.o -x assembler-with-cpp ../../gcc/config/sparc/sol2-c1.asm cc1: out of memory allocating 134217728 bytes after a total of 9127182336 bytes gmake[1]: *** [crt1.o] Error 1 gmake[1]: Leaving directory `/opt/apps/src/gcc-3.4.4/build/gcc' gmake: *** [all-gcc] Error 2 I will try re-configuring this 3.4.4 with sparcv9-sun-solaris2.10 instead of sparc-sun-solaris and see if that makes a difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25740
[Bug bootstrap/25740] Bus Error compiling gcc/config/sparc/sol2-c1.asm
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-01-10 18:09 --- Note that the difference between your system and this one is I have --enable-languages=c,c++. That doesn't matter here. I will try re-configuring this 3.4.4 with sparcv9-sun-solaris2.10 instead of sparc-sun-solaris and see if that makes a difference. Of course, that makes a big difference! sparc-sun-solaris2.9 is a 32-bit compiler while sparcv9-sun-solaris2.10 is a 64-bit compiler, you cannot compile one with the other, you need to specify either CC=gcc -m32 or CC=gcc -m64 at configure time. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25740
[Bug target/25718] invalid assembly for unsigned-minimum expressions.
--- Comment #2 from hp at gcc dot gnu dot org 2006-01-10 18:12 --- Subject: Bug 25718 Author: hp Date: Tue Jan 10 18:12:21 2006 New Revision: 109547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109547 Log: PR target/25718 * config/cris/cris.md (uminsi3): Don't use 8- or 16-bit sizes for a negative bound. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25718
[Bug target/25718] invalid assembly for unsigned-minimum expressions.
--- Comment #3 from hp at gcc dot gnu dot org 2006-01-10 18:13 --- Subject: Bug 25718 Author: hp Date: Tue Jan 10 18:13:16 2006 New Revision: 109548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109548 Log: PR target/25718 * config/cris/cris.md (uminsi3): Don't use 8- or 16-bit sizes for a negative bound. Modified: trunk/gcc/config/cris/cris.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25718
[Bug target/25718] invalid assembly for unsigned-minimum expressions.
--- Comment #4 from hp at gcc dot gnu dot org 2006-01-10 18:14 --- Subject: Bug 25718 Author: hp Date: Tue Jan 10 18:14:42 2006 New Revision: 109549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109549 Log: PR target/25718 * gcc.dg/torture/pr25718-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr25718-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25718
[Bug rtl-optimization/25367] -O1 -funroll-loops leads to segfault
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-01-10 18:50 --- Subject: Bug 25367 Author: ebotcazou Date: Tue Jan 10 18:50:07 2006 New Revision: 109551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109551 Log: PR rtl-optimization/25367 * config/sparc/sparc.h (HARD_REGNO_RENAME_OK): New macro. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25367
[Bug rtl-optimization/25367] -O1 -funroll-loops leads to segfault
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-01-10 18:51 --- Subject: Bug 25367 Author: ebotcazou Date: Tue Jan 10 18:51:33 2006 New Revision: 109552 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109552 Log: PR rtl-optimization/25367 * config/sparc/sparc.h (HARD_REGNO_RENAME_OK): New macro. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/sparc/sparc.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25367
[Bug rtl-optimization/25367] -O1 -funroll-loops leads to segfault
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-01-10 18:53 --- Subject: Bug 25367 Author: ebotcazou Date: Tue Jan 10 18:53:24 2006 New Revision: 109553 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109553 Log: PR rtl-optimization/25367 * config/sparc/sparc.h (HARD_REGNO_RENAME_OK): New macro. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/sparc/sparc.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25367
[Bug rtl-optimization/25367] -O1 -funroll-loops leads to segfault
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-01-10 18:55 --- See http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00545.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25367
[Bug target/25718] invalid assembly for unsigned-minimum expressions.
--- Comment #5 from hp at gcc dot gnu dot org 2006-01-10 19:01 --- Fixed in main trunk; 4.1 and 4.0 pending. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25718
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
--- Comment #2 from hjl at lucon dot org 2006-01-10 19:06 --- Some tests use PID in output filenames. I am testing a patch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
--- Comment #3 from hjl at lucon dot org 2006-01-10 19:22 --- Using PID in output filenames requires many changes. Renaming is simpler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
--- Comment #4 from hjl at lucon dot org 2006-01-10 20:20 --- Created an attachment (id=10608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10608action=view) List of tests with the same prefix This is a list of ests with the same prefix. There are quite a few. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug target/25042] [3.4/4.0/4.1/4.2 Regression] __float128 ICE on x86
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-10 20:26 --- Honza, are you going to do something useful with your patch from comment #3? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-01-10 20:26:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25042
[Bug tree-optimization/21470] -fargument-noalias-global has no effect for the vectorizer
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-10 20:31 --- I have a fix which comes from Richard Guenther and modified for -fargument-noalias-global instead of restrict as it was using the wrong test. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21470
[Bug tree-optimization/17064] -falias-noargument-global doesn't eliminate dead stores/loads
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-10 20:35 --- I have a semi fix for this one but the variable is still being marked as a call clobber but that is because of a FIXME in the source. I am going to take it anyways but not close it once I get my patch approved. It does fix comment #3 though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
--- Comment #3 from steven at gcc dot gnu dot org 2006-01-10 20:36 --- GCC 4.2 (trunk) produces this kind of redundant loads: ... movl-20(%ebp), %eax testl %eax, %eax je .L10 movl-20(%ebp), %eax movl%eax, (%esp) callstrlen ... And so does GCC 3.3-hammer_branch: ... movl-16(%ebp), %ecx xorl%ebx, %ebx testl %ecx, %ecx je .L8 movl-16(%ebp), %eax movl%eax, (%esp) callstrlen ... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-10 20:36:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
[Bug tree-optimization/17064] -falias-noargument-global doesn't eliminate dead stores/loads
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-10 20:36 --- I should note that the patch is not fully done as I still need to be able to add it to the list of variables to remove before running the may_alias again (like the HEAP variables). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-10 20:57 ---
On the trunk, we have the following situation in the .csa RTL dump (on AMD64
-m32 -march=i686):
;; Start of basic block 5, registers live:
4 [si] 5 [di] 6 [bp] 7 [sp] 20 [frame]
(code_label:HI 38 37 39 5 2 [1 uses])
(note:HI 39 38 41 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn:HI 41 39 42 5 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -20 [0xffec])) [7 val+0 S4 A8])
(const_int 0 [0x0]))) 3 {*cmpsi_ccno_1} (nil)
(nil))
(jump_insn:HI 42 41 44 5 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 63)
(pc))) 511 {*jcc_1} (insn_list:REG_DEP_TRUE 41 (nil))
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_BR_PROB (const_int 8100 [0x1fa4])
(nil
;; End of basic block 5, registers live:
4 [si] 5 [di] 6 [bp] 7 [sp] 20 [frame]
(...)
;; Start of basic block 7, registers live: 4 [si] 5 [di] 6 [bp] 7 [sp] 20
[frame]
(code_label:HI 63 119 64 7 5 [1 uses])
(note:HI 64 63 125 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn 125 64 66 7 (set (reg:SI 0 ax)
(mem/f/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -20 [0xffec])) [7 val+0 S4 A8])) 40
{*movsi_1} (nil)
(nil))
(insn:HI 66 125 67 7 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg:SI 0 ax)) 40 {*movsi_1} (nil)
(expr_list:REG_DEAD (reg:SI 0 ax)
(nil)))
(call_insn/u:HI 67 66 68 7 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI (strlen) [flags 0x41]
function_decl 0x2ae6fb00 strlen) [0 S1 A8])
(const_int 4 [0x4]))) 731 {*call_value_0} (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(expr_list:REG_DEP_TRUE (use (mem:BLK (scratch) [0 A8]))
(nil)))
(...)
Then we peephole2 the MEM for the compare to a set, see the .peephole2 dump:
;; Start of basic block 5, registers live:
4 [si] 5 [di] 6 [bp] 7 [sp] 20 [frame]
(code_label:HI 38 37 39 5 2 [1 uses])
(note:HI 39 38 142 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 142 39 143 5 (set (reg:SI 0 ax)
(mem/f/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -20 [0xffec])) [7 val+0 S4 A8])) -1
(nil)
(nil))
(insn 143 142 42 5 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax)
(const_int 0 [0x0]))) -1 (nil)
(expr_list:REG_DEAD (reg:SI 0 ax)
(nil)))
(jump_insn:HI 42 143 44 5 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 63)
(pc))) 511 {*jcc_1} (insn_list:REG_DEP_TRUE 41 (nil))
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_BR_PROB (const_int 8100 [0x1fa4])
(nil
;; End of basic block 5, registers live:
4 [si] 5 [di] 6 [bp] 7 [sp] 20 [frame]
(...)
;; Start of basic block 7, registers live: 4 [si] 5 [di] 6 [bp] 7 [sp] 20
[frame]
(code_label:HI 63 119 64 7 5 [1 uses])
(note:HI 64 63 125 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn 125 64 66 7 (set (reg:SI 0 ax)
(mem/f/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -20 [0xffec])) [7 val+0 S4 A8])) 40
{*movsi_1} (nil)
(nil))
(insn:HI 66 125 67 7 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg:SI 0 ax)) 40 {*movsi_1} (nil)
(expr_list:REG_DEAD (reg:SI 0 ax)
(nil)))
(call_insn/u:HI 67 66 68 7 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI (strlen) [flags 0x41]
function_decl 0x2ae6fb00 strlen) [0 S1 A8])
(const_int 4 [0x4]))) 731 {*call_value_0} (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(expr_list:REG_DEP_TRUE (use (mem:BLK (scratch) [0 A8]))
(nil)))
Essentially the same thing happens in GCC 3.3: Up to peephole2, the first MEM
is burried in the compare, and split out by some peephole.
I don't think this is related to register allocation, really. Someone should
try to see what the flow2 dump looks like for GCC 3.2, which is apparently the
last release that did not have this problem. In any case, it will be difficult
to find out when this problem was introduced. But it doesn't look like a
really severe problem to me anyway, really...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
[Bug c/25742] New: Internal compiler error in gen_rtx_SUBREG
The attached code generates an internal error when we try to compile it with -O[123s]. -- Summary: Internal compiler error in gen_rtx_SUBREG Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zer0 at droids-corp dot org GCC build triplet: i386-linux GCC host triplet: i386-linux GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25742
[Bug c/25742] Internal compiler error in gen_rtx_SUBREG
--- Comment #1 from zer0 at droids-corp dot org 2006-01-10 21:04 --- Created an attachment (id=10609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10609action=view) the guilty program This is the program that we cannot compile : $ avr-gcc -Wall -Os f32.c -c -mmcu=atmega128 f32.c: In function `f': f32.c:71: warning: 'a' might be used uninitialized in this function f32.c:71: warning: 'b' might be used uninitialized in this function f32.c:73: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:618 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. avr-gcc -v Reading specs from /usr/lib/gcc/avr/3.4.3/specs Configured with: ./configure -v --enable-languages=c,c++ --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --build=i386-linux --host=i386-linux --target=avr Thread model: single gcc version 3.4.3 Note that it compiles on my host : $ gcc f32.c -c -Os - ok $ gcc-3.4 f32.c -c -Os - ok -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25742
[Bug c/25742] Internal compiler error in gen_rtx_SUBREG
--- Comment #2 from berndtrog at yahoo dot com 2006-01-10 21:19 --- f32.c compiles OK on 4_1-branch and HEAD. -- berndtrog at yahoo dot com changed: What|Removed |Added CC||berndtrog at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25742
[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-10 21:27 --- FWIW, the peephole that we trigger is this one, which has been around since forever (since rth's ia32 backend rewrite from the previous century...): ;; Don't compare memory with zero, load and use a test instead. (define_peephole2 [(set (match_operand 0 flags_reg_operand ) (match_operator 1 compare_operator [(match_operand:SI 2 memory_operand ) (const_int 0)])) (match_scratch:SI 3 r)] ix86_match_ccmode (insn, CCNOmode) ! optimize_size [(set (match_dup 3) (match_dup 2)) (set (match_dup 0) (match_op_dup 1 [(match_dup 3) (const_int 0)]))] ) But it feels like someone made a bad joke, or something. These are some pieces of what GCC 3.2 makes of it (with -march=i[456]86): movl-16(%ebp), %eax xorl%edi, %edi testl %eax, %eax je .L7 subl$12, %esp movl-16(%ebp), %eax pushl %eax callstrlen and movl-16(%ebp), %esi addl$16, %esp testl %esi, %esi je .L6 movb$61, (%eax) pushl %ecx pushl %edi movl-16(%ebp), %edx This is on AMD64 -m32 with GNU C version 3.2.3 (x86_64-unknown-linux-gnu), compiled by gcc 3.3-hammer-branch, gcc 3.4 and later can't compile gcc 3.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
[Bug bootstrap/25740] Bus Error compiling gcc/config/sparc/sol2-c1.asm
--- Comment #6 from darren at mambo dot net 2006-01-10 21:32 --- Well, I tried 'configure sparcv9-sun-solaris2.10' and it crashed on the same file I tried 'CC=gcc -m64 configure sparcv9-sun-solaris2.10' and it still crashed on the same file. I'm beginning to think I imagined ever compiling gcc on this box! :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25740
[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-10 21:32 --- Since GCC 3.2 also has this problem, contrary to what the reporter claims, I am not sure if we should keep this marked as a regression. Obviously it is a missed optimization, so the bug report is valid in that sense, and we should keep it open at least. Could the reporter check whether GCC 3.2 really does not have this problem, or if perhaps this is a regresion from even older compilers? This problem may have been introduced when the new (*cough* 7 years old) ix86 backend was contributed. In that case, this may still be a regression from GCC 2.95. But I am not willing to go that far back in history ;-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
[Bug ada/25743] New: crosscompiler fails to build ada-rts for target platform.
[~/rpm/BUILD/gcc-4.1-20060106/obj-sparc64-pld-linux]$ $ make all-gcc $ make -C gcc/ada gnatlib (...) ../../xgcc -B../../ -c -g -O2 -gnatpg -nostdinc a-dirval.adb -o a-dirval.o ../../xgcc -B../../ -c -g -O2 -gnatpg -nostdinc a-einuoc.adb -o a-einuoc.o ../../xgcc -B../../ -c -g -O2 -gnatpg -nostdinc a-elchha.adb -o a-elchha.o ../../xgcc -B../../ -c -g -O2 -gnatpg -nostdinc -g -O1 -fno-inline \ a-except.adb -o a-except.o a-exexpr.adb:169:04: warning: types for unchecked conversion have different sizes make[1]: *** [a-except.o] Error 1 $ gcc/xgcc -v Using built-in specs. Target: sparc64-pld-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/lib --libexecdir=/usr/lib --disable-shared --disable-threads --enable-languages=c,c++,ada --enable-c99 --enable-long-long --disable-nls --with-cpu=ultrasparc --with-gnu-as --with-gnu-ld --with-mangler-in-ld --with-system-zlib --enable-multilib --with-headers=/home/users/pluto/rpm/BUILD/gcc-4.1-20060106/fake-root/usr/include --without-x --target=sparc64-pld-linux --host=i686-pld-linux --build=i686-pld-linux Thread model: single gcc version 4.1.0 20060106 (prerelease) -- Summary: crosscompiler fails to build ada-rts for target platform. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: sparc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25743
