GCC 3.4.4 Froze
GCC 3.4.4 is now slushy. All non-documentation patches require my explicitly approval. 3.4.4 RC1 will be building overnight. FYI, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCSE considers read only memory clobbered by function calls.
Richard Henderson [EMAIL PROTECTED] wrote on 09/05/2005 19:35:34:
On Mon, May 09, 2005 at 05:45:24PM +0300, Mostafa Hagog wrote:
EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
! if (! MEM_READONLY_P (x))
Looks like you should push this check here:
case MEM:
if (!MEM_READONLY_P (x))
{
...
}
x = XEXP (x, 0);
goto repeat;
Yes, I agree, no need to waste compile time on those checks, we
know that there is no memory modifications for read-only memory.
r~
Re: GCSE considers read only memory clobbered by function calls.
Paolo Bonzini [EMAIL PROTECTED] wrote on 09/05/2005 18:09:10: It appears that GCSE considers read only memory as call clobbered, which is not the case in CSE. I have took the test for read-only memory from CSE and add it to GCSE where we compute the transparency. My wild guess is that this was not possible when MEM_READONLY_P was RTX_UNCHANGING_P, and now it is. What wasn't possible? the fact that GCSE considers MEM_READONLY_P call clobbered or the fact that CSE does not consider it such that? Mostafa.
Re: building gcc 4.0.0 on Solaris
Hi, I have installed binutils-2.16. Things work better in the sense that I get much farther into building the Java libraries. I still hit a problem: [...] ar rc .libs/libgcj0_convenience.a [... around 100.000 characters ...] internal error: error_message(58) [...] Is this a known issue? I've worked around this by changing all occurrences of AR=ar in sparc-sun-solaris2.8/libjava/libtool to AR=/usr/local/binutils/bin/ar. Using GNU's ar fixes the problem indeed. I have another problem later on, again in sparc-sun-solaris2.8/libjava: /tmp/GCC/gcc/xgcc -shared-libgcc [...] -o .libs/libgcj.so.6.0.0 collect2: ld terminated with signal 11 [Segmentation Fault] Any clue? Has anyone attempted to use GNU binutils 2.16 to build gcc on Solaris? In any case it looks like gcc cannot be built on Solaris using standard GNU binutils releases. -- Dimitri Papadopoulos
Re: GCSE considers read only memory clobbered by function calls.
I want to add the below example as a regression test; the difference
between the success and failure is the position of a load operation. Is
there a possibility to check this using the scan-assembler?
Mostafa Hagog wrote on 09/05/2005 17:45:24:
It appears that GCSE considers read only memory as call clobbered,
which
is not the case in CSE. I have took the test for read-only memory from
CSE
and add it to GCSE where we compute the transparency. Here is a patch
that
does so. This patch makes gcse eliminate redundant loads after stores for
the following example. The difference is seen when we compile with the
options:
-O3 --param max-gcse-passes=3 with/without -fgcse-las (on a
powerpc-linux target). If this looks a reasonable change I will
regression-test and bootstrap the patch and ask for commit.
Example:
#define CALL_FPTR(fptr) (*fptr)
#define MY_FOO_CHECK() if (my_foo_var) my_foo_func()
int my_foo_var;
struct my_foo_struct {
int my_dummy_field;
int *(*ppaddr)(int);
};
struct my_foo_struct *my_foo_record;
int my_main_foo(int n)
{
while ((my_foo_record = CALL_FPTR(my_foo_record-ppaddr)(n))) {
MY_FOO_CHECK();
}
return 0;
}
The patch:
2005-05-09 Mostafa Hagog [EMAIL PROTECTED]
* gcse.c (compute_transp): use MEM_READONLY_P in case of MEM.
Index: gcse.c
===
RCS file: /cvs/gcc/gcc/gcc/gcse.c,v
retrieving revision 1.340
diff -c -p -r1.340 gcse.c
*** gcse.c 23 Apr 2005 21:27:44 - 1.340
--- gcse.c 5 May 2005 12:54:04 -
*** compute_transp (rtx x, int indx, sbitmap
*** 2470,2479
do any list walking for them. */
EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
! if (set_p)
! SET_BIT (bmap[bb_index], indx);
! else
! RESET_BIT (bmap[bb_index], indx);
}
/* Now iterate over the blocks which have memory modifications
--- 2470,2482
do any list walking for them. */
EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
! if (! MEM_READONLY_P (x))
! {
! if (set_p)
! SET_BIT (bmap[bb_index], indx);
! else
! RESET_BIT (bmap[bb_index], indx);
! }
}
RE: Full comparison in 'cbranchsi4' leads to error in gcc 4.0
This works fine on gcc 3.4, however on gcc 4.0 it creates an error during optimization. According to my investigation, the error occurs when there is a division by a constant power of 2 which needs to be transformed into shifting. The error generated is: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:3599 The easiest thing to do is to debug gcc: set a breakpoint on fancy_abort, and and go up a few levels to emit_cmp_and_jump_insn_1(). Note the incoming rtx args (x and y) and mode. From the looks of the code in there it is looking for an instruction pattern that matches, and when no match is found, it tries a wider mode, until there are no wider modes, then it aborts. You need to find the mode and rtx arguments that are being passed in, and then understand why no matching instruction is found. For example, in your instruction pattern, (define_insn cbranchsi4 [(set (pc) (if_then_else (match_operator 0 comparison_operator [(match_operand:SI 1 register_operand r) (match_operand:SI 2 nonmemory_operand r)]) (label_ref (match_operand 3 )) (pc)))] c%C0jump %1 %2 %3 [(set_attr type branch) (set_attr length 1)] ) it isn't prepared to match a memory operand. Perhaps the optimizer pre-calculated a constant, and targeted the constant into memory rather than a register? In that case, there will be no match on the third argument because it is expecting a nonmemoryoperand.
Re: GCC 4.0.0 Performance Regressions?
On Tue, May 10, 2005 at 02:04:37AM +0200, Giovanni Bajo wrote: You should try and isolate a single BYTEmark test which shows the biggest regression. It's better if you manage to pack the whole test as a single preprocessed source file. Theoretically, this file should be compilable and linkable, and the resulting binary should run for a while doing computations. With this kind of help, we can analyze the regression and see why it's slower with 4.0.0. Giovanni Bajo It was rather time-consuming but I managed to do it. I picked the numsort benchmark which had a serious regression: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 Jason B. -- My interest is in the future; I am going to spend the rest of my life there. -- Charles Kettering
RE: Mail. Mail! Mail?
Original Message From: Zack Weinberg Sent: 09 May 2005 19:38 Bernard Leak writes: Can something be done to make the problem less obstructive? It's not obvious that the script should try to be too clever and work out which name to use. Mail looks as useful as any name it can have hard-coded. However, a comment could be added to the script *output* [... more useful suggestions ...] This is where I quietly mention that patches are welcome. zw How about an option to format the output suitable for piping straight into telnet mail.gnu.org 25? cheers, DaveK -- Can't think of a witty .sigline today
Re: building gcc 4.0.0 on Solaris
I've worked around this by changing all occurrences of AR=ar in sparc-sun-solaris2.8/libjava/libtool to AR=/usr/local/binutils/bin/ar. Using GNU's ar fixes the problem indeed. I have another problem later on, again in sparc-sun-solaris2.8/libjava: /tmp/GCC/gcc/xgcc -shared-libgcc [...] -o .libs/libgcj.so.6.0.0 collect2: ld terminated with signal 11 [Segmentation Fault] Any clue? How did you configure? The mix of GNU tools and Sun tools looks suspicious. libgcj.so.6.0.0 is a monster so that could be a memory problem too. If you're not interested in Java, I'd suggest to configure with --disable-libgcj. Has anyone attempted to use GNU binutils 2.16 to build gcc on Solaris? I have (with a 2.16 prerelease) on Solaris 2.5.1, 2.6, 7, 8 and 9. I'll try with the stock release. In any case it looks like gcc cannot be built on Solaris using standard GNU binutils releases. 2.15 is the only one problematic, unless proven otherwise. -- Eric Botcazou
Re: building gcc 4.0.0 on Solaris
Hi, How did you configure? The mix of GNU tools and Sun tools looks suspicious. I think there's no mix involved. I have configured with: ./configure \ --with-as=/usr/local/binutils/bin/as \ --with-ld=/usr/local/binutils/bin/ld \ ... so I should be using GNU's as and ld. libgcj.so.6.0.0 is a monster so that could be a memory problem too. If you're not interested in Java, I'd suggest to configure with --disable-libgcj. Yes, I do have a first version built with --enable-languages=c,c++ only, but I'd like to have a complete version. Otherwise it's not a memory problem, I have enough memory: $ top ... Memory: 1024M real, 243M free, 2457M swap in use, 225M swap free ... Has anyone attempted to use GNU binutils 2.16 to build gcc on Solaris? I have (with a 2.16 prerelease) on Solaris 2.5.1, 2.6, 7, 8 and 9. I'll try with the stock release. In any case it looks like gcc cannot be built on Solaris using standard GNU binutils releases. 2.15 is the only one problematic, unless proven otherwise. No, I've had problems with almsot all other previous GNU binutils releases, see my previous posts on this list. Maybe GNU binutils 2.13 or 2.14 did work at some point. -- Dimitri
Re: building gcc 4.0.0 on Solaris
How did you configure? The mix of GNU tools and Sun tools looks suspicious. I think there's no mix involved. I have configured with: ./configure \ --with-as=/usr/local/binutils/bin/as \ --with-ld=/usr/local/binutils/bin/ld \ ... so I should be using GNU's as and ld. --with-gnu-as and --with-gnu-ld I presume? Hacking libtool is not supported anyway. ;-) I think you should use only GNU tools by tweaking your PATH. 2.15 is the only one problematic, unless proven otherwise. No, I've had problems with almsot all other previous GNU binutils releases, see my previous posts on this list. Including 2.13.x and 2.14? -- Eric Botcazou
Re: building gcc 4.0.0 on Solaris
Hi, I have configured with: ./configure \ --with-as=/usr/local/binutils/bin/as \ --with-ld=/usr/local/binutils/bin/ld \ ... so I should be using GNU's as and ld. --with-gnu-as and --with-gnu-ld I presume? No, but configure does detect that, doesn't it? I've never used these option flags before, I thought they were for HP-UX only. Mmh... I'll doublecheck. Hacking libtool is not supported anyway. ;-) I think you should use only GNU tools by tweaking your PATH. Ah, but I'm not hacking anything. Only in the specific case of sparc-sun-solaris2.8/libjava I had to switch from Sun's ar to GNU's ar. After building the library that wouldn't build, I reverted the change to libtool. This is a new issue and the previous hack is totally irrelevant. No, I've had problems with almsot all other previous GNU binutils releases, see my previous posts on this list. Including 2.13.x and 2.14? At least one of them. I'll have to check that, I can't recall which versions had problems. As far as I can remember I had always upgraded GNU binutils for specific reasons (the gcc build would fail, the build of our programs would fail, or our programs would fail). -- Dimitri
Re: building gcc 4.0.0 on Solaris
Hi, libgcj.so.6.0.0 is a monster so that could be a memory problem too. If you're not interested in Java, I'd suggest to configure with --disable-libgcj. Actually I'd like to help fix bugs in the Solaris toolchain, apart from compiling my C++ programs. Using xgcc -v instead of plain xgcc I've found that the problem happens here: /tmp/GCC/gcc/collect2 [...] /tmp/GCC/gcc/crtn.o -soname libgcj.so.6 collect2: ld returned 1 exit status Is there a way I can find the exact ld command line, in order to provide a small testcase for the GNU binutils bugzilla? -- Dimitri
Re: building gcc 4.0.0 on Solaris
Actually I'd like to help fix bugs in the Solaris toolchain, apart from compiling my C++ programs. Using xgcc -v instead of plain xgcc I've found that the problem happens here: /tmp/GCC/gcc/collect2 [...] /tmp/GCC/gcc/crtn.o -soname libgcj.so.6 collect2: ld returned 1 exit status Is there a way I can find the exact ld command line, in order to provide a small testcase for the GNU binutils bugzilla? Pass -debug to collect2. I'm not sure this will give you a *small* testcase though. -- Eric Botcazou
Re: building gcc 4.0.0 on Solaris
Actually I'd like to help fix bugs in the Solaris toolchain, apart from compiling my C++ programs. Using xgcc -v instead of plain xgcc I've found that the problem happens here: /tmp/GCC/gcc/collect2 [...] /tmp/GCC/gcc/crtn.o -soname libgcj.so.6 collect2: ld returned 1 exit status Is there a way I can find the exact ld command line, in order to provide a small testcase for the GNU binutils bugzilla? Pass -debug to collect2. I'm not sure this will give you a *small* testcase though. -- Eric Botcazou
Re: building gcc 4.0.0 on Solaris
Hi, Pass -debug to collect2. I'm not sure this will give you a *small* testcase though. /usr/local/binutils/bin/ld [...] -soname libgcj.so.6 [...] GNU ld version 2.16 Supported emulations: elf32_sparc elf64_sparc /usr/local/binutils/bin/ld: failed to set dynamic section sizes: Memory exhausted Ouch! 1 Mb RAM + 2Mb swap ought to be enough. I'm wondering what could be eating up memory when the workstation is idle, ps or top don't show any process eating up lots of memory and ipcs doesn't show shared memory in use: $ top [...] Memory: 1024M real, 235M free, 2450M swap in use, 231M swap free [...] 26336 root 1 590 122M 6968K sleep0:06 0.00% Xsun 185 root 14 580 13M 1984K sleep0:39 0.00% syslogd 26354 root 4 590 7448K 1808K sleep0:08 0.00% dtgreet 26340 root 4 100 5416K 1432K sleep0:00 0.00% dtlogin 323 root 4 380 5200K 1296K sleep0:01 0.00% dtlogin 173 root 5 380 4968K 2848K sleep 194:15 0.00% automountd [...] $ I think I'm going to reboot this workstation and restart... -- Dimitri
Re: Mainline bootstrap broken in varasm.c
Mark Mitchell wrote: Steve Kargl wrote: Julian already sent my a patch, which did not fix the problem. Additionally, I think the patch that caused the problem was committed by Nathan. Julian just happen to commit a patch to varasm.c two commits after Nathan. OK, thanks. I'm sure Nathan will look at it, come morning in the UK. yes. I somehow incorrectly grepped for IN_LIBGCC2 and found only one occurrence, #defining it. I have reverted that miscleanup. I wonder if USED_FOR_TARGET cannot be used here instead -- I'd find it less confusing at least. mutterIN_LIBGCC2 indeed, no, this is crtstuff/mutter nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Validating a C++ back-end
Vasanth wrote: Hi, I am working on a fresh C++ port and I am filling in all the machine specific hooks. How do I run the C++ testsuite on my compiler? I am familiar with the GCC torture/execute tests and have my backend passing those tests reasonably well. Now, I am looking for something similar for C++ to test my support for the language's features. Ah, you need a conformance testsuite. There are several conformance ones available, all proprietary AFAIK. Depending on what you want to verify, you might need a language conformance testsuite and/or an ABI conformance testsuite. A C++ specific forum might be able to provide the best info about what's available. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
RE: Mail. Mail! Mail?
On Tue, 2005-05-10 at 10:14 +0100, Dave Korn wrote: Original Message From: Zack Weinberg Sent: 09 May 2005 19:38 Bernard Leak writes: Can something be done to make the problem less obstructive? It's not obvious that the script should try to be too clever and work out which name to use. Mail looks as useful as any name it can have hard-coded. However, a comment could be added to the script *output* [... more useful suggestions ...] This is where I quietly mention that patches are welcome. zw How about an option to format the output suitable for piping straight into telnet mail.gnu.org 25? At this point, you might as well rewrite it in Perl and require Mail::Mailer, or rewrite it in python, and use smtplib (which is in the python standard lib)
RE: Re: information
A mail message with subject Re: information has been found containing a virus. The message was sent from gcc@gcc.gnu.org to the following: [EMAIL PROTECTED] For more information contact [EMAIL PROTECTED]
RE: Mail. Mail! Mail?
Original Message From: Daniel Berlin Sent: 10 May 2005 14:07 On Tue, 2005-05-10 at 10:14 +0100, Dave Korn wrote: Original Message From: Zack Weinberg Sent: 09 May 2005 19:38 Bernard Leak writes: Can something be done to make the problem less obstructive? It's not obvious that the script should try to be too clever and work out which name to use. Mail looks as useful as any name it can have hard-coded. However, a comment could be added to the script *output* [... more useful suggestions ...] This is where I quietly mention that patches are welcome. zw How about an option to format the output suitable for piping straight into telnet mail.gnu.org 25? At this point, you might as well rewrite it in Perl and require Mail::Mailer, or rewrite it in python, and use smtplib (which is in the python standard lib) I don't think that's a valid comparison. I would venture to suggest that telnet clients are far more universally installed than Mail::Mailer, or Python, or Perl, or quite likely even Mail. cheers, DaveK -- Can't think of a witty .sigline today
Re: Validating a C++ back-end
Vasanth wrote: Hi, I am working on a fresh C++ port and I am filling in all the machine specific hooks. How do I run the C++ testsuite on my compiler? I am familiar with the GCC torture/execute tests and have my backend passing those tests reasonably well. Now, I am looking for something similar for C++ to test my support for the language's features. I am a bit confused by how the Deja Gnu tests are organized. I see that the testsuite contains a lot of different tests of which, some are compile only tests, some are pre-processor tests etc. Aren't the runnable tests the main kind that I should be interested in? Given a compiler version of 3.x.x shouldn't I be able to rely on test results run on the generic portions by the GCC maintainers themselves and worry about only the runnable tests? Is there a specific/sufficient list of tests that I need to validate...? If you can get it going, I'd advise also trying boost, it uses alot of language features and will be a good test (although make sure you compare results again x86, as some tests do fail on various versions of gcc). Chris
Error building gcc 4.0.0 on AIX Box
I'm trying to build gcc 4.0.0 on my Aix 4.3.3 Box using a Gcc 3.3.3. The error i have seems to be a system error on available resources on my IBM RS6000. It looks like this: gmake[1]: Entering directory `/home/sinn/COMUNE/develop/gcc-4.0.0/objdir/gcc' build/genattrtab ../../gcc/config/rs6000/rs6000.md tmp-attrtab.c out of memory allocating 80016 bytes after a total of 4161621084 bytes gmake[1]: *** [s-attrtab] Error 1 gmake[1]: Leaving directory `/home/sinn/COMUNE/develop/gcc-4.0.0/objdir/gcc' gmake: *** [all-gcc] Error 2 Any help would be appreciated. Thanks. begin:vcard fn:Carlo Corridore n:Corridore;Carlo org:Alenia Aeronautica Nola;Sistemi di Integrazione adr:;;Via Boscofangone Zona A.S.I.;Polvica di Nola;NA;80035;Italy email;internet:[EMAIL PROTECTED] title:Systems Integration Manager tel;work:++39-81-315-4103 tel;fax:++39-81-315-4044 x-mozilla-html:FALSE version:2.1 end:vcard
Re: fold_indirect_ref bogous
On Tue, 3 May 2005, Jeffrey A Law wrote: On Wed, 2005-04-27 at 16:19 +0200, Richard Guenther wrote: fold_indirect_ref, called from the gimplifier happily converts ^^ something like the following patch fixes this. Right. Given that I'd seen similar problems with some unrelated changes of mine, I went ahead and put your patch through the usual bootstrap and regression tests on my i686 box. Installed. You didn't ;) You fixed tree-ssa-ccp.c:maybe_fold_stmt_indirect, not fold-const.c:fold_indirect_ref_1 ! The latter is causing the failure I'm running into. Richard. -- Richard Guenther richard dot guenther at uni-tuebingen dot de WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
[gnu.org #232556] GNU Mirror: SWITCHmirror replaces Swiss SunSITE
Hello, I've updated the mirror list on gnu.org. I'm passing this on to you so you can consider it for the GCC mirrors list as per his request. Start of forwarded message Subject: [gnu.org #232556] GNU Mirror: SWITCHmirror replaces Swiss SunSITE From: [EMAIL PROTECTED] via RT [EMAIL PROTECTED] Hello Gnu SWITCHmirror replaces the mirror service on Swiss SunSITE (sunsite.cnlab-switch.ch). Could you please add SWITCHmirror to the page http://gcc.gnu.org/mirrors.html On the page http://www.gnu.org/order/ftp.html, could you please replace the reference to Swiss SunSITE with the one to SWITCHmirror? The correct links for our mirror are now: http://mirror.switch.ch/ftp/mirror/gnu/ ftp://mirror.switch.ch/mirror/gnu/ The new contact address is: [EMAIL PROTECTED] it replaces the old address: [EMAIL PROTECTED] Country: Switzerland Many thanks ikn advance! Kind Regards Thomas _ Thomas Lenggenhager[EMAIL PROTECTED] SWITCH The Swiss Education Research Network Neumuehlequai 6 Tel: +41 44 268 1520 CH-8001 Zurich, Switzerland Fax: +41 44 268 1568 End of forwarded message -- John Sullivan Program Administrator| Phone: (617)542-5942 51 Franklin Street, 5th Fl. | Fax: (617)542-2652 Boston, MA 02110-1301 USA| GPG: AE8600B6
RE: Error building gcc 4.0.0 on AIX Box
Original Message From: Carlo Corridore Sent: 10 May 2005 16:16 I'm trying to build gcc 4.0.0 on my Aix 4.3.3 Box using a Gcc 3.3.3. The error i have seems to be a system error on available resources on my IBM RS6000. It looks like this: gmake[1]: Entering directory `/home/sinn/COMUNE/develop/gcc-4.0.0/objdir/gcc' build/genattrtab ../../gcc/config/rs6000/rs6000.md tmp-attrtab.c out of memory allocating 80016 bytes after a total of 4161621084 bytes gmake[1]: *** [s-attrtab] Error 1 gmake[1]: Leaving directory `/home/sinn/COMUNE/develop/gcc-4.0.0/objdir/gcc' gmake: *** [all-gcc] Error 2 Any help would be appreciated. Thanks. Only that you're not the first to run up against this problem: http://www.mail-archive.com/gcc@gcc.gnu.org/msg02674.html and that this answer: http://www.mail-archive.com/gcc@gcc.gnu.org/msg02945.html seemed to fix it, according to http://www.mail-archive.com/gcc@gcc.gnu.org/msg03336.html cheers, DaveK -- Can't think of a witty .sigline today
Re: Mail. Mail! Mail?
Bernard Leak wrote: Firstly, thanks to Bob Proulx for the helpful pointer to the Debian search widget. This is a genuinely useful-looking tool. How pleasing! Not wanting to take credit inappropriately, it was Zack who suggested the Debian package search page. I was the mailx history rant! :-) But unless he thinks this is another thing I should just know about, You have to draw the line somewhere. Take for example the contrived problem of documenting fully the process of waking up and going to work in the morning. Spend no more than 25 words describing how to tie your shoes. Is it sufficient for someone who has never seen shoelaces before to replicate the task and learn to tie their shoes? Probably not. True story. One of my friends was picking up his and the neighbor's kids in the car one day. My friend has an older car with crank windows. The neighbor kids had never seen that before and very politely (I was impressed) asked how could they please put the window down? It surprised me, but they had not ever seen a crank window before and eventually needed to ask for help. Those are the types of scenes I think about when I and others ask for help. I tried quite hard to find out the answers I needed before I first posted my question. And we appreciate that. I often spend a huge amount of time searching and creating test cases and then posting a note only to find that I missed something very simple. Oh well. One has to do the research first just the same. But then once done don't fear asking for help. Not having made an effort will show. As it will also show having made an honest effort to figure things out. How difficult does it have to be to find something out before adding it to the documentation looks like a benefit to other people? I don't think I have ever heard of anyone else having this particular problem before. Mind you there are a *lot* of potential problems. If you are forcing me to state an opinion I would say I think something needs to be asked three times before it becomes a frequently asked question. So no, I actually don't think this is a big deal and would not do anything taking huge effort to make sure it did not happen again. But if the problem did appear a few times or by judgement someone thought that it would be likely to happen then it would be useful to work to avoid. If you have a lot of time to waste you might try finding Mail in the Linux Documentation Project tree. You do have a lot of time to waste, don't you? I mean, it *might* be in there. Somewhere. Yes, I tried this at length before I gave up and made my posting. Again, I didn't think there was much point in mentioning it. The name is an unfortunately common word. I like the links browser. It has some really nice features. But one of the worst things about it is the fact that the name cannot be searched for with any reasonable success. (For those interested look at the extended project Elinks, as in 'apt-get install elinks', successful because you can search for that name.) Picking an unsearchable project name is a bad thing that we know is a bad thing today. But back when Mail was created, who knew? Does Bob think that if I don't know that Mail = mail I am roughly equally likely not to know about cat or grep? If so, he is clearly looking down on me from a position of such altitude as to be quite unable to recognise the problems the rest of us have. I am sorry my treatise on the history of mailx disturbed you so greatly. It was not my intention. I was really only working from the premise of, See one, do one, teach one. The reason I shared that essay was that if you don't know about it that it will make no sense. But if you do know about it then many things make sense. I often learn great things from the people who work hard to share their knowledge. In that same spirit I try to give it back when I can. Bob
Re: Mail. Mail! Mail?
Dear List, Jonathan Wakely wants me to send a patch (or more than one). Send a patch. Will do, after some further digging and sanity-testing, along the lines I have already indicated. Did you expect it already? I have to consider that not all builds of GCC are on UN*X-type boxes. The existing machinery for submitting test results is rather non-portable: I don't want to do anything to make it worse. This isn't GCC's problem. No it (was) mine - but it was a problem with GCC. I'm considering how GCC can be modified to help, so it doesn't become somebody else's problem. Most of the difficulty is not best dealt with in GCC, but I think some of it is. Send a patch I've already sent a suggestion to O'Reilly fpr the next edition of Linux in a Nutshell. I'm thinking what can be done by way of producing a one-stop shop for nasty aliases and homonyms (libxml=gnome-xml and all the others) to go in the LDP. Any other bright ideas? Or can someone point me to where it has all been done before? Bernard Leak -- Before they made me, they broke the mould
Re: Mail. Mail! Mail?
On Tue, May 10, 2005 at 04:58:03PM +0100, Bernard Leak wrote: Dear List, Jonathan Wakely wants me to send a patch (or more than one). :-) Send a patch. Will do, after some further digging and sanity-testing, along the lines I have already indicated. Did you expect it already? I have to consider that not all builds of GCC are on UN*X-type boxes. The existing machinery for submitting test results is rather non-portable: I don't want to do anything to make it worse. Cool. I'm sure plenty of people will be glad to look over it and verify anything you're not sure about, just mention if you think a certain bit needs extra attention. I've already sent a suggestion to O'Reilly fpr the next edition of Linux in a Nutshell. I'm thinking what can be done by way of producing a one-stop shop for nasty aliases and homonyms (libxml=gnome-xml and all the others) to go in the LDP. Any other bright ideas? Or can someone point me to where it has all been done before? That sounds like a very good idea to me. Here's one that bothers me when I move between different machines: soffice / ooffice jon
Re: Validating a C++ back-end
Hi Nathan, Thanks for the inputs. Can you tell me if there is a set of tests in the G++ testsuite for verifying just my implementation of basic machine dependent C++ hooks? To give examples - verify global constructor/destructors being invoked correctly, init_priority, thunks, Vtable stuff etc. Can I just take all those dg-do run tests and run them on my target? I am just looking for basic testing since I am only in the initial stages, before I go onto those full blown conformance tests. thanks for the clarifications so far, Vasanth On 5/10/05, Nathan Sidwell [EMAIL PROTECTED] wrote: Vasanth wrote: Hi, I am working on a fresh C++ port and I am filling in all the machine specific hooks. How do I run the C++ testsuite on my compiler? I am familiar with the GCC torture/execute tests and have my backend passing those tests reasonably well. Now, I am looking for something similar for C++ to test my support for the language's features. Ah, you need a conformance testsuite. There are several conformance ones available, all proprietary AFAIK. Depending on what you want to verify, you might need a language conformance testsuite and/or an ABI conformance testsuite. A C++ specific forum might be able to provide the best info about what's available. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Validating a C++ back-end
Vasanth wrote: Hi Nathan, Thanks for the inputs. Can you tell me if there is a set of tests in the G++ testsuite for verifying just my implementation of basic machine dependent C++ hooks? To give examples - verify global constructor/destructors being invoked correctly, init_priority, thunks, Vtable stuff etc. Can I just take all those dg-do run tests and run them on my target? All gcc has are the g++.dg and g++-old-deja tests. If they pass, you have a compiler that is probably as functional as any other gcc target. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: emit_conditional_move w/o compare insn (was: Full comparison in 'cbranchsi4' leads to error in gcc 4.0)
Hi Gary, Thanks a lot for the tip. After debugging, the problem seem to be coming from 'emit_conditional_move' which is called by 'expand_sdiv_pow2' when converting division-by-constants into shifting. The problem is that the architecture I have does not support compare operations: It either has a conditional move or a conditional branch instructions (the compare operation is part of these instructions). To make a conditional move, 'emit_conditional_move' generates a seperate compare and then a move insns, maybe hoping that these will be later combined into a single instruction during the optimization steps. Would it be possible to tell this to emit_conditional_move so that it generates the cmove insn directely? Many Thanks, Sami Khawam Gary Funck wrote: This works fine on gcc 3.4, however on gcc 4.0 it creates an error during optimization. According to my investigation, the error occurs when there is a division by a constant power of 2 which needs to be transformed into shifting. The error generated is: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:3599 The easiest thing to do is to debug gcc: set a breakpoint on fancy_abort, and and go up a few levels to emit_cmp_and_jump_insn_1(). Note the incoming rtx args (x and y) and mode. From the looks of the code in there it is looking for an instruction pattern that matches, and when no match is found, it tries a wider mode, until there are no wider modes, then it aborts. You need to find the mode and rtx arguments that are being passed in, and then understand why no matching instruction is found. For example, in your instruction pattern, (define_insn cbranchsi4 [(set (pc) (if_then_else (match_operator 0 comparison_operator [(match_operand:SI 1 register_operand r) (match_operand:SI 2 nonmemory_operand r)]) (label_ref (match_operand 3 )) (pc)))] c%C0jump %1 %2 %3 [(set_attr type branch) (set_attr length 1)] ) it isn't prepared to match a memory operand. Perhaps the optimizer pre-calculated a constant, and targeted the constant into memory rather than a register? In that case, there will be no match on the third argument because it is expecting a nonmemoryoperand.
Re: use of preserve_temp_slots in copy_blkmode_from_reg
While looking at this, I found that expr.c always calls free_temp_slots immediately followed by pops_temp_slots. Isn't the call to free_temp_slots pointless there? It looks like it is now. It didn't used to be though (when we had RTL_EXPR).
Re: GCSE considers read only memory clobbered by function calls.
On Tue, May 10, 2005 at 11:37:50AM +0300, Mostafa Hagog wrote: I want to add the below example as a regression test; the difference between the success and failure is the position of a load operation. Is there a possibility to check this using the scan-assembler? No. r~
Re: building gcc 4.0.0 on Solaris
/usr/local/binutils/bin/ld [...] -soname libgcj.so.6 [...] GNU ld version 2.16 Supported emulations: elf32_sparc elf64_sparc /usr/local/binutils/bin/ld: failed to set dynamic section sizes: Memory exhausted Ouch! 1 Mb RAM + 2Mb swap ought to be enough. Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not be used to build libgcj nowadays. ;-) -- Eric Botcazou
Re: building gcc 4.0.0 on Solaris
Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not be used to build libgcj nowadays. ;-) Ooops :-) These were indeed Gb instead of Mb for those wondering... -- Dimitri
Re: building gcc 4.0.0 on Solaris
On Tue, 10 May 2005, Dimitri Papadopoulos-Orfanos wrote: Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not be used to build libgcj nowadays. ;-) Ooops :-) These were indeed Gb instead of Mb for those wondering... [have not followed this thread, so sorry if it was already suggested] BTW: Have you tried to also look at what ulimits are set on your system? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
ppc-eabisim is broken in mainline
Between 20050505 and 20050510, the ppc-eabisim configuration was broken. I'm seeing this error: /mnt/scratch/nightly/2005-05-10-orv/ppc/./gcc/xgcc -B/mnt/scratch/nightly/2005-05-10-orv/ppc/./gcc/ -nostdinc -B/mnt/scratch/nightly/2005-05-10-orv/ppc/powerpc-eabisim/newlib/ -isystem /mnt/scratch/nightly/2005-05-10-orv/ppc/powerpc-eabisim/newlib/targ-include -isystem /mnt/scratch/nightly/2005-05-10-orv/srcw/newlib/libc/include -B/usr/local/powerpc-eabisim/bin/ -B/usr/local/powerpc-eabisim/lib/ -isystem /usr/local/powerpc-eabisim/include -isystem /usr/local/powerpc-eabisim/sys-include -L/mnt/scratch/nightly/2005-05-10-orv/ppc/./ld -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I -I../../srcw/gcc -I../../srcw/gcc/ -I../../srcw/gcc/../include -I../../srcw/gcc/../libcpp/include -mrelocatable-lib -mno-eabi -mstrict-align -xassembler-with-cpp -c eabi.S -o libgcc/./eabi.o /mnt/scratch/nightly/2005-05-10-orv/ppc/gcc//: Assembler messages: /mnt/scratch/nightly/2005-05-10-orv/ppc/gcc//:1: Warning: line numbers must be positive; line number 0 rejected eabi.S:136: Error: Relocation cannot be done when using -mrelocatable eabi.S:137: Error: Relocation cannot be done when using -mrelocatable eabi.S:138: Error: Relocation cannot be done when using -mrelocatable eabi.S:139: Error: Relocation cannot be done when using -mrelocatable eabi.S:142: Error: Relocation cannot be done when using -mrelocatable make[2]: *** [libgcc/./eabi.o] Error 1 make[2]: Leaving directory `/mnt/scratch/nightly/2005-05-10-orv/ppc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/mnt/scratch/nightly/2005-05-10-orv/ppc/gcc' make: *** [all-gcc] Error 2 build failed Some experimentation shows that the assembler from the two dates behaves the same, and eabi.S is identical, but the preprocessed source files differ. cc1 used to define _RELOCATABLE, but it does not any more. The definition used to be: # 0 built-in #define _RELOCATABLE 1
Re: ppc-eabisim is broken in mainline
On May 10, 2005, at 1:54 PM, Joern RENNECKE wrote: Between 20050505 and 20050510, the ppc-eabisim configuration was broken. /mnt/scratch/nightly/2005-05-10-orv/ppc/gcc//:1: Warning: line numbers must be positive; line number 0 rejected That is PR 21250 and this has been failing since April 19. Thanks, Andrew Pinski
Re: ppc-eabisim is broken in mainline
Andrew Pinski wrote: On May 10, 2005, at 1:54 PM, Joern RENNECKE wrote: Between 20050505 and 20050510, the ppc-eabisim configuration was broken. /mnt/scratch/nightly/2005-05-10-orv/ppc/gcc//:1: Warning: line numbers must be positive; line number 0 rejected That is PR 21250 and this has been failing since April 19. That warning does indeed also appear in the build from 20050505, but it does not stop the build. The 'Relocation cannot be done when using -mrelocatable' error does.
Re: building gcc 4.0.0 on Solaris
Hi, BTW: Have you tried to also look at what ulimits are set on your system? I've rebooted the system and things are really getting better (even Sun's ar seems to be working now). This was a kernel problem, the kernel is not up-to-date with patches and the workstation hadn't been rebooted for months. There were only 30-40 processes running, eating less than 300 Mb, but the system was nevertheless reporting only a few Mb RAM+swap left. I'm also using --with-gnu-as and --with-gnu-ld now. At some point these were required or made a difference on HP-UX only as far as I can recall; I hadn't noticed they were now required or making a difference on Solaris too. -- Dimitri
Re: ppc-eabisim is broken in mainline
On May 10, 2005, at 2:04 PM, Joern RENNECKE wrote: Andrew Pinski wrote: On May 10, 2005, at 1:54 PM, Joern RENNECKE wrote: Between 20050505 and 20050510, the ppc-eabisim configuration was broken. /mnt/scratch/nightly/2005-05-10-orv/ppc/gcc//:1: Warning: line numbers must be positive; line number 0 rejected That is PR 21250 and this has been failing since April 19. That warning does indeed also appear in the build from 20050505, but it does not stop the build. The 'Relocation cannot be done when using -mrelocatable' error does. Sorry I should have looked closer to what actually was causing the build to stop, sorry again. -- Pinski
Re: building gcc 4.0.0 on Solaris
I'm also using --with-gnu-as and --with-gnu-ld now. At some point these were required or made a difference on HP-UX only as far as I can recall; I hadn't noticed they were now required or making a difference on Solaris too. They should not be required if --with-as and --with-ld are respectively specified because the configure machinery will probe in that case. They are required otherwise because the Sun tools are the default. -- Eric Botcazou
Re: Regression on mainline in tree-vrp.c
On Fri, Apr 22, 2005 at 02:56:30PM -0700, Steve Kargl wrote: Appears that any nested loops are doomed with -O2 with gfortran. This is a critical important problem, because almost every Fortran program that I know contains nested loops. Is this fixed now? This works for me. Diego.
Re: Regression on mainline in tree-vrp.c
Diego Novillo writes: Is this fixed now? This works for me. The Ada bootstrap problem on i386-pc-solaris2.10 is fixed, thanks. I tried to submit a separate bug report via gccbug, but that (like another one a bit earlier) got silently ignored ;-( It neither made it into Bugzilla nor triggered any hint that gcc-gnats has been turned off. Right now, I'm running into another Ada problem, where the native as chokes while gas only warns and continues: stage1/xgcc -Bstage1/ -B/vol/gcc/share/i386-pc-solaris2.10/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada /vol/gnu/src/gcc/gcc-dist/gcc/ada/exp_ch3.adb -o ada/exp_ch3.o Assembler: exp_ch3.adb /var/tmp//cccKJdly.s, line 13008 : Value out of range where line 13008 is movw-4294967296(%ecx), %dx gas gives exp_ch3.s: Assembler messages: exp_ch3.s:13009: Warning: shortened to instead. This is most likely unrelated, and I'll fully report it once I can get gccbug to work again. Rainer
Re: Regression on mainline in tree-vrp.c
On Tue, May 10, 2005 at 02:55:36PM -0400, Diego Novillo wrote: On Fri, Apr 22, 2005 at 02:56:30PM -0700, Steve Kargl wrote: Appears that any nested loops are doomed with -O2 with gfortran. This is a critical important problem, because almost every Fortran program that I know contains nested loops. Is this fixed now? This works for me. Yes. I believe the commit that fixed the problem was 2005-04-28 Kazu Hirata [EMAIL PROTECTED] PR tree-optimization/21030 * tree-vrp.c (adjust_range_with_scev): Do not create invalid ranges where VR-MAX is smaller than VR-MIN. -- Steve
Can gcc select vector mode instruction patterns itself?
I'm porting gcc to a new VLIW architecture.
There are 11 function units in the chip, and 4 of them are DSPs.
Now I'm designing the SIMD instruction patterns, and I wouldn't like use the
built-in functions to support it.
If I wrote some instruction patterns which involved many V4QI
packing/unpacking/arithmetic operations,
could gcc try to select them automatically and smartly?
(Of course I never wrote any define_expand/define_split to generate any V4QI
operations myself.)
For example:
1. my packing instruction patterns ('D' means DSP register):
(define_insn *packqi_from_mem
[(set (vec_select:QI (match_operand:V4QI 0 register_operand D)
(parallel [(match_operand:SI 2 const_int_operand
i)]))
(match_operand:QI 1 memory_operand m))]
ldub.b%2\\t%0, %1
)
2. my V4QI + V4QI SIMD operation
(define_insn *SIMD_addqi3
[(set (match_operand:V4QI 0 register_operand =D)
(plus:V4QI (match_operand:V4QI 1 register_operand %D)
(match_operand:V4QI 2 register_operand
D)))]
add.ub\\t%0, %1, %2
)
Is it possible that gcc can try to load 4 QImode value to a register by the pattern
*packqi_from_mem
and perform the V4QI + V4QI SIMD add by the pattern *SIMD_addqi3 itself?
Post-Lillehammer WG14 mailing
The post-Lillehammer WG14 mailing is now available at http://www.open-std.org/jtc1/sc22/wg14/www/docs/post-lillehammer.htm. It includes a copy of C99 merged with TC1 and TC2 (and apparently some other editorial changes in the foreword). The DR discussions in the draft minutes may not be ready to rely on yet, but should at least be indicative of possible directions, in particular that we may be able to get away with merging structure types across multiple translation units with IMA (in C99 if not in C90 where type compatibility doesn't require the tag to be the same). -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Targets using implicit extern C
On Tue, May 10, 2005 at 02:26:12PM -0400, Ian Lance Taylor wrote: How would people feel about adding a configure option --with-implicit-extern-c? Then we could justifiably flip the default for the generic *-elf, etc., targets. In fact in general we could then take the macro out of the tm.h files and into config.gcc, which is probably a more reliable place to put it anyhow. I think that the decision should be made at configure time, by checking the #include headers to see if they are C++-ready. Look for the string __cplusplus in some set of standard headers, if it is not found, assume that we'll need implicit extern C. For cross-builds, we still have a path to the headers to be checked.
A question about tree-if-conv.c:tree_if_convert_stmt.
Hi, According to the CVS annotate of tree-if-conv.c, Devang Patel checked in the following code in tree_if_convert_stmt. case GOTO_EXPR: /* Unconditional goto */ add_to_predicate_list (bb_for_stmt (TREE_OPERAND (t, 1)), cond); Note that TREE_OPERAND (t, 1) seems wrong. A GOTO_EXPR takes only one operand. I am pretty sure this part of the code has never been run because if it had been, then the compiler would have ICEd by now. Now, what would be the right fix here? Something like this? case GOTO_EXPR: break; As far as I know, all jumps except computed gotos are are implicitly represented by the CFG. I don't think the if-conv is trying to handle computed gotos here. By the way, this problem has been filed as PR 18472. Kazu Hirata
Re: A question about tree-if-conv.c:tree_if_convert_stmt.
On May 10, 2005, at 1:37 PM, Kazu Hirata wrote: Now, what would be the right fix here? Something like this? case GOTO_EXPR: break; Just remove handling of GOTO_EXPR here and in if_convertible_stmt_p(). - Devang
Re: A question about tree-if-conv.c:tree_if_convert_stmt.
Hi Devang, Just remove handling of GOTO_EXPR here and in if_convertible_stmt_p(). OK. Will submit a patch. Kazu Hirata
Re: Targets using implicit extern C
Joe Buck wrote: On Tue, May 10, 2005 at 02:26:12PM -0400, Ian Lance Taylor wrote: How would people feel about adding a configure option --with-implicit-extern-c? Then we could justifiably flip the default for the generic *-elf, etc., targets. In fact in general we could then take the macro out of the tm.h files and into config.gcc, which is probably a more reliable place to put it anyhow. I think that the decision should be made at configure time, by checking the #include headers to see if they are C++-ready. Look for the string __cplusplus in some set of standard headers, if it is not found, assume that we'll need implicit extern C. For cross-builds, we still have a path to the headers to be checked. Autoconfigury would be hard to make reliable in Darwin, where the problem headers are (mostly) a number of levels down and in obscure places under /usr/include. The --with option would work better. Stan
Re: Targets using implicit extern C
Joe Buck [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 02:26:12PM -0400, Ian Lance Taylor wrote: How would people feel about adding a configure option --with-implicit-extern-c? Then we could justifiably flip the default for the generic *-elf, etc., targets. In fact in general we could then take the macro out of the tm.h files and into config.gcc, which is probably a more reliable place to put it anyhow. I think that the decision should be made at configure time, by checking the #include headers to see if they are C++-ready. Look for the string __cplusplus in some set of standard headers, if it is not found, assume that we'll need implicit extern C. For cross-builds, we still have a path to the headers to be checked. It would be hard to make that completely reliable for embedded systems development, where the header files may or not be available in any standard place at the time that gcc is configured. That would be a good way to set the default for the configure option, of course. Ian
Re: Targets using implicit extern C
Ian Lance Taylor wrote: Joe Buck [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 02:26:12PM -0400, Ian Lance Taylor wrote: How would people feel about adding a configure option --with-implicit-extern-c? Then we could justifiably flip the default for the generic *-elf, etc., targets. In fact in general we could then take the macro out of the tm.h files and into config.gcc, which is probably a more reliable place to put it anyhow. I think that the decision should be made at configure time, by checking the #include headers to see if they are C++-ready. Look for the string __cplusplus in some set of standard headers, if it is not found, assume that we'll need implicit extern C. For cross-builds, we still have a path to the headers to be checked. It would be hard to make that completely reliable for embedded systems development, where the header files may or not be available in any standard place at the time that gcc is configured. E.g. the AVR target, which normally uses avr-libc: http://savannah.nongnu.org/projects/avr-libc/ but only builds avr-libc after gcc is built. Eric
Recog - unrecognized insn when clobber present
Hi,
I am working on a port of GCC to a 32-bit RISC machine. I am having
trouble with .combine pass adding clobbers to instruction patterns. To
be more specific,
(define_insn lshrsi3_internal_reg_nohwshift
[(set (match_operand:SI 0 register_operand =d)
(lshiftrt:SI (match_operand:SI 1 register_operand d)
(match_operand:SI 2 register_operand d)))
(clobber (reg:SI R_TMP))]
!(TARGET_HW_SHIFT)
{
...
}
is what I have in my md file. When compiling __lshrdi3 in libgcc2, I
see the following RTL produced
libgcc2.i.19.life:
(insn 43 41 44 4 (set (reg:SI 93)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 0)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84 [ u ]) 0)
(reg/v:SI 85 [ b ]))
(nil)))
(insn 44 43 46 4 (set (subreg:SI (reg/v:DI 89 [ w ]) 0)
(reg:SI 93)) 46 {movsi_internal2} (insn_list 43 (nil))
(expr_list:REG_DEAD (reg:SI 93)
(nil)))
(insn 46 44 47 4 (set (reg:SI 94)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 4)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 87 [ uu ])
(expr_list:REG_DEAD (reg/v:SI 85 [ b ])
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84 [ u ]) 4)
(reg/v:SI 85 [ b ]))
(nil)
After combine, I expect recog to take insn 43 and 46 and cause both to
match lshrsi3_internal_reg_nohwshift. However, insn 46 seems to not
get the clobber attached in a parallel while 43 does.
libgcc2.i.20.combine:
(insn 44 43 46 4 (parallel [
(set (subreg:SI (reg/v:DI 89 [ w ]) 0)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 0)
(reg/v:SI 85 [ b ])))
(clobber (reg:SI 18 r18))
]) 72 {lshrsi3_internal_reg_nohwshift} (nil)
(expr_list:REG_UNUSED (reg:SI 18 r18)
(nil)))
(insn 46 44 47 4 (set (reg:SI 94)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 4)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 87 [ uu ])
(expr_list:REG_DEAD (reg/v:SI 85 [ b ])
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84 [ u ]) 4)
(reg/v:SI 85 [ b ]))
(nil)
Hence, I get an unrecognized insn error soon after. The only
difference between 43 and 46 seems to be that 43 underwent a
combination with 44 and is subregging 0, while 46 is subregging to
byte 4.
Taking away the clobber makes the insn match and the code to compile.
Any ideas what/where I should start checking? Help is greatly appreciated..
thanks,
Vasanth
Re: Targets using implicit extern C
Joe Buck [EMAIL PROTECTED] writes: I think that the decision should be made at configure time, by checking the #include headers to see if they are C++-ready. Look for the string __cplusplus in some set of standard headers, if it is not found, assume that we'll need implicit extern C. For cross-builds, we still have a path to the headers to be checked. Ian Lance Taylor wrote: It would be hard to make that completely reliable for embedded systems development, where the header files may or not be available in any standard place at the time that gcc is configured. On Tue, May 10, 2005 at 04:30:43PM -0600, E. Weddington wrote: E.g. the AVR target, which normally uses avr-libc: http://savannah.nongnu.org/projects/avr-libc/ but only builds avr-libc after gcc is built. Right, but you don't need the answer to the question until it's time to build libstdc++, and you can't build libstdc++ without a C library. So can't the test be deferred until that point?
Re: Targets using implicit extern C
Joe Buck wrote: Ian Lance Taylor wrote: It would be hard to make that completely reliable for embedded systems development, where the header files may or not be available in any standard place at the time that gcc is configured. On Tue, May 10, 2005 at 04:30:43PM -0600, E. Weddington wrote: E.g. the AVR target, which normally uses avr-libc: http://savannah.nongnu.org/projects/avr-libc/ but only builds avr-libc after gcc is built. Right, but you don't need the answer to the question until it's time to build libstdc++, and you can't build libstdc++ without a C library. So can't the test be deferred until that point? Seems reasonable, sure. Eric
Re: Targets using implicit extern C
Joe Buck wrote: Right, but you don't need the answer to the question until it's time to build libstdc++, and you can't build libstdc++ without a C library. So can't the test be deferred until that point? I don't think that's a good idea. People build compilers without headers frequently, and this really can be sensibly defaulted in the configuration, perhaps with a configure option to override. Also, the presence of __cplusplus in some system headers isn't enough to make sure that the headers are really C++-aware; I've seen systems with a few such headers, but not complete awareness. The argument that there's no right answer for *-elf seems odd to me. We already make assumptions for *-elf that may not be correct for all systems, like how to run static initializers, etc. We certainly can't build libstdc++ without knowing about the target C library. I'd be willing to consider the argument that this should actually be a -f switch, with a default determined by the target triplet. That would make it possible to use a *-elf compiler with different headers/libraries that you got from somewhere without having to rebuild the compiler, which seems better than any autoconfery. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.0 Performance Regressions?
On Tue, May 10, 2005 at 06:08:43PM -0500, Jason Bucata wrote: Would it help to report some others [regressions]? I might have time later this week to work on some of the others, especially now that I have a much better idea of what to look for. If you can find a small test with a large regression (say 30% or more), it would be great to have a PR for such a thing. All else being equal, smaller test cases are easier to debug, so I'd suggest starting with as small a test as possible that causes as large a regression as possible, if you have any like that.
The Linux binutils 2.16.90.0.3 is released
This is the beta release of binutils 2.16.90.0.3 for Linux, which is based on binutils 2005 0510 in CVS on sources.redhat.com plus various changes. It is purely for Linux. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.3 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.16.90.0.3 to [EMAIL PROTECTED] and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.16.90.0.2: 1. Update from binutils 2005 0510. 2. Update ia64 assembler to support comdat group section generated by gcc 4 (PR 940). 3. Fix a linker crash on bad input (PR 939). 4. Fix a sh64 assembler regression (PR 936). 5. Support linker script on executable (PR 882). 6. Fix the linker -pie regression (PR 878). 7. Fix an x86_64 disassembler bug (PR 843). 8. Fix a PPC linker regression. 9. Misc speed up. Changes from binutils 2.16.90.0.1: 1. Update from binutils 2005 0429. 2. Fix an ELF linker regression (PR 815). 3. Fix an empty section removal related bug. 4. Fix an ia64 linker regression (PR 855). 5. Don't allow local symbol to be equated common/undefined symbols (PR 857). 6. Fix the ia64 linker to handle local dynamic symbol error reporting. 7. Make non-debugging reference to discarded section an error (PR 858). 8. Support Sparc/TLS. 9. Support rpm build with newer rpm. 10. Fix an alpha linker regression. 11. Fix the non-gcc build regression. Changes from binutils 2.15.94.0.2.2: 1. Update from binutils 2005 0408. 2. The i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location. 3. The x86_64 assembler now allows movq between a segment register and a 64bit general purpose register. 4. 20x Speed up linker for input files with 64K sections. 5. Properly report ia64 linker relaxation failures. 6. Support tuning ia64 assembler for Itanium 2 processors. 7. Linker will remove empty unused output sections. 8. Add -N to readelf to display full section names. 9. Fix the ia64 linker to support linkonce text sections without unwind sections. 10. More unwind directive checkings in the ia64 assembler. 11. Speed up linker with wildcard handling. 12. Fix readelf to properly dump .debug_ranges and .debug_loc sections. Changes from binutils 2.15.94.0.2: 1. Fix greater than 64K section support in linker. 2. Properly handle i386 and x86_64 protected symbols in linker. 3. Fix readelf for LEB128 on 64bit hosts. 4. Speed up readelf for section group process. 5. Include ia64 texinfo pages. 6. Change ia64 assembler to check hint.b for Montecito. 7. Improve relaxation failure report in ia64 linker. 8. Fix ia64 linker to allow relax backward branch in the same section. Changes from binutils 2.15.94.0.1: 1. Update from binutils 2004 1220. 2. Fix strip for TLS symbol references. Changes from binutils 2.15.92.0.2: 1. Update from binutils 2004 1121. 2. Put ia64 .ctors/.dtors sections next to small data section for Intel ia64 compiler. 3. Fix -Bdynamic/-Bstatic handling for linker script. 4. Provide more information on relocation overflow. 5. Add --sort-section to linker. 6. Support icc 8.1 unwind info in readelf. 7. Fix the infinite loop bug on bad input in the ia64 assembler. 8. Fix ia64 SECREL relocation in linker. 9. Fix a section group memory leak in readelf. Changes from binutils 2.15.91.0.2: 1. Update from binutils 2004 0927. 2. Work around a section header bug in Intel ia64 compiler. 3. Fix an unwind directive bug in the ia64 assembler. 4. Fix various PPC bugs. 5. Update ARM support. 6. Fix an x86-64 linker warning while building Linux kernel. Changes from binutils 2.15.91.0.1: 1. Update from binutils 2004 0727. 2. Fix the x86_64 linker to prevent non-PIC code in shared library. 3. Fix the ia64 linker to warn the relotable files which can't be relaxed. 4. Fix the comdat group support. Allow mix single-member comdat group with
Re: Recog - unrecognized insn when clobber present
Vasanth [EMAIL PROTECTED] writes:
I am working on a port of GCC to a 32-bit RISC machine. I am having
trouble with .combine pass adding clobbers to instruction patterns. To
be more specific,
(define_insn lshrsi3_internal_reg_nohwshift
[(set (match_operand:SI 0 register_operand =d)
(lshiftrt:SI (match_operand:SI 1 register_operand d)
(match_operand:SI 2 register_operand d)))
(clobber (reg:SI R_TMP))]
!(TARGET_HW_SHIFT)
{
...
}
is what I have in my md file. When compiling __lshrdi3 in libgcc2, I
see the following RTL produced
libgcc2.i.19.life:
(insn 43 41 44 4 (set (reg:SI 93)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 0)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84 [ u ]) 0)
(reg/v:SI 85 [ b ]))
(nil)))
(insn 44 43 46 4 (set (subreg:SI (reg/v:DI 89 [ w ]) 0)
(reg:SI 93)) 46 {movsi_internal2} (insn_list 43 (nil))
(expr_list:REG_DEAD (reg:SI 93)
(nil)))
(insn 46 44 47 4 (set (reg:SI 94)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 4)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 87 [ uu ])
(expr_list:REG_DEAD (reg/v:SI 85 [ b ])
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84 [ u ])
4)
(reg/v:SI 85 [ b ]))
(nil)
After combine, I expect recog to take insn 43 and 46 and cause both to
match lshrsi3_internal_reg_nohwshift. However, insn 46 seems to not
get the clobber attached in a parallel while 43 does.
libgcc2.i.20.combine:
(insn 44 43 46 4 (parallel [
(set (subreg:SI (reg/v:DI 89 [ w ]) 0)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 0)
(reg/v:SI 85 [ b ])))
(clobber (reg:SI 18 r18))
]) 72 {lshrsi3_internal_reg_nohwshift} (nil)
(expr_list:REG_UNUSED (reg:SI 18 r18)
(nil)))
(insn 46 44 47 4 (set (reg:SI 94)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 4)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 87 [ uu ])
(expr_list:REG_DEAD (reg/v:SI 85 [ b ])
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84 [ u ])
4)
(reg/v:SI 85 [ b ]))
(nil)
Hence, I get an unrecognized insn error soon after. The only
difference between 43 and 46 seems to be that 43 underwent a
combination with 44 and is subregging 0, while 46 is subregging to
byte 4.
Taking away the clobber makes the insn match and the code to compile.
When combining instructions, the combine pass will add clobbers if
needed to recognize the combined instruction. This is documented in
the description of the RTL code CLOBBER. What is happening here is
that combine sees that it can combine insns 43 and 44 if it adds a
clobber. So it does that.
combine can't see how to combine insn 46 with anything, so it doesn't
add a clobber.
You seem to be saying that insn 44 as generated by combined is not
recognized. I don't see why. Doesn't it match the
lshrsi3_internal_reg_nohwshift pattern? If it didn't, combine would
not generate it.
Ian
Re: Validating a C++ back-end
On May 9, 2005, at 10:20 PM, Vasanth wrote: How do I run the C++ testsuite on my compiler? make check, it isn't meant to be that hard or complex. If you get 10 or fewer unexpected failures in the C++ testsuite and the libstdc++ testsuite, then, you are in the game, if more, you'll want to investigate.
RE: Recog - unrecognized insn when clobber present
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ian
Lance Taylor
Sent: Tuesday, May 10, 2005 6:17 PM
To: Vasanth
Cc: gcc@gcc.gnu.org
Subject: Re: Recog - unrecognized insn when clobber present
Vasanth [EMAIL PROTECTED] writes:
I am working on a port of GCC to a 32-bit RISC machine. I am having
trouble with .combine pass adding clobbers to instruction patterns.
To
be more specific,
(define_insn lshrsi3_internal_reg_nohwshift
[(set (match_operand:SI 0 register_operand =d)
(lshiftrt:SI (match_operand:SI 1 register_operand d)
(match_operand:SI 2 register_operand d)))
(clobber (reg:SI R_TMP))]
!(TARGET_HW_SHIFT)
{
...
}
is what I have in my md file. When compiling __lshrdi3 in libgcc2, I
see the following RTL produced
libgcc2.i.19.life:
(insn 43 41 44 4 (set (reg:SI 93)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 0)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84 [ u ])
0)
(reg/v:SI 85 [ b ]))
(nil)))
(insn 44 43 46 4 (set (subreg:SI (reg/v:DI 89 [ w ]) 0)
(reg:SI 93)) 46 {movsi_internal2} (insn_list 43 (nil))
(expr_list:REG_DEAD (reg:SI 93)
(nil)))
(insn 46 44 47 4 (set (reg:SI 94)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 4)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 87 [ uu ])
(expr_list:REG_DEAD (reg/v:SI 85 [ b ])
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84
[ u
]) 4)
(reg/v:SI 85 [ b ]))
(nil)
After combine, I expect recog to take insn 43 and 46 and cause both
to
match lshrsi3_internal_reg_nohwshift. However, insn 46 seems to not
get the clobber attached in a parallel while 43 does.
libgcc2.i.20.combine:
(insn 44 43 46 4 (parallel [
(set (subreg:SI (reg/v:DI 89 [ w ]) 0)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 0)
(reg/v:SI 85 [ b ])))
(clobber (reg:SI 18 r18))
]) 72 {lshrsi3_internal_reg_nohwshift} (nil)
(expr_list:REG_UNUSED (reg:SI 18 r18)
(nil)))
(insn 46 44 47 4 (set (reg:SI 94)
(lshiftrt:SI (subreg:SI (reg/v:DI 87 [ uu ]) 4)
(reg/v:SI 85 [ b ]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 87 [ uu ])
(expr_list:REG_DEAD (reg/v:SI 85 [ b ])
(expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 84
[ u
]) 4)
(reg/v:SI 85 [ b ]))
(nil)
Hence, I get an unrecognized insn error soon after. The only
difference between 43 and 46 seems to be that 43 underwent a
combination with 44 and is subregging 0, while 46 is subregging to
byte 4.
Taking away the clobber makes the insn match and the code to compile.
When combining instructions, the combine pass will add clobbers if
needed to recognize the combined instruction. This is documented in
the description of the RTL code CLOBBER. What is happening here is
that combine sees that it can combine insns 43 and 44 if it adds a
clobber. So it does that.
combine can't see how to combine insn 46 with anything, so it doesn't
add a clobber.
You seem to be saying that insn 44 as generated by combined is not
recognized. I don't see why. Doesn't it match the
lshrsi3_internal_reg_nohwshift pattern? If it didn't, combine would
not generate it.
Ian
Hi Ian,
Sorry if I was not clear. Insn 46 is what is unrecognized. As you can
see 44 is indeed matched by lshiftrt_internal_reg_nohwshift.
Quoting from the description of (clobber x),
### If the last group of expressions in a parallel are each a clobber
expression whose arguments are reg or match_scratch (see section 10.4
RTL Template) expressions, the combiner phase can add the appropriate
clobber expressions to an insn it has constructed when doing so will
cause a pattern to be matched.
In this case, the combiner could not combine 46 with anything else,
which is ok. The description still seems to say that the combiner can
just add a clobber to the insn to cause a match with
lshiftrt_internal_reg_nohwshift. It has chosen not to do so and hence
the insn becomes unrecognized.
Am I missing something here? This is with GCC 3.4.1.
thanks,
Vasanth
Re: Recog - unrecognized insn when clobber present
Vasanth Asokan [EMAIL PROTECTED] writes: Quoting from the description of (clobber x), ### If the last group of expressions in a parallel are each a clobber expression whose arguments are reg or match_scratch (see section 10.4 RTL Template) expressions, the combiner phase can add the appropriate clobber expressions to an insn it has constructed when doing so will cause a pattern to be matched. In this case, the combiner could not combine 46 with anything else, which is ok. The description still seems to say that the combiner can just add a clobber to the insn to cause a match with lshiftrt_internal_reg_nohwshift. It has chosen not to do so and hence the insn becomes unrecognized. Am I missing something here? This is with GCC 3.4.1. What you are missing is that the combiner will only add the appropriate clobber expressions to an insn IT HAS CONSTRUCTED (emphasis added). The combiner does not add clobbers to arbitrary instructions. Ian
[Bug rtl-optimization/18081] [3.4 regression] Infinite memory allocation on -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10 06:05 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
[Bug c/21482] New: internal compiler error (tree-ssa-operands.c:1449)
uname: Linux bkainline 2.6.11.8 #1 SMP Mon May 9 14:12:51 CEST 2005 i686 i686 i386 GNU/Linux gcc-cmd-line: if gcc -DDEFAULT_BASEDIR=\/usr\ -DDATADIR=\/var/mysql\ -DDEFAULT_CHARSET_HOME=\/usr\ -DSHAREDIR=\/usr/lib/mysql/data/mysql\ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I.-O3 -DDBUG_OFF -v -save-temps -MT default.o -MD -MP -MF .deps/default.Tpo -c -o default.o default.c; \ then mv -f .deps/default.Tpo .deps/default.Po; else rm -f .deps/default.Tpo; exit 1; fi gcc-stderr: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --prefix=/usr --with-gnu-as --with-gnu-ld --enable-threads --with-cpu=i686 --with-arch=i686 --with-tune=i686 --with-system-zlib --enable-languages=c,c++,objc,java,treelang --enable-__cxa_atexit --with-x --enable-shared --enable-nls Thread model: posix gcc version 4.0.0 /usr/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -E -quiet -v -I. -I. -I.. -I../include -I. -MD default.d -MF .deps/default.Tpo -MP -MT default.o -MQ default.o -DDEFAULT_BASEDIR=/usr -DDATADIR=/var/mysql -DDEFAULT_CHARSET_HOME=/usr -DSHAREDIR=/usr/lib/mysql/data/mysql -DHAVE_CONFIG_H -DDBUG_OFF default.c -march=i686 -O3 -fpch-preprocess -o default.i ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include ignoring duplicate directory . ignoring duplicate directory . #include ... search starts here: #include ... search starts here: . .. ../include /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/include /usr/include End of search list. /usr/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -fpreprocessed default.i -quiet -dumpbase default.c -march=i686 -auxbase-strip default.o -O3 -version -o default.s GNU C version 4.0.0 (i686-pc-linux-gnu) compiled by GNU C version 4.0.0. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129529 default.c: In function âsearch_default_file_with_extâ: default.c:346: internal compiler error: in get_indirect_ref_operands, at tree-ssa-operands.c:1449 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [default.o] Error 1 -- Summary: internal compiler error (tree-ssa-operands.c:1449) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Tobias dot Kranz at bka dot bund dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-gnu-linux GCC host triplet: i686-pc-gnu-linux GCC target triplet: i686-pc-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21482
[Bug c++/21483] New: Spurious 'control may reach end of non-void function' ... being inlined
Compiling the following code with
/home/veksler/gcc-4.0.0/bin/g++ -Wall -O2 -c bug.cpp
(Works fine with -O0 or with gcc-3.4.3)
Gives:
bug.cpp: In function 'bool foo(bar*, bar*)':
bug.cpp:19: warning: control may reach end of non-void function 'bool
bar_less::operator()(bar*, bar*)' being inlined
Which:
1. Is obviously incorrect.
2. Does not give a line number inside bar_less::operator()
-- bug.cpp ---
struct bar;
bool operator(const bar, const bar);
class bar_less
{
public:
bool operator()(bar* x, bar* y)
{
bool validX = x, validY = y;
if(validX validY)
return (*x *y);
else
return false;
}
};
bool foo(bar *x, bar *y)
{
bar_less comp;
return comp(x,y);
}
--
Summary: Spurious 'control may reach end of non-void function'
... being inlined
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: veksler at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21483
[Bug c/21482] internal compiler error (tree-ssa-operands.c:1449)
--- Additional Comments From Tobias dot Kranz at bka dot bund dot de 2005-05-10 06:24 --- Created an attachment (id=8850) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8850action=view) bzip2-packed default.i-File -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21482
[Bug libstdc++/19781] testsuite_hooks.cc doesn't test for mkfifo
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10 06:27 --- Honestly, I would have loved to have fixed this in 3.4.4, but I'm out of time. I took a quick try at it, but there were lots of patch rejects. It's certainly doable, but I'm not going to get there. So ... ... fixed in 4.0.1. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19781
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
--- Additional Comments From marcus at jet dot franken dot de 2005-05-10 06:31 --- see comment #1 ... you already derefenced the pointer in ppv (in the line unsigned long lv = *lvp; ) so the compiler assumes that anohter NULL ptr check is not needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
--- Additional Comments From chaac at nic dot fi 2005-05-10 08:00 --- Andrew, Here is a pointer to the mailing list: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479 Topic started on May 08, 2005 with subject WinAVR 20050214 (gcc 3.4.3) and optimizer bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
--- Additional Comments From chaac at nic dot fi 2005-05-10 08:06 --- In AVR's reading memory address 0 is valid thing though. In a way I can understand why to optimization in x86 but shouldn't this be disabled by default on AVR's? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
[Bug c++/21484] New: [g++] using typename doesn't work in case template : template inheritance
Is it just me or what?
===nested_defs.cpp===
templatetypename T
struct A
{
typedef T value_type;
};
templateclass T
struct B : AT
{
using typename AT::value_type;
value_type x;
};
int main()
{
Bint b;
b.x = 0;
return 0;
}
===
[EMAIL PROTECTED] tmp]$ g++ -g -c -Wall nested_defs.cpp
nested_defs.cpp:12: error: 'value_type' does not name a type
nested_defs.cpp:12: note: (perhaps 'typename AT::value_type' was intended)
nested_defs.cpp: In function 'int main()':
nested_defs.cpp:20: error: 'struct Bint' has no member named 'x'
[EMAIL PROTECTED] tmp]$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure
--prefix=/usr/local/gcc-4.0.0--nocheck-native
--with-gnu-as --with-gnu-ld --enable-threads=posix --with-arch=pentium3
--with-tune=pentium4 --enable-__cxa_atexit --enable-languages=c,c++,java,f95
--disable-checking --disable-nls
Thread model: posix
gcc version 4.0.0
With Comeau C++ Intel 8.0 C++ it is ok.
---
By the way, if i want to access all members of AT inside B, without explicit
using, typedef,
etc, what can i do?
damn, if B is not template it works
===
templatetypename T
struct A
{
typedef T value_type;
};
struct B : Aint
{
value_type x;
};
===
if A is not template it also works:
===
struct A
{
typedef int value_type;
};
templatetypename T
struct B : A
{
value_type x;
};
===
only for template : template case it doesn't compile (g++, Comeau), although
intel C++ 8.0
works ok:
===
templatetypename T
struct A
{
typedef T value_type;
};
templatetypename T
struct B : AT
{
value_type x;
};
int main()
{
Bint b;
b.x = 0;
return 0;
}
===
[EMAIL PROTECTED] tmp]$ /opt/intel_cc_80/bin/icc -c nested_defs.cpp
[EMAIL PROTECTED] tmp]$ echo $?
0
--
Summary: [g++] using typename doesn't work in case template :
template inheritance
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smelkov at mph1 dot phys dot spbu dot ru
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21484
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
--- Additional Comments From schlie at comcast dot net 2005-05-10 08:31 --- (In reply to comment #5) see comment #1 ... you already derefenced the pointer in ppv (in the line unsigned long lv = *lvp; ) so the compiler assumes that anohter NULL ptr check is not needed. - yes, however as the loigical extention of: a null reference is undefined = may trap = will trap is simply wrong, and is not justifyable; such an optimization is target specific, as it depends on will trap target semantics. (not to mention that even if it is trapped for a particular target, that the target won't simply return some value, so pointer null comparsions can't be reliably optimized away unless the compiler can also enforce dereferenced null pointer trap semantics for that particualr target, which GCC does not appear to do.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
[Bug libfortran/20788] Loading libgfortran.so clobbers C redirection of stdin/stdout/stderr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10 08:32 --- Subject: Bug 20788 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-10 08:31:50 Modified files: libgfortran: ChangeLog libgfortran/io : unix.c Log message: PR libfortran/20788 * io/unix.c (fd_to_stream): Add an avoid_mmap argument indicating we don't we to mmap this stream. Use fd_open instead of mmap_open in that case. (open_external): Call fd_to_stream with avoid_mmap = 0. (input_stream): Call fd_to_stream with avoid_mmap = 1. (output_stream): Likewise. (error_stream): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.25r2=1.163.2.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.21.10.1r2=1.21.10.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788
[Bug libfortran/20788] Loading libgfortran.so clobbers C redirection of stdin/stdout/stderr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10 08:35 --- Subject: Bug 20788 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-10 08:34:58 Modified files: libgfortran: ChangeLog libgfortran/io : read.c Log message: PR libfortran/20788 Missing entry from previous commit: * io/unix.c (fd_to_stream): Add an avoid_mmap argument indicating we don't we to mmap this stream. Use fd_open instead of mmap_open in that case. (open_external): Call fd_to_stream with avoid_mmap = 0. (input_stream): Call fd_to_stream with avoid_mmap = 1. (output_stream): Likewise. (error_stream): Likewise. Really committing: * io/read.c (read_f): Accept 'e', 'E', 'd' and 'D' as first non-blank characters of a real number. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.210r2=1.211 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gccr1=1.8r2=1.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788
[Bug libfortran/20788] Loading libgfortran.so clobbers C redirection of stdin/stdout/stderr
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-10 08:36 --- This one is fixed. Thanks for the bug report! -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
--- Additional Comments From chaac at nic dot fi 2005-05-10 08:41 --- Sorry about wrong mailing list pointer :) http://lists.gnu.org/archive/html/avr-gcc-list/2005-05/index.html Here is correct URL :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
[Bug rtl-optimization/21485] New: BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
I've found a major performance regression in gcc 4.0.0's optimization of the BYTEmark numsort benchmark. I've boiled it down to a testcase that I think will suit you... it outputs a single number representing the number of iterations run (higher is better). On my machine I get 900ish under 4.0.0 and around 1530 on 3.4.3. Both were compiled and run in a Gentoo test partition, if that makes a difference: 3.4.3: gcc version 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, pie-8.7.7) 4.0.0: gcc version 4.0.0 (Gentoo Linux 4.0.0) -- Summary: BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbucata at tulsaconnect dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From jbucata at tulsaconnect dot com 2005-05-10 09:05 --- Created an attachment (id=8851) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8851action=view) Test case (preprocessed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From jbucata at tulsaconnect dot com 2005-05-10 09:10 --- Oops, I should add that my pertinent options were: -O3 -fomit-frame-pointer -march=athlon-xp -static -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10 09:14 --- Confirmed on x86 (with and without frame pointer) and on amd64. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-10 09:14:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-10 09:27 --- mainline drops even lower - looks like poor choice of addressing modes and thus more register pressure for 4.0 and 4.1. Note that using profile-feedback improves numbers a lot (but still we regress). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug libstdc++/18604] [3.4/4.0/4.1 Regression] Use of unqualified names conflict with names in global namespace
--- Additional Comments From giovannibajo at libero dot it 2005-05-10 09:42 --- Thanks Paolo! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From giovannibajo at libero dot it 2005-05-10 09:45 --- Jason: thanks for this! Even better would be to let the testcase do a fixed number of iterations (like 1000 or so), and then we'll be using time externally to measure performance. Maybe you can do this for other testcases you are going to submit, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10
09:46 ---
This is the function (reindented) where we spend almost all of our time:
void
NumSift (long *array, unsigned long i, unsigned long j)
{
unsigned long k;
long temp;
while ((i + i) = j)
{
k = i + i;
if (k j)
if (array[k] array[k + 1L])
++k;
if (array[i] array[k])
{
temp = array[k];
array[k] = array[i];
array[i] = temp;
i = k;
}
else
i = j + 1;
}
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10 09:50 --- If Richard is right in comment #4, it would be interesting to see what happens if one tries this with Zdenek's TARGET_MEM_REF patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10 10:22 --- On AMD64 with GCC 4.0.1 (CVS 4.0 branch) I go from ~580 at -O3 to ~930 at -O3 -fno-tree-pre. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug libfortran/21471] 'POSITION = APPEND' doesn't seem to work
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-10 10:26 --- Confirmed. Library does not use this APPEND parameter. Patch here: http://gcc.gnu.org/ml/fortran/2005-05/msg00095.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2005-05/msg00095.html Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|i686-pc-linux-gnu | Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-05-10 10:26:20 date|| Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21471
[Bug c/21486] New: C Compiler does NOT signal anything when there is an increment of char * without target variable
This simple source code:
#include stdio.h
main()
{
char *p;
p+21;
return 1;
}
does NOT cause the gcc compiler to warn or signal any error. Pointer p remains
the same, before and after the 'strange' increment.
If the compiler does not signal anything about that, in a large source code it's
a very hard task to find where the problem is.
--
Summary: C Compiler does NOT signal anything when there is an
increment of char * without target variable
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frans at iunknown dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21486
[Bug c/21486] C Compiler does NOT signal anything when there is an increment of char * without target variable
--- Additional Comments From schwab at suse dot de 2005-05-10 12:04 --- $ gcc -Wall simple.c simple.c:4: warning: return type defaults to #8216;int#8217; simple.c: In function #8216;main#8217;: simple.c:7: warning: statement with no effect -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21486
[Bug c++/21487] New: new object affectation in a switch
what follows (version, command line, source and .ii) seems to be a bug.
if you need something else - [EMAIL PROTECTED]
bravo et merci quand même pour votre bon boulot !
seb.
--Command lines : -
seb$ g++ --version
g++ (GCC) 3.3.6 (Debian 1:3.3.6-4)
Copyright (C) 2003 Free Software Foundation, Inc.
Ce logiciel est libre; voir les sources pour les conditions de copie. Il n'y a
PAS
GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER.
seb$ g++ -Wall -save-temps -o test makebug.cpp
makebug.cpp: Dans function « int main(int, char**) »:
makebug.cpp:42: error: saut à l'étiquette du « case »
makebug.cpp:40: error: crosses initialization of `Thing*str'
makebug.cpp:44: error: saut à l'étiquette du « case »
makebug.cpp:40: error: crosses initialization of `Thing*str'
makebug.cpp:40: attention : unused variable `Thing*str'
-- source code: (makebug.cpp) ---
class Thing {
public:
Thing() {
}
};
int main (int argc, char ** argv){
if (argc == 1) {
return 0;
}
int truc = 0;
switch (truc) {
case 0:
break;
case 1:
Thing *th;
th = new Thing();
break;
case 2:
break;
case 3:
break;
}
switch (truc) {
case 0:
break;
case 1:
Thing *str = new Thing;
break;
case 2:
break;
case 3:
break;
}
return 0;
}
preprocessed file: (makebug.ii) ---
# 1 makebug.cpp
# 1 interne
# 1 ligne de commande
# 1 makebug.cpp
class Thing {
public:
Thing() {
}
};
int main (int argc, char ** argv){
if (argc == 1) {
return 0;
}
int truc = 0;
switch (truc) {
case 0:
break;
case 1:
Thing *th;
th = new Thing();
break;
case 2:
break;
case 3:
break;
}
switch (truc) {
case 0:
break;
case 1:
Thing *str = new Thing;
break;
case 2:
break;
case 3:
break;
}
return 0;
}
--
Summary: new object affectation in a switch
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebmaestro at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org,sebmaestro at hotmail
dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21487
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
[Bug c/21342] [4.0/4.1 Regression] some incompatible external declarations not diagnosed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10 12:38 --- Subject: Bug 21342 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-10 12:38:35 Modified files: gcc: ChangeLog c-decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: redecl-11.c redecl-12.c redecl-13.c redecl-14.c redecl-15.c Log message: PR c/21342 * c-decl.c (pushdecl): When there is a declaration in the current scope and the declarations are external linkage, check for compatibility with the type in the external scope and update the type in the external scope with the composite type information. Do not form a composite type of the new type and the visible type if they are incompatible. testsuite: * gcc.dg/redecl-11.c, gcc.dg/redecl-12.c, gcc.dg/redecl-13.c, gcc.dg/redecl-14.c, gcc.dg/redecl-15.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8703r2=2.8704 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gccr1=1.652r2=1.653 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5454r2=1.5455 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-11.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-12.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-13.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-14.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-15.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21342
[Bug c/21342] [4.0/4.1 Regression] some incompatible external declarations not diagnosed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10 12:41 --- Subject: Bug 21342 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-10 12:41:28 Modified files: gcc: ChangeLog c-decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: redecl-11.c redecl-12.c redecl-13.c redecl-14.c redecl-15.c Log message: PR c/21342 * c-decl.c (pushdecl): When there is a declaration in the current scope and the declarations are external linkage, check for compatibility with the type in the external scope and update the type in the external scope with the composite type information. Do not form a composite type of the new type and the visible type if they are incompatible. testsuite: * gcc.dg/redecl-11.c, gcc.dg/redecl-12.c, gcc.dg/redecl-13.c, gcc.dg/redecl-14.c, gcc.dg/redecl-15.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.236r2=2.7592.2.237 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.630.6.9r2=1.630.6.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.167r2=1.5084.2.168 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-11.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-12.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-13.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-14.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/redecl-15.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21342
[Bug tree-optimization/21488] New: [4.1 regression] Not copy propagating single-argument PHIs causes out-of-ssa coalescing failure
---
void bar (unsigned int);
unsigned int
foo (void)
{
unsigned int i, j;
for (i = 1; i 30; i++)
{
j = 2 + 3*i;
bar (j);
}
return j;
}
---
-- .optimized:
foo ()
{
unsigned intD.3 ivtmp.10D.1589;
unsigned intD.3 ivtmp.2D.1581;
unsigned intD.3 pretmp.1D.1580;
unsigned intD.3 pretmp.0D.1579;
unsigned intD.3 jD.1567;
unsigned intD.3 iD.1566;
unsigned intD.3 D.1572;
unsigned intD.3 D.1571;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
# SUCC: 1 [100.0%] (fallthru,exec)
# BLOCK 1
# PRED: 1 [96.5%] (dfs_back,true,exec) 0 [100.0%] (fallthru,exec)
# jD.1567_2 = PHI jD.1567_13(1), 5(0);
L0:;
bar (jD.1567_2);
jD.1567_13 = jD.1567_2 + 3;
if (jD.1567_13 != 92) goto L0; else goto L2;
# SUCC: 1 [96.5%] (dfs_back,true,exec) 2 [3.5%] (loop_exit,false,exec)
# BLOCK 2
# PRED: 1 [3.5%] (loop_exit,false,exec)
# jD.1567_3 = PHI jD.1567_2(1);
L2:;
return jD.1567_3;
# SUCC: EXIT [100.0%]
}
-- .vars
foo ()
{
unsigned intD.3 j.13D.1592;
unsigned intD.3 jD.1567;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
jD.1567 = 5;
# SUCC: 1 [100.0%] (fallthru,exec)
# BLOCK 1
# PRED: 3 [100.0%] (fallthru) 0 [100.0%] (fallthru,exec)
L0:;
bar (jD.1567);
j.13D.1592 = jD.1567 + 3;
if (j.13D.1592 != 92) goto L8; else goto L2;
# SUCC: 3 [96.5%] (dfs_back,true,exec) 2 [3.5%] (loop_exit,false,exec)
# BLOCK 3
# PRED: 1 [96.5%] (dfs_back,true,exec)
L8:;
jD.1567 = j.13D.1592;
goto bb 1 (L0);
# SUCC: 1 [100.0%] (fallthru)
# BLOCK 2
# PRED: 1 [3.5%] (loop_exit,false,exec)
L2:;
return jD.1567;
# SUCC: EXIT [100.0%]
}
Note the copy inside the loop, and the extra basic block that is needed
for it. This happens because j_2 and j_13 are not coalesced when going
out of SSA form. We never again get rid of it later on:
foo:
pushq %rbx
movl$5, %ebx
jmp .L2
.p2align 4,,7
.L7:
movl%eax, %ebx
.L2:
movl%ebx, %edi
callbar
leal3(%rbx), %eax
cmpl$92, %eax
jne .L7
movl%ebx, %eax
popq%rbx
ret
This is a regression from GCC 4.0 that is most likely to blame on the
copy propagation pass that Diego merged in from the tree-cleanup-branch.
It causes a number of performance regressions on various targets.
The bug looks somewhat similar to the issue previously discussed in
PR18048, but I haven't checked if that bug is also affected by this
problem.
--
Summary: [4.1 regression] Not copy propagating single-argument
PHIs causes out-of-ssa coalescing failure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: amacleod at redhat dot com,dnovillo at redhat dot
com,gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21488
[Bug target/21389] optimized code seg faults due to double load on sparcV9
--- Additional Comments From drew dot johnson at andrew dot com 2005-05-10 12:57 --- Subject: RE: optimized code seg faults due to double load on sparcV9 OK, I see your point. Sorry for inconvenience. I see that the status in bugzilla has been updated accordingly. Is there anything else I should do to close this? Drew -Original Message- From: ebotcazou at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Sunday, May 08, 2005 6:59 AM To: Johnson, Drew Subject: [Bug target/21389] optimized code seg faults due to double load on sparcV9 --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-08 10:58 --- Then what is the point of the -munaligned-doubles flag? Is this simply ignored? I understand your point about malloc, but what if we have casts to buffers that are not mod8-aligned? Isn't that what -munaligned-doubles is for? Excerpt from the manual: With `-munaligned-doubles', GCC assumes that doubles have 8 byte alignment only if they are contained in another type, or if they have an absolute address. Otherwise, it assumes they have 4 byte alignment. Specifying this option avoids some rare compatibility problems with code generated by other compilers. It is not the default because it results in a performance loss, especially for floating point code. So -munaligned-doubles cannot do anything for your invalid code and the bus error is to be expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. [mf2] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389
[Bug rtl-optimization/21485] BYTEmark numsort: performance regression 3.4.3 - 4.0.0 with -O3 optimization
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-10 12:58 --- Looks like a register pressure problem... but yes, TARGET_MEM_REF may help as well. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug c++/21487] new object affectation in a switch
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10 13:12 --- This is how C++ works, you can actually fall through case statements. This is invalid code and G++ rejects it correctly. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21487
