Failure in bootstrapping GFortran 4.3.0 on Cygwin
I want to flag that some changes in GCC 4.3.0 20070816 rev 127568: * Makefile.in (REVISION): New. (REVISION_c): New. (REVISION_s): New. (version.o): Also depend on $(REVISION). Add -DREVISION=$(REVISION_s). * version.c (version_string): Add REVISION. causes failure on Cygwin: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I/tmp/gcc/gcc -I/tmp/gcc/gcc/. -I/tmp/gcc/gcc/../include -I/tmp/gcc/gcc/../libcpp/include -I/tmp/gcc/gcc/../libdecnumber -I/tmp/gcc/gcc/../libdecnumber/bid -I../libdecnumber /tmp/gcc/gcc/varray.c -o varray.o gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I/tmp/gcc/gcc -I/tmp/gcc/gcc/. -I/tmp/gcc/gcc/../include -I/tmp/gcc/gcc/../libcpp/include -I/tmp/gcc/gcc/../libdecnumber -I/tmp/gcc/gcc/../libdecnumber/bid -I../libdecnumber/tmp/gcc/gcc/vec.c -o vec.o make[3]: *** No rule to make target /tmp/gcc/gcc/REVISION', needed by version.o'. Stop. make[3]: Leaving directory /tmp/gcc/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory /tmp/gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory /tmp/gcc/build' make: *** [all] Error 2 Cheers, Angelo.
Re: GCC 4.3.0 Status Report (2007-08-09)
Mark Mitchell [EMAIL PROTECTED] wrote on 09/08/2007 17:19:13: Are there any folks out there who have projects for Stage 1 or Stage 2 that they are having trouble getting reviewed? struct-reorg + ipa-type-escape changes are awaiting for response. http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00028.html http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00024.html Olga
A compensation to 'Successful Build Report for GCC 4.0.0 C and C++'
Hello: This is a compensation to Simon G. Best's build report (http://gcc.gnu.org/ml/gcc/2005-04/msg01402.html). As Simon G. Best mentioned, after final-install, gcc's shared libs should be configed as below: 1. add the line '/usr/local/lib' to the end of '/etc/ld.so.conf'; 2. run 'ldconfig' as root. But I found this is not enough. One shared lib 'libgcc_s.so.1' of installed gcc is conflict with '/lib/libgcc_s.so.1' of RedHat self contained gcc. If they are not the same version, program built with new gcc will report 'libgcc_s.so.1 version not correctly' error. It is caused by that these two libs are both configed into shared lib cache by '/sbin/ldconfig', and '/lib/libgcc_s.so.1' is always be found earier by run-time linker( '/lib' is scaned before dirs listed in '/etc/ld.so.conf' ). Solution: mv /lib/libgcc_s.so.1 '/lib/libgcc_s.so.1.bk ln -s newgccdir/lib/libgcc_s.so.1 /lib/libgcc_s.so.1 /sbin/ldconfig Hint: '/lib/libgcc_s.so.1' can not be removed, for it will be recreated by '/sbin/ldconfig' Deng Xun
Re: Very Fast: Directly Coded Lexical Analyzer
Am Freitag, 10. August 2007 schrieben Sie: To me, very fast (millions of lines a second) lexical analyzers are trivial to write by hand, and I really don't see the point of tools, and certainly not the utility of any theory in writing such code. If anything the formalism of a finite state machine just gets in the way, since it is more efficient to encode the state in the code location than in data. Well, there are people out there who don't want to write everytime the same code. Why not making your life easier with using autogeneration tools, it also reduces bugpropability. signature.asc Description: This is a digitally signed message part.
Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin
Revital1 Eres wrote: Also on ppc64. Everywhere! Paolo.
Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin
Paolo Carlini [EMAIL PROTECTED] writes: Revital1 Eres wrote: Also on ppc64. Everywhere! The file is only updated by the new config/gcc_update script, so if you update the first time it is not created. How about this: 2007-08-17 Andreas Schwab [EMAIL PROTECTED] * Makefile.in (REVISION): Only use $(srcdir)/REVISION when it exists. Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 127578) +++ gcc/Makefile.in (working copy) @@ -728,13 +728,13 @@ TM_H = $(GTM_H) insn-constants.h in BASEVER := $(srcdir)/BASE-VER # 4.x.y DEVPHASE:= $(srcdir)/DEV-PHASE # experimental, prerelease, DATESTAMP := $(srcdir)/DATESTAMP # MMDD or empty -REVISION:= $(srcdir)/REVISION # [BRANCH revision XX] +REVISION:= $(wildcard $(srcdir)/REVISION) # [BRANCH revision XX] BASEVER_c := $(shell cat $(BASEVER)) DEVPHASE_c := $(shell cat $(DEVPHASE)) DATESTAMP_c := $(shell cat $(DATESTAMP)) -ifeq (,$(wildcard $(REVISION))) +ifdef REVISION REVISION_c := else REVISION_c := $(shell cat $(REVISION)) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin
Well, at least the culprit is easy to find! 2007-08-16 H.J. Lu [EMAIL PROTECTED] * Makefile.in (REVISION): New. (REVISION_c): New. (REVISION_s): New. (version.o): Also depend on $(REVISION). Add -DREVISION=$(REVISION_s). * version.c (version_string): Add REVISION.
RE: Failure in bootstrapping GFortran 4.3.0 on Cygwin
On 17 August 2007 12:28, Andreas Schwab wrote: Paolo Carlini [EMAIL PROTECTED] writes: Revital1 Eres wrote: Also on ppc64. Everywhere! The file is only updated by the new config/gcc_update script, so if you update the first time it is not created. How about this: DATESTAMP := $(srcdir)/DATESTAMP # MMDD or empty -REVISION:= $(srcdir)/REVISION # [BRANCH revision XX] +REVISION:= $(wildcard $(srcdir)/REVISION) # [BRANCH revision XX] BASEVER_c := $(shell cat $(BASEVER)) DEVPHASE_c := $(shell cat $(DEVPHASE)) DATESTAMP_c := $(shell cat $(DATESTAMP)) -ifeq (,$(wildcard $(REVISION))) +ifdef REVISION REVISION_c := else REVISION_c := $(shell cat $(REVISION)) I'm not clear about this, are we allowed to use gnu-specific features like $(wildcard ...) in this makefile? cheers, DaveK -- Can't think of a witty .sigline today
Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin
Dave Korn [EMAIL PROTECTED] writes: I'm not clear about this, are we allowed to use gnu-specific features like $(wildcard ...) in this makefile? Yes. @item GNU make version 3.79.1 (or later) You must have GNU make installed to build [EMAIL PROTECTED] Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: [RFC] Migrate pointers to members to the middle end
On 8/9/07, Ollie Wild [EMAIL PROTECTED] wrote: On 8/8/07, Daniel Berlin [EMAIL PROTECTED] wrote: I also haven't necessarily said what Ollie has proposed is a bad idea. I have simply said the way he has come up with what he proposed is not the way we should go about this. It may turn out he has come up with exactly the representation we want (though I doubt this, for various reasons).The specification given also doesn't even explain where/how these operations can occur in GIMPLE, and what they do other than a C++ something something. Also given that someone already wrote a type-based devirtualizer that worked fine, and i don't see how a points-to one is much work, I'd like to see more justification for things like PTRMEM_PLUS_EXPR than hey, the C++ FE generates this internally. OK. It sounds like I need to go into a lot more detail. The new nodes I've proposed aren't actually motivated by the C++ front end, but rather by a consideration of the semantics dictated by the C++ standard. Naturally, this gives rise to some similarity, but for instance, there is no PTRMEM_PLUS_EXPR in the C++ front end, and my definition of PTRMEM_CST disagrees with the current node of the same name. Let's walk through them: [...] Just to throw in something late from the side. Can you try to model things in such a way that representing TLS accesses on the tree level would be possible with whatever new infrastructure you come up with? (It's the only thing we keep libcalls for if I remember correctly) Thx, Richard.
Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin
On Fri, Aug 17, 2007 at 01:27:39PM +0200, Andreas Schwab wrote: Paolo Carlini [EMAIL PROTECTED] writes: Revital1 Eres wrote: Also on ppc64. Everywhere! The file is only updated by the new config/gcc_update script, so if you update the first time it is not created. How about this: 2007-08-17 Andreas Schwab [EMAIL PROTECTED] * Makefile.in (REVISION): Only use $(srcdir)/REVISION when it exists. I checked in a dfferent fix. But this version should work also. I have no objection to replace my fix with this one. H.J.
Re: i seem to have hit a problem with my new conflict finder.
Kenneth Zadeck [EMAIL PROTECTED] writes: There are a lot of ways to handle this problem: 1) We could do a pass that breaks multiword sets into individual regs if some of those regs are dead. I guess the downside of this is that such insns may not match some patterns anymore. 2) We could turn off local. I was planning on testing this anyway because i want to see if local, at this point, is just making global do a bad job. However, my hope is that global or the new allocator from vlad is smart enough to properly handle the case where some parts of a multiword set are dead. 3) We could fix global/reload to not be stupid. Because, of course, you should be able to put something in that unused regs slot. Any comments. I think the first step is to figure out what is going wrong. I don't see any obvious reason why global or reload should fail in this way, as long as the multi-word set is properly marked as such at the point of the set itself. Ian
Re: i seem to have hit a problem with my new conflict finder.
Kenneth Zadeck wrote: it looks like the backwards scan is not getting enough interferences to make reload/global happy. the case comes about because of way local_alloc is preassigning regs for pseudos that would map into more than 1 hardreg. pseudo's are as wide as they need to be. When local_alloc assigns one of these to a hard reg, it assigns it to the first hardreg needed and the mode is used to indicate how many of the following regs are needed. The problem comes where you have a store that uses 2 or more hard regs but one or more of those hardregs is unused. In a forwards scan, ALL of the set regs will interfere with anything live until the last set reg goes dead. In a backwards scan, the unused hard regs never cause interferences. global/reload wants these interferences. This is, of course, one of the reasons that backward scanning the proper way to build an interference graph. But something in global or reload cannot handle the truth. There are a lot of ways to handle this problem: 1) We could do a pass that breaks multiword sets into individual regs if some of those regs are dead. I guess the downside of this is that such insns may not match some patterns anymore. May be it is right thing to do in long perspective but I think it is too complicated to implement it working. 2) We could turn off local. I was planning on testing this anyway because i want to see if local, at this point, is just making global do a bad job. However, my hope is that global or the new allocator from vlad is smart enough to properly handle the case where some parts of a multiword set are dead. The local has very important part update_equiv_regs. Without it you will have a serious performance degradation. As for IRA I started work on using df-infrastructure for it. I am not going to use UREC or LIVE at least at first time. I'll use LR as it was in IRA before the df-infrastructure. IRA also uses forward scan for building conflicts. After making df-infrastructure working in IRA, I should think about using LIVE or backward scan but right now I am not sure that will give an improvement worth to use it. 3) We could fix global/reload to not be stupid. Because, of course, you should be able to put something in that unused regs slot. Any comments. Thanks for asking. Taking into account the implementation problems I am not sure that the backward scan is worth to implement in gcc. May be I am wrong. Only the practice (the perfomance and compile time improvements) could say that.
Re: i seem to have hit a problem with my new conflict finder.
Vladimir N. Makarov wrote: Kenneth Zadeck wrote: it looks like the backwards scan is not getting enough interferences to make reload/global happy. the case comes about because of way local_alloc is preassigning regs for pseudos that would map into more than 1 hardreg. pseudo's are as wide as they need to be. When local_alloc assigns one of these to a hard reg, it assigns it to the first hardreg needed and the mode is used to indicate how many of the following regs are needed. The problem comes where you have a store that uses 2 or more hard regs but one or more of those hardregs is unused. In a forwards scan, ALL of the set regs will interfere with anything live until the last set reg goes dead. In a backwards scan, the unused hard regs never cause interferences. global/reload wants these interferences. This is, of course, one of the reasons that backward scanning the proper way to build an interference graph. But something in global or reload cannot handle the truth. There are a lot of ways to handle this problem: 1) We could do a pass that breaks multiword sets into individual regs if some of those regs are dead. I guess the downside of this is that such insns may not match some patterns anymore. May be it is right thing to do in long perspective but I think it is too complicated to implement it working. 2) We could turn off local. I was planning on testing this anyway because i want to see if local, at this point, is just making global do a bad job. However, my hope is that global or the new allocator from vlad is smart enough to properly handle the case where some parts of a multiword set are dead. The local has very important part update_equiv_regs. Without it you will have a serious performance degradation. I understand that, but the actual local assignment is the part that gets in the way of both this and the rest of allocation. I was going to leave that part and just turn off the local assignment. As for IRA I started work on using df-infrastructure for it. I am not going to use UREC or LIVE at least at first time. I'll use LR as it was in IRA before the df-infrastructure. IRA also uses forward scan for building conflicts. After making df-infrastructure working in IRA, I should think about using LIVE or backward scan but right now I am not sure that will give an improvement worth to use it. The reason that i was doing this now was because i thought we might get some gain from it and that it is nonorthogonal to what you were doing with IRA. I would actually assume that you could just drop this code in. This was what we talked about doing at the bad Indian restaurant at the summit. My main goal here was to get rid of urec, since it produces stupid information for use with early clobbers and it is very slow. My enclosed patch should be a lot faster. 3) We could fix global/reload to not be stupid. Because, of course, you should be able to put something in that unused regs slot. Any comments. Thanks for asking. Taking into account the implementation problems I am not sure that the backward scan is worth to implement in gcc. May be I am wrong. Only the practice (the perfomance and compile time improvements) could say that.
Re: i seem to have hit a problem with my new conflict finder.
Kenneth Zadeck wrote: Vladimir N. Makarov wrote: Kenneth Zadeck wrote: it looks like the backwards scan is not getting enough interferences to make reload/global happy. the case comes about because of way local_alloc is preassigning regs for pseudos that would map into more than 1 hardreg. pseudo's are as wide as they need to be. When local_alloc assigns one of these to a hard reg, it assigns it to the first hardreg needed and the mode is used to indicate how many of the following regs are needed. The problem comes where you have a store that uses 2 or more hard regs but one or more of those hardregs is unused. In a forwards scan, ALL of the set regs will interfere with anything live until the last set reg goes dead. In a backwards scan, the unused hard regs never cause interferences. global/reload wants these interferences. This is, of course, one of the reasons that backward scanning the proper way to build an interference graph. But something in global or reload cannot handle the truth. There are a lot of ways to handle this problem: 1) We could do a pass that breaks multiword sets into individual regs if some of those regs are dead. I guess the downside of this is that such insns may not match some patterns anymore. May be it is right thing to do in long perspective but I think it is too complicated to implement it working. 2) We could turn off local. I was planning on testing this anyway because i want to see if local, at this point, is just making global do a bad job. However, my hope is that global or the new allocator from vlad is smart enough to properly handle the case where some parts of a multiword set are dead. The local has very important part update_equiv_regs. Without it you will have a serious performance degradation. I understand that, but the actual local assignment is the part that gets in the way of both this and the rest of allocation. I was going to leave that part and just turn off the local assignment. As for IRA I started work on using df-infrastructure for it. I am not going to use UREC or LIVE at least at first time. I'll use LR as it was in IRA before the df-infrastructure. IRA also uses forward scan for building conflicts. After making df-infrastructure working in IRA, I should think about using LIVE or backward scan but right now I am not sure that will give an improvement worth to use it. The reason that i was doing this now was because i thought we might get some gain from it and that it is nonorthogonal to what you were doing with IRA. I would actually assume that you could just drop this code in. This was what we talked about doing at the bad Indian restaurant at the summit. Yes, Ken. I remember that talk. Probably I was not clear. I meant that we could use LR instead of UREC or LIVE again. I introduced usage of accurate live analysis (analog of UREC/LIVE). It gave 0.5% improvement on SPEC95 but creates a lot of problems. I should acknowledge that probably the introducing accurate live analysis was my mistake. I found that we need LIVE now because it is used in some optimizations like initialization of uninitialized regs. So just getting rid off only UREC will be good too. It might give some gain. In any case IRA can not use UREC because UREC is needed before IRA calculates reg class info and the reg class info is needed for calculation of UREC. If you manage to use LIVE instead of UREC, it would permit to use LIVE also in IRA instead of LR. But I can not say can we use LIVE instead of UREC because I don't know the df-infrastructure well yet.
Re: i seem to have hit a problem with my new conflict finder.
Vladimir N. Makarov wrote: Kenneth Zadeck wrote: Vladimir N. Makarov wrote: Kenneth Zadeck wrote: it looks like the backwards scan is not getting enough interferences to make reload/global happy. the case comes about because of way local_alloc is preassigning regs for pseudos that would map into more than 1 hardreg. pseudo's are as wide as they need to be. When local_alloc assigns one of these to a hard reg, it assigns it to the first hardreg needed and the mode is used to indicate how many of the following regs are needed. The problem comes where you have a store that uses 2 or more hard regs but one or more of those hardregs is unused. In a forwards scan, ALL of the set regs will interfere with anything live until the last set reg goes dead. In a backwards scan, the unused hard regs never cause interferences. global/reload wants these interferences. This is, of course, one of the reasons that backward scanning the proper way to build an interference graph. But something in global or reload cannot handle the truth. There are a lot of ways to handle this problem: 1) We could do a pass that breaks multiword sets into individual regs if some of those regs are dead. I guess the downside of this is that such insns may not match some patterns anymore. May be it is right thing to do in long perspective but I think it is too complicated to implement it working. 2) We could turn off local. I was planning on testing this anyway because i want to see if local, at this point, is just making global do a bad job. However, my hope is that global or the new allocator from vlad is smart enough to properly handle the case where some parts of a multiword set are dead. The local has very important part update_equiv_regs. Without it you will have a serious performance degradation. I understand that, but the actual local assignment is the part that gets in the way of both this and the rest of allocation. I was going to leave that part and just turn off the local assignment. As for IRA I started work on using df-infrastructure for it. I am not going to use UREC or LIVE at least at first time. I'll use LR as it was in IRA before the df-infrastructure. IRA also uses forward scan for building conflicts. After making df-infrastructure working in IRA, I should think about using LIVE or backward scan but right now I am not sure that will give an improvement worth to use it. The reason that i was doing this now was because i thought we might get some gain from it and that it is nonorthogonal to what you were doing with IRA. I would actually assume that you could just drop this code in. This was what we talked about doing at the bad Indian restaurant at the summit. Yes, Ken. I remember that talk. Probably I was not clear. I meant that we could use LR instead of UREC or LIVE again. I introduced usage of accurate live analysis (analog of UREC/LIVE). It gave 0.5% improvement on SPEC95 but creates a lot of problems. I should acknowledge that probably the introducing accurate live analysis was my mistake. I found that we need LIVE now because it is used in some optimizations like initialization of uninitialized regs. So just getting rid off only UREC will be good too. It might give some gain. In any case IRA can not use UREC because UREC is needed before IRA calculates reg class info and the reg class info is needed for calculation of UREC. If you manage to use LIVE instead of UREC, it would permit to use LIVE also in IRA instead of LR. But I can not say can we use LIVE instead of UREC because I don't know the df-infrastructure well yet. we should talk. I am avail today. i am leaving on vacation tomorrow for a week. Even if this patch does not get in this round, you should consider it as a starting point for building the interference graph for ira. it does not use urec and a big part of the patch is just getting rid of urec, It does a backwards scan using the live at bottom set as the starting point for the scan. This is the most accurate you can get so there really is no reason not to use it since it is also no more expensive than any weaker technique. The biggest difference is what is done with the early clobbers. The biggest thing that i objected to with the make accurate live analysis was it marking the early clobber as being live from the beginning of the block. This patch just adds interferences from the early clobber output to the inputs that die within the insn and could be in the same class. Kenny
Re: ICE on valid code, cse related
On Wed, Aug 01, 2007 at 08:53:53PM +0530, Pranav Bhandarkar wrote: internal compiler error: RTL check: expected code 'const_double' and mode 'VOID', have code 'const_double' and mode 'SF' in plus_constant, at explow.c:103 [snip] Regret the rather verbose post. It is not verbose enough. Please post a testcase. -- Rask Ingemann lambertsen
Re: i seem to have hit a problem with my new conflict finder.
On Fri, 2007-08-17 at 12:01 -0400, Kenneth Zadeck wrote: In any case IRA can not use UREC because UREC is needed before IRA calculates reg class info and the reg class info is needed for calculation of UREC. If you manage to use LIVE instead of UREC, it would permit to use LIVE also in IRA instead of LR. But I can not say can we use LIVE instead of UREC because I don't know the df-infrastructure well yet. we should talk. I am avail today. i am leaving on vacation tomorrow for a week. Even if this patch does not get in this round, you should consider it as a starting point for building the interference graph for ira. it does not use urec and a big part of the patch is just getting rid of urec, It does a backwards scan using the live at bottom set as the starting point for the scan. This is the most accurate you can get so there really is no reason not to use it since it is also no more expensive than any weaker technique. It is the standard way of doing things. Out-Of-SSA has always used live range info from the bottom up for its conflict graph. I'm marginally suprised it is calculated any other way... Andrew
Re: ICE on valid code, cse related
On Thu, Aug 09, 2007 at 01:32:02PM +0100, Dave Korn wrote: On 09 August 2007 13:25, Rask Ingemann Lambertsen wrote: All examples so far have had CONST_DOUBLE in the REG_EQUAL note. Yes, and? I don't see what you're getting at here. Not necessarily a whole lot, but it's the only thing to look for without a testcase and CONST_DOUBLE handling was broken in the past, which resulted in the RTL checks that are now being tripped again. If you look at the ia16 back end I posted, you'll notice that it only implements movXX for modes of 16 bits or less and AFAIK does not suffer from the CSE bug. It maybe latent for other reasons, or you may not have triggered it yet, but I wonder what kind of REG_EQUAL notes do you get when you start passing 32- (or even 64-) bit values around in 16-bit registers? Pretty difficult to say without a test case, isn't it? The only mention of any such thing is gcc.c-torture/execute/2717-2.c[1], but that was in the GCC 3.3 days. These days, the tree optimizers have already optimized the testcase away before RTL generation happens. What happened to the experiments you described at URL:http://gcc.gnu.org/ml/gcc/2004-06/msg01178.html? Emitting a no-op move of the (set (reg) (reg)) form won't work, but maybe something like (insn (use (reg) (expr_list:REG_EQUAL ...))) would work? [1] http://gcc.gnu.org/ml/gcc/2003-04/msg01397.html -- Rask Ingemann Lambertsen
Re: i seem to have hit a problem with my new conflict finder.
Andrew MacLeod wrote: On Fri, 2007-08-17 at 12:01 -0400, Kenneth Zadeck wrote: In any case IRA can not use UREC because UREC is needed before IRA calculates reg class info and the reg class info is needed for calculation of UREC. If you manage to use LIVE instead of UREC, it would permit to use LIVE also in IRA instead of LR. But I can not say can we use LIVE instead of UREC because I don't know the df-infrastructure well yet. we should talk. I am avail today. i am leaving on vacation tomorrow for a week. Even if this patch does not get in this round, you should consider it as a starting point for building the interference graph for ira. it does not use urec and a big part of the patch is just getting rid of urec, It does a backwards scan using the live at bottom set as the starting point for the scan. This is the most accurate you can get so there really is no reason not to use it since it is also no more expensive than any weaker technique. It is the standard way of doing things. Out-Of-SSA has always used live range info from the bottom up for its conflict graph. I'm marginally suprised it is calculated any other way... Andrew this is gcc, get a life. bottom up is the way i was taught when i was a small child playing with compilers with training wheels. Gcc always seemed weird because you need reg_dead and reg_unused notes. Note that my patch does not use reg_dead or unused notes. kenny
RE: ICE on valid code, cse related
On 17 August 2007 17:02, 'Rask Ingemann Lambertsen' wrote: What happened to the experiments you described at URL:http://gcc.gnu.org/ml/gcc/2004-06/msg01178.html? Emitting a no-op move of the (set (reg) (reg)) form won't work, but maybe something like (insn (use (reg) (expr_list:REG_EQUAL ...))) would work? Hard to remember all that far back, but off the top of my head I think I did indeed discover that emitting the no-op move didn't help, couldn't figure out why nor what to try instead, and let it drop because I had other pressures on my working hours and implementing movdi was a good enough workaround for my purposes at the time. Maybe I'll get a chance to give it another go, this time with your suggestion, because I'm sure the compiler does generate incorrect RTL in this case and it would be worth trying to correct it and see what difference that makes. cheers, DaveK -- Can't think of a witty .sigline today
Re: i seem to have hit a problem with my new conflict finder.
Seongbae Park (???, ???) wrote: On 8/17/07, Kenneth Zadeck [EMAIL PROTECTED] wrote: ... we should talk. I am avail today. i am leaving on vacation tomorrow for a week. Please send me the patch before you leave (and please leave valinor turned on) - I'll give a look while you're gone. Valinor will stay on. the patch was in the first posting. I am testing it now with local_alloc turned off. kenny
Re: i seem to have hit a problem with my new conflict finder.
On Fri, 2007-08-17 at 09:32 -0400, Kenneth Zadeck wrote: The problem comes where you have a store that uses 2 or more hard regs but one or more of those hardregs is unused. In a forwards scan, ALL of the set regs will interfere with anything live until the last set reg goes dead. In a backwards scan, the unused hard regs never cause interferences. global/reload wants these interferences. Can you cut/paste the problematic RTL here? I'm having a hard time seeing what your problem is since store's (excluding store with update insns) don't have any set regs, so we shouldn't get any inferences for store insns. 2) We could turn off local. I was planning on testing this anyway because i want to see if local, at this point, is just making global do a bad job. However, my hope is that global or the new allocator from vlad is smart enough to properly handle the case where some parts of a multiword set are dead. Offline, I gave Kenny a patch to disable local_alloc. I'm appending it here for posterity. Peter Index: opts.c === --- opts.c (revision 127398) +++ opts.c (working copy) @@ -895,6 +895,8 @@ decode_options (unsigned int argc, const set_param_value (min-crossjump-insns, 1); } + flag_local_alloc = 1; + /* Initialize whether `char' is signed. */ flag_signed_char = DEFAULT_SIGNED_CHAR; /* Set this to a special uninitialized value. The actual default is set Index: local-alloc.c === --- local-alloc.c (revision 127398) +++ local-alloc.c (working copy) @@ -363,6 +363,9 @@ local_alloc (void) registers. */ update_equiv_regs (); + if (! flag_local_alloc) +return recorded_label_ref; + /* This sets the maximum number of quantities we can have. Quantity numbers start at zero and we can have one for each pseudo. */ max_qty = (max_regno - FIRST_PSEUDO_REGISTER); Index: common.opt === --- common.opt (revision 127398) +++ common.opt (working copy) @@ -628,6 +628,10 @@ fleading-underscore Common Report Var(flag_leading_underscore) Init(-1) Give external symbols a leading underscore +flocal-alloc +Common Report Var(flag_local_alloc) +Perform local register allocation + floop-optimize Common Does nothing. Preserved for backward compatibility.
Re: i seem to have hit a problem with my new conflict finder.
Kenneth Zadeck wrote: Vladimir N. Makarov wrote: Kenneth Zadeck wrote: Vladimir N. Makarov wrote: Kenneth Zadeck wrote: it looks like the backwards scan is not getting enough interferences to make reload/global happy. the case comes about because of way local_alloc is preassigning regs for pseudos that would map into more than 1 hardreg. pseudo's are as wide as they need to be. When local_alloc assigns one of these to a hard reg, it assigns it to the first hardreg needed and the mode is used to indicate how many of the following regs are needed. The problem comes where you have a store that uses 2 or more hard regs but one or more of those hardregs is unused. In a forwards scan, ALL of the set regs will interfere with anything live until the last set reg goes dead. In a backwards scan, the unused hard regs never cause interferences. global/reload wants these interferences. This is, of course, one of the reasons that backward scanning the proper way to build an interference graph. But something in global or reload cannot handle the truth. There are a lot of ways to handle this problem: 1) We could do a pass that breaks multiword sets into individual regs if some of those regs are dead. I guess the downside of this is that such insns may not match some patterns anymore. May be it is right thing to do in long perspective but I think it is too complicated to implement it working. 2) We could turn off local. I was planning on testing this anyway because i want to see if local, at this point, is just making global do a bad job. However, my hope is that global or the new allocator from vlad is smart enough to properly handle the case where some parts of a multiword set are dead. The local has very important part update_equiv_regs. Without it you will have a serious performance degradation. I understand that, but the actual local assignment is the part that gets in the way of both this and the rest of allocation. I was going to leave that part and just turn off the local assignment. As for IRA I started work on using df-infrastructure for it. I am not going to use UREC or LIVE at least at first time. I'll use LR as it was in IRA before the df-infrastructure. IRA also uses forward scan for building conflicts. After making df-infrastructure working in IRA, I should think about using LIVE or backward scan but right now I am not sure that will give an improvement worth to use it. The reason that i was doing this now was because i thought we might get some gain from it and that it is nonorthogonal to what you were doing with IRA. I would actually assume that you could just drop this code in. This was what we talked about doing at the bad Indian restaurant at the summit. Yes, Ken. I remember that talk. Probably I was not clear. I meant that we could use LR instead of UREC or LIVE again. I introduced usage of accurate live analysis (analog of UREC/LIVE). It gave 0.5% improvement on SPEC95 but creates a lot of problems. I should acknowledge that probably the introducing accurate live analysis was my mistake. I found that we need LIVE now because it is used in some optimizations like initialization of uninitialized regs. So just getting rid off only UREC will be good too. It might give some gain. In any case IRA can not use UREC because UREC is needed before IRA calculates reg class info and the reg class info is needed for calculation of UREC. If you manage to use LIVE instead of UREC, it would permit to use LIVE also in IRA instead of LR. But I can not say can we use LIVE instead of UREC because I don't know the df-infrastructure well yet. we should talk. I am avail today. i am leaving on vacation tomorrow for a week. I am on vacation next week too. I'll be back Aug 29. We could talk at the end of August. Even if this patch does not get in this round, you should consider it as a starting point for building the interference graph for ira. Yes, As I wrote I'll look at this when ira with the df-infrastracture will start to work. Backward scan usage could be the next step. it does not use urec and a big part of the patch is just getting rid of urec, It does a backwards scan using the live at bottom set as the starting point for the scan. This is the most accurate you can get so there really is no reason not to use it since it is also no more expensive than any weaker technique. Yes I know that the bottom up scan is used in all compiler books because you don't need notes like REG_DEAD. What gcc does is very unusual. Although I don't see a big difference between forward and backward scan if there are notes. It would be nice to remove the notes at all but it is more complicated than just removing it in building conflict graph because it is used in the reload too. The biggest difference is what is done with the early
Why is building a cross compiler out-of-the-box always broken?
Hello all,
Several years ago in the gcc 3.3 time frame I looked into building cross
compilers using the current versions of gcc, glibc etc. for a number of
different systems. I quickly found that it was a quagmire. I inquired
of this list at that time and was told that the glibc hack was
problematic and that things would not be fixed in gcc 3.4 but might get
better by gcc 3.5 (which eventually became gcc 4.0). I worked around my
need at that time and went on to other things. Recently out of
curiosity I dug out the problem and took another look. Except for the
fact that the Linux kernel build system now supports headers_install to
provide a reliable set of sanitized header, not much seems to have
changed. I realize that there are various solutions for specific
platforms. Dan Kegel's excellent crosstool and the cross-lfs website,
for example, are testaments to the people who have labored to circumvent
this problem. However, the question remains, why is the problem still
there to be circumvented? Is there some secret opposition to easy use
of these tools, is there some law of nature that prevents them from
building, is there some good technical reason that is hard to implement,
or has it just not been a big enough pain for anyone to beat it into
submission? As it stands currently, it looks like gcc needs both the
kernel (for unwind support) and glibc (for generic C reasons) headers
*for the target* to build a cross compiler for that target, but glibc
needs a functioning cross compiler for that target before it will even
configure so you can try to make install-headers. Mean while, back at
the ranch, the inhibit_libc hack does not seem to be implemented
everywhere needed for a successful build and the gcc configure seems to
have a curious need for the --with-newlib flag to really mean we want
inhibit_libc as well as handling with_sysroot and with_headers rather
differently. (See the fragment below from gcc 4.2.1) As an aside, I
suspect that there are subtle assumptions that the build/host glibc
headers are the same as the target glibc headers in some respects. Way
back, I was trying to cross compile on Solaris using a complete self
hosting gnu tool chain and I saw some very strange failure. In the
current experiment I am using a more-or-less up to date Linux system,
but if/when building a cross compiler works I could resurrect the
Solaris test environment to check for portability issues of that type.
For now I'm just looking at current Linux build/host/targets.
So, my open questions to the list are, what is/should be the preferred
way to bootstrap a cross compiler/glibc environment?
What needed to be done to get there from here? Does the inhibit_libc
hack need to be extended, ripped out and replaced, or just better
documented? I will follow this discussion on the gcc mailing list
archive since I'm not subscribed, but I'm willing to test stuff if
anyone wants me to. Or, if it really does work currently and I'm just
an idiot, could some kind soul hit me with a clue-bat and point me to a
descriptions of the solution.
# inhibit_libc
# If this is using newlib, without having the headers available now,
# then define inhibit_libc in LIBGCC2_CFLAGS.
# This prevents libgcc2 from containing any code which requires libc
# support.
inhibit_libc=false
if { { test x$host != x$target test x$with_sysroot = x ; } ||
test x$with_newlib = xyes ; }
{ test x$with_headers = x || test x$with_headers = xno ; } ; then
inhibit_libc=true
fi
Thanks - Steve
Re: Why is building a cross compiler out-of-the-box always broken?
On 8/17/07, Stephen M. Kenton [EMAIL PROTECTED] wrote: Cross compiling works for me out of the box if done correctly. Yes I have to compile GCC and glibc (or newlib) twice but I don't care as it is all scripted. Thanks, Andrew Pinski
Re: Why is building a cross compiler out-of-the-box always broken?
Stephen M. Kenton wrote: Hello all, . . . I realize that there are various solutions for specific platforms. Dan Kegel's excellent crosstool and the cross-lfs website, . . . So, my open questions to the list are, what is/should be the preferred way to bootstrap a cross compiler/glibc environment? Don't bootstrap. Use one of Kegal's crosstool or the cross-lfs instructions exactly once. Then keep a good build of glibc around for future build cycles. That way you never bootstrap. You just build a cross compiler in the standard manner, which *always* works. David Daney
Re: Why is building a cross compiler out-of-the-box always broken?
Stephen M. Kenton [EMAIL PROTECTED] writes: However, the question remains, why is the problem still there to be circumvented? Is there some secret opposition to easy use of these tools, is there some law of nature that prevents them from building, is there some good technical reason that is hard to implement, or has it just not been a big enough pain for anyone to beat it into submission? The central problem is that gcc, binutils, glibc, and the kernel are all separate projects which are distributed and maintained separately by different people. Thus there are mismatches and confusions and difficulties which result from the different release cycles and different agendas. Thus there is a place in the ecosystem for people to write the scripts needed to smooth over those differences. And indeed that ecosystem is filled by tools like crosstool and buildtool. This is certainly not ideal. But the organizational differences make it quite difficult to fix in any other way. Ian
Re: Why is building a cross compiler out-of-the-box always broken?
Andrew Pinski wrote: On 8/17/07, Stephen M. Kenton [EMAIL PROTECTED] wrote: Cross compiling works for me out of the box if done correctly. Yes I have to compile GCC and glibc (or newlib) twice but I don't care as it is all scripted. Thanks, Andrew Pinski Great! Scripting is wonderful and I don't object to multiple cycles either. Care to hit me with a clue-bat and post your script so I can find what I did wrong? It sound's like other people have out-of-the-box problems too. I'll patch my scripts and turn them loose on ~20 tool chain builds. Steve
Re: STL vector::resize
John L. Kulp wrote: Shouldn't the last (optional) argument be (1) const and (2) a reference (rather than a potentially very expensive copying call-by-value)? Among other things, if you have a type declared with alignment attributes, it will fail on this. I notice the MSVC implementation has (1) but not (2). I can't see any code that would depend on the value being copied. The standard specifies the signature. Making it const doesn't change the signature, so that's conforming, but doesn't avoid the copy. Making it a reference would be non-conforming. If copy constructions are very expensive then maybe storing the types in std::vector directly isn't a good idea. You could store them by (smart) pointer instead, or just use capacity and push_back instead of resize. Calling resize(n) could result in n copy constructions, so one more for the parameter isn't going to matter in many cases. If you remain unconvinced you might want to take the thread to [EMAIL PROTECTED] rather than this list, but I'm certain noone will change that signature while the standard says it passes by value. Jon
gcc-4.3-20070817 is now available
Snapshot gcc-4.3-20070817 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070817/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 127603 You'll find: gcc-4.3-20070817.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070817.tar.bz2 C front end and core compiler gcc-ada-4.3-20070817.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070817.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070817.tar.bz2 C++ front end and runtime gcc-java-4.3-20070817.tar.bz2 Java front end and runtime gcc-objc-4.3-20070817.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070817.tar.bz2The GCC testsuite Diffs from 4.3-20070810 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
gcc.dg/sms-antideps.c fails on IA64 (modulo scheduling problem)
I noticed that gcc.dg/sms-antideps.c is failing on my IA64 Linux and HP-UX platforms. The failure is: x.c: In function 'foo': x.c:25: internal compiler error: in gen_sub2_insn, at optabs.c:4640 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. When I enter gen_sub2_insn the operands I have are: (reg:DI 332 ar.lc) and (const_int 0 [0x0]) It is generate_prolog_epilog (called by sms_schedule) in modulo-sched.c that is trying to generate this subtract. First off: why am I subracting zero? Shouldn't generate_prolog_epilog skip the subtraction if last_stage is zero? I wind up dying because count_reg in this case is ar.lc (application register, loop counter) and this register on the IA64 does not allow the subtraction operation on it. All I can do with this register is to do a move into it to initialize it and then use and decrement it in counted loops (the doloop_end insn). How do I explain to the modulo scheduler that it cannot do this optimization? Not doing the subtract when last_stage is zero might make this one test case work but it would leave open the larger problem of possibly generating a subtract instruction on a register (count_reg) that does not allow that operation. Ideas or advise (or patches)? Steve Ellcey [EMAIL PROTECTED]
Re: gcc.dg/sms-antideps.c fails on IA64 (modulo scheduling problem)
Steve Ellcey [EMAIL PROTECTED] writes: I noticed that gcc.dg/sms-antideps.c is failing on my IA64 Linux and HP-UX platforms. The failure is: x.c: In function 'foo': x.c:25: internal compiler error: in gen_sub2_insn, at optabs.c:4640 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. When I enter gen_sub2_insn the operands I have are: (reg:DI 332 ar.lc) and (const_int 0 [0x0]) It is generate_prolog_epilog (called by sms_schedule) in modulo-sched.c that is trying to generate this subtract. First off: why am I subracting zero? Shouldn't generate_prolog_epilog skip the subtraction if last_stage is zero? I wind up dying because count_reg in this case is ar.lc (application register, loop counter) and this register on the IA64 does not allow the subtraction operation on it. All I can do with this register is to do a move into it to initialize it and then use and decrement it in counted loops (the doloop_end insn). How do I explain to the modulo scheduler that it cannot do this optimization? Not doing the subtract when last_stage is zero might make this one test case work but it would leave open the larger problem of possibly generating a subtract instruction on a register (count_reg) that does not allow that operation. I think the modulo scheduler code is making some bad assumptions about the doloop pattern. The doloop insn is permitted to be special, and the register it uses is permitted to be special. Ian
Re: gcc.dg/sms-antideps.c fails on IA64 (modulo scheduling problem)
[EMAIL PROTECTED] wrote on 18/08/2007 03:19:48: I noticed that gcc.dg/sms-antideps.c is failing on my IA64 Linux and HP-UX platforms. The failure is: x.c: In function 'foo': x.c:25: internal compiler error: in gen_sub2_insn, at optabs.c:4640 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. When I enter gen_sub2_insn the operands I have are: (reg:DI 332 ar.lc) and (const_int 0 [0x0]) Andrey already brought that problem to our attention; please see - http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01010.html; It will be addressed in the next patch. Thank, Revital
[Bug fortran/33095] New: MAX with optional arguments gives run-time error
This is a fallout from PR31198. Using a = MAX(1,2, a1, a2) where a1 and a2 are optional arguments: If both a1 and a2 are not present, gfortran gives a bogus run-time error message: Fortran runtime error: Second argument of 'max' intrinsic should be present Looking at the dump, gfortran optimized the second argument away: MAX(2,a1,a2) if a1 is now not present ... Fortran 2003: 13.7.71 MAX (A1, A2 [, A3, ...]) 13.7.76 MIN (A1, A2 [, A3, ...]) Fortran 95: 13.14.64 MAX (A1, A2 [, A3, ...]) 13.14.69 MIN (A1, A2 [, A3, ...]) See also: http://groups.google.com/group/comp.lang.fortran/msg/be6db97903228689 Test case (from c.l.f): PROGRAM testoptarg PRINT *, m1(3,4) PRINT *, m1(3) PRINT *, m1() ! gives the run-time error CONTAINS INTEGER FUNCTION m1(a1,a2) INTEGER, OPTIONAL, INTENT(IN) :: a1,a2 m1 = max(1, 2, a1, a2) END FUNCTION m1 END PROGRAM testoptarg -- Summary: MAX with optional arguments gives run-time error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33095
[Bug middle-end/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #9 from bje at gcc dot gnu dot org 2007-08-17 06:49 --- Fixed in r127578. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug rtl-optimization/11832] Optimization of common code in switch statements
-- aldot at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldot at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-07 04:15:54 |2007-08-17 07:17:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832
[Bug c/33096] New: Internal compiler error with register global variables
Compile the following program with -O3 on FreeBSD or Linux, x86:
///
#include stdlib.h
#include string.h
register long foo asm(esi);
register long bar asm(edi);
char * crash_me_baby(char *str) {
char *path = malloc(1024 + strlen(str));
return path;
}
///
This results in an error like the following:
test.c:10: error: unable to find a register to spill in class 'DIREG'
test.c:10: error: this is the insn:
(insn:HI 16 83 17 2 (parallel [
(set (reg:SI 2 cx [66])
(unspec:SI [
(mem:BLK (reg/v/f:SI 63 [ suffix ]) [0 A8])
(reg:QI 0 ax [70])
(const_int 1 [0x1])
(reg:SI 2 cx [69])
] 20))
(use (reg:SI 19 dirflag))
(clobber (reg/f:SI 68 [ suffix ]))
(clobber (reg:CC 17 flags))
]) 530 {*strlenqi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE
12 (insn_list:REG_DEP_TRUE 14 (insn_list:REG_DEP_TRUE 15 (nil)
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_DEAD (reg:SI 2 cx [69])
(expr_list:REG_DEAD (reg:QI 0 ax [70])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg/f:SI 68 [ suffix ])
(expr_list:REG_EQUAL (unspec:SI [
(mem:BLK (reg/v/f:SI 63 [ suffix ]) [0 A8])
(reg:QI 0 ax [70])
(const_int 1 [0x1])
(reg:SI 2 cx [69])
] 20)
(nil
--
Summary: Internal compiler error with register global variables
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slava at factorcode dot org
GCC build triplet: i386-unknown-freebsd6.2
GCC host triplet: i386-unknown-freebsd6.2
GCC target triplet: i386-unknown-freebsd6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096
[Bug c/33096] Internal compiler error with register global variables
--- Comment #1 from slava at factorcode dot org 2007-08-17 07:56 --- Created an attachment (id=14068) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14068action=view) Test case This is a test case for the bug. Compile with -O1, -O2 or -O3 to trigger it. With -O0, it compiles fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096
[Bug fortran/31298] F2003: use mod, operator(+) = operator(.userOp.) not supported
--- Comment #10 from burnus at gcc dot gnu dot org 2007-08-17 08:14 --- Rejecting operator(.procedure.) has been fixed by PR33072. Accepting multiple renames/imports of an operator (operator(.op.), operator(.myop.)=operator(.op.)) is fixed by the submitted patch http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01081.html Remains to be done: Supporting operator(+)=operator(.myPlusOp.), which can be based on the attachment 13369 and the submitted patch. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code |rejects-valid Summary|Uninitialized variable in |F2003: use mod, operator(+) |f951 (in read_module) / |= operator(.userOp.) not |renaming operator in USE|supported Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug tree-optimization/23330] FIXME from passes.c: pass_may_alias should be a TODO item
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:15 --- Fixed by: 2007-08-14 Daniel Berlin [EMAIL PROTECTED] * tree-pass.h (PROP_pta): Removed. (TODO_rebuild_alias): New. (pass_may_alias): Removed. * tree-ssa-ccp.c (execute_fold_all_builtins): Only rebuild aliasing if we changed something. * tree-ssa-alias.c (compute_may_aliases): Make non-static. Update SSA internally. (pass_may_alias): Removed. (create_structure_vars): Return TODO_rebuild_alias. * tree-ssa-pre.c (do_pre): Return TODO_rebuild_alias. * tree-sra.c (tree_sra): Only rebuild aliasing if something changed. (tree_sra_early): We never affect aliasing right now. * tree-flow.h (compute_may_aliases): New prototype. * passes.c: Remove pass_may_alias from the passes. (execute_function_todo): Support TODO_rebuild_alias. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23330
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-17 09:17 --- This seems to me a duplicate of PR179. I am going to add a dependency to remember to check this PR when PR179 gets fixed. -- manu at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||179 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug c++/31751] [4.1/4.2 regression] ICE with forgotten member declaration
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:23 --- Hi Volker. I will be away for some days on vacations... In the meanwhile, if you could double check that we really want the fix for 27211 (not a regression) on the branches and, in case, take care of the backport, it would be great. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31751
[Bug libstdc++/33084] Small typo in valarray header
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:27 --- Subject: Bug 33084 Author: paolo Date: Fri Aug 17 09:27:06 2007 New Revision: 127579 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127579 Log: 2007-08-17 Johannes Willkomm [EMAIL PROTECTED] PR libstdc++/33084 * include/std/valarray (operator _Op(const _Tp, const valarray)): Fix typo. * testsuite/26_numerics/numeric_arrays/valarray/33084.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/numeric_arrays/valarray/33084.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/valarray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33084
[Bug middle-end/33088] [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:27 --- For one, I don't think __real__ X = R; __imag__ X = C; is really nice looking. Now if the person did: *(double*) X = R; ((double*) X)[1] = C; it might be a different story but then again X is still defined piece wise so you will still get NaN. I really don't think this is a bug as we have an uninitialized variables here in the same way doing: short a; a = b0xff|a; a = (b8)0xFF00|a; Would be defined code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
[Bug libstdc++/33084] Small typo in valarray header
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 09:28 --- Subject: Bug 33084 Author: paolo Date: Fri Aug 17 09:28:09 2007 New Revision: 127580 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127580 Log: 2007-08-17 Johannes Willkomm [EMAIL PROTECTED] PR libstdc++/33084 * include/std/valarray (operator _Op(const _Tp, const valarray)): Fix typo. * testsuite/26_numerics/numeric_arrays/valarray/33084.cc: New. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/26_numerics/valarray/33084.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/std/std_valarray.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33084
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:29 --- /* An in-class declaration of a static data member should be external; it is only a declaration, and not a definition. */ if (init == NULL_TREE) gcc_assert (DECL_EXTERNAL (decl)); Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-08-17 09:29:10 date|| Summary|ICE on valid C++ virtual|[4.2/4.3 Regression] ICE on |template static member in |valid C++ virtual template |namespace |static member in anonymous ||namespace Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug rtl-optimization/11001] global register %edi versus string builtins
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 09:03 --- *** Bug 33096 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||slava at factorcode dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11001
[Bug target/33096] Internal compiler error with register global variables
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:03 --- *** This bug has been marked as a duplicate of 11001 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096
[Bug c++/32870] Unclear error message when declaring struct in wrong namespace
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:35 --- Subject: Bug 32870 Author: paolo Date: Fri Aug 17 09:35:23 2007 New Revision: 127581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127581 Log: /cp 2007-08-17 Paolo Carlini [EMAIL PROTECTED] PR c++/32870 * parser.c (cp_parser_class_head): Improve error message. /testsuite 2007-08-17 Paolo Carlini [EMAIL PROTECTED] PR c++/32870 * g++.dg/other/error17.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/other/error17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32870
[Bug c++/32870] Unclear error message when declaring struct in wrong namespace
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:36 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32870
[Bug libstdc++/33084] Small typo in valarray header
--- Comment #4 from pcarlini at suse dot de 2007-08-17 09:30 --- Fixed for 4.2.2. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33084
[Bug middle-end/33086] warn for read-only uninitialized variables passed as arguments
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-17 10:15 ---
(In reply to comment #3)
void use(const int *a)
{
int *b = (int*)a;
Andrew, you are right. I tend to forget how fragile is 'const', even in C++.
So, then this is invalid and thus it is PR10138.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #5 from pcarlini at suse dot de 2007-08-17 10:22 --- This is now fixed both in mainline and in 4_2-branch: 32190.C: In function 'int main()': 32190.C:5: error: template argument 1 is invalid at this point, not being a regression, I think we can close it. -- pcarlini at suse dot de changed: What|Removed |Added Known to work||4.2.1 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-17 10:24 --- (In reply to comment #5) This is now fixed both in mainline and in 4_2-branch: 32190.C: In function 'int main()': 32190.C:5: error: template argument 1 is invalid at this point, not being a regression, I think we can close it. Is there a testcase for this? If not, perhaps we can close this *after* the testcase is added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #7 from pcarlini at suse dot de 2007-08-17 10:26 --- Sure, I'll take care of that... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 --- Ivan, would you like to write, test and post the testcase? Once it is approved I can commit it for you (with your name of course!). A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you need further help, please contact me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #9 from igodard at pacbell dot net 2007-08-17 10:37 --- Subject: Re: wrong error recovery on parsing template arguments Begging your pardon, but what's wrong with the one I put in already? Ivan manu at gcc dot gnu dot org wrote: --- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 --- Ivan, would you like to write, test and post the testcase? Once it is approved I can commit it for you (with your name of course!). A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you need further help, please contact me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug middle-end/33088] [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store
--- Comment #2 from joseph at codesourcery dot com 2007-08-17 10:37 --- Subject: Re: [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store On Fri, 17 Aug 2007, pinskia at gcc dot gnu dot org wrote: For one, I don't think __real__ X = R; __imag__ X = C; is really nice looking. Now if the person did: *(double*) X = R; ((double*) X)[1] = C; it might be a different story but then again X is still defined piece wise so you will still get NaN. I think setting parts is cleaner than using casts like that, and safer (because of not involving arithmetic that GCC's liable to get wrong in cases involving -0) than R + C * I. I really don't think this is a bug as we have an uninitialized variables here in the same way doing: short a; a = b0xff|a; a = (b8)0xFF00|a; Would be defined code. I think setting the parts is valid GNU C (ISO C doesn't have the __real__ and __imag__ operators), and should be considered much like initializing a struct by parts, where it would definitely be incorrect to generate an exception from an uninitialized part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
(In reply to comment #9)
Subject: Re: wrong error recovery on parsing template arguments
Begging your pardon, but what's wrong with the one I put in already?
Nothing is wrong, but to be useful for GCC testsuite, we need to add some
markers (for example, // { dg-error template argument 1 is invalid }) and
then run an old version and check that the test fails and run it for mainline
and check that the test passes. Then the patch adding the testcase is submitted
to gcc-patches for review with an appropriate changelog, approved and
committed. I think it would be a feasible contribution from you, letting more
advance developers like Paolo to focus on more complex stuff.
But if you don't want to do it just say so, no problem at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug fortran/33095] MAX with optional arguments gives run-time error
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-17 11:24 --- Oh, sh**, I didn't think about simplification. Well, I don't see an easy way to have error messages at runtime, so we should simply skip those. We won't have any diagnostic, but no compiler that I know of does it, but we will be accepting valid code, so it's a no-brainer. I'll work on that. PS: I'm not sure it's a 4.3 regression, but it probably is (I can't test right now). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-08-17 11:24:13 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33095
[Bug other/33087] Add dependency information to object files and make use of it
--- Comment #4 from raselmsh at hotmail dot com 2007-08-17 12:04 --- I took a look at ccache again, and it is definitely not what I was thinking of. ccache is more aimed at accelerating multiple full compile rounds of the same package, whereas I was thinking of improving dependency handling in makefiles in order to simplify them - the same problem that 'gcc -M' solves, but to my mind a more elegant solution. Although ccache can do this, I think it is rather clumsy for the job, just as I wouldn't use it as a substitute for 'gcc -M'. On the other hand, I can live with the fact that you don't agree about the need for this :) If I had time (and you were interested), I would take a look at doing it myself, but unfortunately I don't... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33087
[Bug fortran/33097] New: Invalid decl trees are created for external intrinsics
Recently I discovered, that gfortran FE creates invalid decl trees for exteranl intrinsics: only return value is added to arg chain, and none of the actual arguments. This can potentially break much stuff, because of inconsistency of CALL_EXPR and corresponding fndecl. This was due to the following TODO in gfc_get_symbol_for_expr(): /* TODO: proper argument lists for external intrinsics. */ -- Summary: Invalid decl trees are created for external intrinsics Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: asl at math dot spbu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug fortran/33097] Invalid decl trees are created for external intrinsics
--- Comment #1 from asl at math dot spbu dot ru 2007-08-17 12:42 --- Created an attachment (id=14069) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14069action=view) Quick and dirty patch Attached is quick and dirty patch to populate symbol with arguments. It seems to be incomplete (at least for optional args, as it seems to me), and maybe invalid in general (I touched gfortran FE yesterday for the first time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
12:44 ---
Here is a simpler testcase:
int f(int i) { return 100LL / (1 + i); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug fortran/33097] Invalid decl trees are created for external intrinsics
--- Comment #2 from asl at math dot spbu dot ru 2007-08-17 12:49 --- Quick example of the problem: function_decl 0x4bf6d00 _gfortran_matmul_r4 type function_type 0x52495a0 type void_type 0x4419840 void VOID align 8 symtab 6 alias set -1 LLVM: void pointer_to_this pointer_type 0x44198a0 QI size integer_cst 0x441247c constant invariant 8 unit size integer_cst 0x4412498 constant invariant 1 align 8 symtab 0 alias set -1 arg-types tree_list 0x524d63c value reference_type 0x5249540 chain tree_list 0x524d658 value void_type 0x4419840 void pointer_to_this pointer_type 0x5249600 addressable public external asm-frame-size 0 QI file rnflow.f90 line 2723 chain function_decl 0x4bf6c00 dgetri Note, we have only 1 arg for matmul_r4 and it's return value actually. And such decl is attached to CALL_EXPR, which has 3 arguments to provide for callee :) The gcf_show_symbol() returns (no formal args, as expected): symbol _gfortran_matmul_r4 (REAL 4)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS INTRINSIC-PROC DIMENSION EXTERNAL FUNCTION) Array spec:(2 AS_ASSUMED_SHAPE () () () () ) result: _gfortran_matmul_r4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #10 from zadeck at naturalbridge dot com 2007-08-17 12:48
---
Subject: Re: [4.3 Regression] ICE with -O2 -fsee
wouter dot vermaelen at scarlet dot be wrote:
--- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
12:44 ---
Here is a simpler testcase:
int f(int i) { return 100LL / (1 + i); }
thanks,
everyone knows what the problems with see.c are, it is simply a matter
of having the authors fix their code. Virtually anything that invokes
this pass will cause it to fail.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:09 --- Subject: Bug 33079 Author: fxcoudert Date: Fri Aug 17 13:09:23 2007 New Revision: 127584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127584 Log: PR fortran/33079 * intrinsics/string_intrinsics.c (string_trim, string_minmax): Fix the zero-length result case. * gfortran.dg/zero_length_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/zero_length_2.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:10 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug fortran/33095] MAX with optional arguments gives run-time error
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-17 13:21 --- Oh, sh**, I didn't think about simplification. Well, I don't see an easy way to have error messages at runtime, so we should simply skip those. Good idea. As long as the compiler does the right thing (TM) we don't need run-time errors. Otherwise they make mostly sense with some -f*check-* option. PS: I'm not sure it's a 4.3 regression, but it probably is (I can't test right now). I don't think so. The message was introduced with PR31198 and older versions did probably the same as gfortran 4.2: It crashes if any of the optional arguments is not present (NULL pointers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33095
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #2 from ian at airs dot com 2007-08-17 14:31 --- This patch fixes the problem and passes the g++ testsuite. Index: cp/decl.c === --- cp/decl.c (revision 127491) +++ cp/decl.c (working copy) @@ -4963,7 +4963,7 @@ make_rtl_for_nonlocal_decl (tree decl, t gcc_assert (TREE_STATIC (decl)); /* An in-class declaration of a static data member should be external; it is only a declaration, and not a definition. */ - if (init == NULL_TREE) + if (init == NULL_TREE DECL_INITIAL (decl) == NULL_TREE) gcc_assert (DECL_EXTERNAL (decl)); } -- ian at airs dot com changed: What|Removed |Added Target Milestone|4.2.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug fortran/31298] F2003: use mod, operator(+) = operator(.userOp.) not supported
--- Comment #11 from patchapp at dberlin dot org 2007-08-17 15:10 --- Subject: Bug number PR31298 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01081.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug fortran/32875] Not Implemented: complex character array constructor
--- Comment #4 from patchapp at dberlin dot org 2007-08-17 15:10 --- Subject: Bug number PR32875 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01077.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32875
[Bug c++/29077] Incorrect error message for destructor in wrong namespace
--- Comment #6 from pcarlini at suse dot de 2007-08-17 15:30 --- I guess we can indeed close this one as fixed in mainline... -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29077
[Bug c++/28107] Incomplete type in struct added to global namespace
--- Comment #2 from pcarlini at suse dot de 2007-08-17 15:37 --- FWIW, Comeau gives very similar errors: ComeauTest.c, line 3: error: incomplete type is not allowed union B b; ^ ComeauTest.c, line 6: error: tag kind of class or struct is incompatible with declaration of union B (declared at line 3) struct B; ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28107
[Bug libstdc++/33098] New: __is_convertible_helper in tr1_impl/type_traits uses deprecated add_reference
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure CC=gcc43 CXX=g++43 --program-suffix=43
--disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070816 (experimental)
The following code:
#include type_traits
int main() {
bool b = std::is_convertibleint*,int*::value;
}
when compiled with:
g++43 -std=c++0x test.cpp -o test
Gives:
include/c++/4.3.0/type_traits: In instantiation of const bool
std::__is_convertible_helperint*, int*, false::__value:
include/c++/4.3.0/type_traits:258: instantiated from
std::is_convertibleint*, int*
test.cpp:5: instantiated from here
include/c++/4.3.0/type_traits:243: error: invalid use of incomplete type
struct std::add_referenceint*
include/c++/4.3.0/tr1_impl/type_traitsfwd.h:157: error: declaration of struct
std::add_referenceint*
include/c++/4.3.0/type_traits: In instantiation of std::is_convertibleint*,
int*:
test.cpp:5: instantiated from here
include/c++/4.3.0/type_traits:258: error: std::__is_convertible_helperint*,
int*, false::__value is not a valid template argument for type bool because
it is a non-constant expression
test.cpp: In function int main():
test.cpp:5: error: value is not a member of std::is_convertibleint*, int*
Besauce the following structure uses deprecated add_reference.
templatetypename _From, typename _To,
bool = (is_void_From::value || is_void_To::value
|| is_function_To::value || is_array_To::value
// This special case is here only to avoid warnings.
|| (is_floating_pointtypename
remove_reference_From::type::value
__is_int_or_cref_To::__value))
struct __is_convertible_helper
{
// An imaginary lvalue of type From
static const bool __value = (__is_convertible_simpletypename
add_reference_From::type, _To::__value);
};
FIX:
change add_reference to add_lvalue_reference (see attached patch)
--
Summary: __is_convertible_helper in tr1_impl/type_traits uses
deprecated add_reference
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot fairles at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug libstdc++/33098] __is_convertible_helper in tr1_impl/type_traits uses deprecated add_reference
--- Comment #1 from chris dot fairles at gmail dot com 2007-08-17 15:48 --- Created an attachment (id=14070) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14070action=view) patch to fix compile error when using pointers with is_convertible -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug libstdc++/33098] __is_convertible_helper in tr1_impl/type_traits uses deprecated add_reference
--- Comment #2 from chris dot fairles at gmail dot com 2007-08-17 15:48 --- Created an attachment (id=14071) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14071action=view) test case that gives compile error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug fortran/32881] PURE attribute escapes from contained procedure
--- Comment #5 from patchapp at dberlin dot org 2007-08-17 15:10 --- Subject: Bug number PR32881 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01078.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32881
[Bug c++/18207] misleading diagnostic for ill-formed implicitly-defined default constructor
--- Comment #2 from pcarlini at suse dot de 2007-08-17 16:15 --- This is fixed in the active branches. Now the diagnostic is: 18207.C: In constructor 's::s()': 18207.C:8: error: no matching function for call to 'm::m()' 18207.C:4: note: candidates are: m::m(const m) 18207.C: In constructor 's1::s1()': 18207.C:15: note: synthesized method 's::s()' first required here -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.1.2 4.2.1 4.3.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18207
[Bug libstdc++/33098] [c++0x] __is_convertible_helper in type_traits uses deprecated add_reference
--- Comment #4 from paolo at gcc dot gnu dot org 2007-08-17 16:39 --- Subject: Bug 33098 Author: paolo Date: Fri Aug 17 16:39:10 2007 New Revision: 127588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127588 Log: 2007-08-17 Chris Fairles [EMAIL PROTECTED] PR libstdc++/33098 * include/std/type_traits (__is_convertible_helper): Use add_lvalue_reference. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #11 from igodard at pacbell dot net 2007-08-17 17:25 ---
Subject: Re: wrong error recovery on parsing template arguments
Seems impractical. I don't have access to the old versions or mainline,
and don't know what magic to put in the source for your system to use.
I'm sure all that could be fixed, but it's more likely to take more of
someone's time holding my hand than it would be to do it themselves. If
I were doing a hundred of them it would be worth the investment, but for
a one-off it seems hardly useful.
Ivan
manu at gcc dot gnu dot org wrote:
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
(In reply to comment #9)
Subject: Re: wrong error recovery on parsing template arguments
Begging your pardon, but what's wrong with the one I put in already?
Nothing is wrong, but to be useful for GCC testsuite, we need to add some
markers (for example, // { dg-error template argument 1 is invalid }) and
then run an old version and check that the test fails and run it for mainline
and check that the test passes. Then the patch adding the testcase is
submitted
to gcc-patches for review with an appropriate changelog, approved and
committed. I think it would be a feasible contribution from you, letting more
advance developers like Paolo to focus on more complex stuff.
But if you don't want to do it just say so, no problem at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug libstdc++/33098] [c++0x] __is_convertible_helper in type_traits uses deprecated add_reference
--- Comment #3 from pcarlini at suse dot de 2007-08-17 16:31 --- Yes, let's patch-up this, but really I have to finish the builtin, this is only temporary. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-17 16:31:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug libstdc++/33098] [c++0x] __is_convertible_helper in type_traits uses deprecated add_reference
--- Comment #5 from pcarlini at suse dot de 2007-08-17 16:40 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug testsuite/31884] priority_queue_dijkstra.cc operates on deallocated memory
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-17 17:24 --- Subject: Bug 31884 Author: drow Date: Fri Aug 17 17:24:22 2007 New Revision: 127590 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127590 Log: PR testsuite/31884 * testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc (main): Do not access deleted nodes. * testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc, testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc, testsuite/27_io/basic_filebuf/open/char/4.cc, testsuite/27_io/objects/char/9.cc: Use dg-require-fileio. * testsuite/ext/forced_exception_error/cons_virtual_derivation.cc, testsuite/ext/pb_ds/regression/hash_data_map_rand.cc, testsuite/ext/pb_ds/regression/trie_data_map_rand.cc, testsuite/ext/pb_ds/regression/list_update_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc, testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/priority_queue_rand.cc, testsuite/ext/pb_ds/regression/tree_data_map_rand.cc, testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc, testsuite/ext/throw_allocator/deallocate_global.cc, testsuite/ext/throw_allocator/check_delete.cc, testsuite/ext/throw_allocator/check_allocate_max_size.cc, testsuite/ext/throw_allocator/check_deallocate_null.cc, testsuite/ext/throw_allocator/check_new.cc, testsuite/ext/throw_allocator/deallocate_local.cc, testsuite/tr1/5_numerical_facilities/random/subtract_with_carry_01/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/subtract_with_carry/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/linear_congruential/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/mersenne_twister/cons/gen1.cc, testsuite/23_containers/list/modifiers/insert/25288.cc: Use dg-require-time. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/insert/25288.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/open/char/4.cc trunk/libstdc++-v3/testsuite/27_io/objects/char/9.cc trunk/libstdc++-v3/testsuite/ext/forced_exception_error/cons_virtual_derivation.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_allocate_max_size.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_deallocate_null.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_delete.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_new.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/deallocate_global.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/deallocate_local.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/mersenne_twister/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/subtract_with_carry/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/subtract_with_carry_01/cons/gen1.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31884
[Bug c++/14283] Diagnostic for invalid template-id could be improved
--- Comment #12 from pcarlini at suse dot de 2007-08-17 18:09 --- Hi Giovanni, any update on this? -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14283
[Bug target/31385] gcc fails to find spill register for decimal arithmetic
--- Comment #1 from janis at gcc dot gnu dot org 2007-08-17 18:21 --- Current mainline (revision 127590) still gets this ICE for i686-pc-linux-gnu with either bid or dpd decimal float support. The current line number for the ICE is reload1.c:2001. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31385
[Bug tree-optimization/33099] New: Scalar evolutions confusing VRP with pointer values that wrap around
The following test case is miscompiled with GCC 4.2:
extern void abort (void);
volatile int N = 5;
void foo (void)
{
int i;
char *p, value[10];
value[0] = 0x42;
for (i = 0; i N; i++)
if (i 0)
{
p = (char *)i - 1;
*(value + (int) p) = (char) i;
}
if (value[0] != 1)
abort ();
}
main()
{
foo ();
return 0;
}
$ gcc --version
gcc (GCC) 4.2.2 20070816 (prerelease)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -O2 -o a a.c
$ ./a
Aborted (core dumped)
This was originally a C++ program which I converted into this C snippet from
GIMPLE. I believe it's valid C, but I am not actually sure. The original C++
code *is* valid, though.
The problem here starts in tree-vrp.c:adjust_range_with_scev() when we ask for
the scalar evolution of p_8 in the loop
L0:;
i_24 = ASSERT_EXPR i_1, i_1 N.1_6;
if (i_24 0) goto L1; else goto L7;
[ ... ]
L1:;
i_4 = ASSERT_EXPR i_24, i_24 0;
i.0_7 = (char *) i_4;
p_8 = i.0_7 - 1B;
[...]
L2:;
i_11 = i_24 + 1;
# i_1 = PHI 0(2), i_11(5);
L3:;
if (i_1 N.1_6) goto L0; else goto L4;
The call to analyze_scalar_evolution(loop, p_8) returns the chrec {-1B, +, 1B}
which is more or less understandable because the initial value i.0_7 can be
traced all the way back to the start of the loop to 0.
However:
1- SCEV has not realized that there is an ASSERT_EXPR in the path. The initial
value of i.0_7 is actually 1, not 0.
2- When VRP sees the chrec {-1B, +, 1B} it asks whether it may wrap. Since we
assumes that pointers never wrap, scev_probably_wraps_p returns false. Which
is understandable, I guess, but in this case we get burnt by the logic that
follows in adjust_range_with_scev:
* Since the range we have is VARYING, we take the initial value of the given
chrec and set it as the min value for the range. So, the minimum value for the
new range is set to -1B.
* Since the scalar evolution goes forward, we set the maximum value to the
max value for the type (upper_bound_in_type). Which also happens to be -1B.
* So, we end up with the range [-1B, -1B] which we later propagate into the
pointer dereference, causing the failure.
This problem does not happen in mainline because of the PTR_PLUS_EXPR cleanup.
Pointer arithmetic uses unsigned types and all this is avoided.
I think that the core problem is that we are tripping over the fact that while
we don't consider pointers to wrap, the instantiation of the chrec is giving
wrapped-around pointer values. This confuses VRP.
So far, I see the following options for fixing this:
1- Teach SCEV that subtracting pointer values from 0 yields an unkown
chrec. Similarly, adding to upper_bound_in_type will yield an unkown
chrec. What's the wording in the standard wrt pointer arithmetic? Is
the following undefined, implementation defined, or valid?
char *p = 0;
--p;
*p = 'x';
2- Teach SCEV about ASSERT_EXPRs when instantiating chrecs. Would
benefit both mainline and 4.2. May hide other bugs that occur when
there are no assertions around. But that's unlikely.
3- Tell VRP to refuse to do anything with pointer chrecs that have a constant
initial value. This may prove suboptimal in some cases where we could've
gotten a good range, but they should be few and far between.
4- In mainline, the representation of pointer arithmetic has been
cleaned up considerably with the PTR_PLUS_EXPR patches. Bringing those
in to 4.2 is IMO out of the question because of the sheer invasiveness.
But if the problem was widespread enough maybe we could consider it. I
don't think it is, though.
--
Summary: Scalar evolutions confusing VRP with pointer values that
wrap around
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug fortran/20441] -finit-local-zero is missing from gfortran
--- Comment #8 from patchapp at dberlin dot org 2007-08-17 20:15 --- Subject: Bug number PR20441 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01151.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 20:18 --- Confirmed (and yes this was fixed by PtrPlus). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.2.1 Known to work||4.3.0 4.1.1 Last reconfirmed|-00-00 00:00:00 |2007-08-17 20:18:57 date|| Summary|Scalar evolutions confusing |[4.2 Regression] Scalar |VRP with pointer values that|evolutions confusing VRP |wrap around |with pointer values that ||wrap around Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 20:20 --- Exposed by: 2006-02-07 Jeff Law [EMAIL PROTECTED] Which added VRP after IV-OPTs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #3 from dnovillo at google dot com 2007-08-17 20:27 --- Subject: Re: [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around On 8/17/07 4:20 PM, pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 20:20 --- Exposed by: 2006-02-07 Jeff Law [EMAIL PROTECTED] Which added VRP after IV-OPTs. No, no that is completely unrelated. This happens in the first VRP pass. It's all inside adjust_range_with_scev which specifically calls scalar evolutions code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-17 20:34 --- Oh you are correct but this still worked in 4.1.1 though, I have not looked into what changed between 4.1.1 and 4.2.0 with respect of scev yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|law at gcc dot gnu dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #5 from dnovillo at google dot com 2007-08-17 20:37 --- Subject: Re: [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around On 8/17/07 4:34 PM, pinskia at gcc dot gnu dot org wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-17 20:34 --- Oh you are correct but this still worked in 4.1.1 though, I have not looked into what changed between 4.1.1 and 4.2.0 with respect of scev yet. Since you are looking, two things to check for: (1) IL representation for the pointer subtraction, and (2) SCEV may have returned an unknown chrec back in 4.1. Or maybe we still didn't consider pointers to not-wrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-17 20:42 ---
The IR is the same but scev did something different:
Visiting statement:
p_10 = i.0_9 - 1B;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = p_10)
(get_scalar_evolution
(scalar = p_10)
(scalar_evolution = ))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i.0_9)
(get_scalar_evolution
(scalar = i.0_9)
(scalar_evolution = {0B, +, 1B}_1))
(set_scalar_evolution
(scalar = i.0_9)
(scalar_evolution = {0B, +, 1B}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = 1B)
(get_scalar_evolution
(scalar = 1B)
(scalar_evolution = 1B))
)
(set_scalar_evolution
(scalar = p_10)
(scalar_evolution = {4294967295B, +, 1B}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {4294967295B, +, 1B}_1)
(res = {4294967295B, +, 1B}_1))
Found new range for p_10: VARYING
vs (in 4.2):
Visiting statement:
i.0_4 = (char *) i_23;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i.0_4)
(get_scalar_evolution
(scalar = i.0_4)
(scalar_evolution = ))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_23)
(get_scalar_evolution
(scalar = i_23)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_23)
(scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_1)
(get_scalar_evolution
(scalar = i_1)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_1)
(scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = ))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = N.1_3)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(res = scev_not_known))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_8)
(get_scalar_evolution
(scalar = i_8)
(scalar_evolution = ))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_25)
(get_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = 1)
(get_scalar_evolution
(scalar = 1)
(scalar_evolution = 1))
)
(set_scalar_evolution
(scalar = i_8)
(scalar_evolution = {1, +, 1}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {1, +, 1}_1)
(res = {1, +, 1}_1))
Induction variable (int) 1 + 1 * iteration does not wrap in statement i_8 =
i_25 + 1 in loop 1.
Statement i_8 = i_25 + 1 is executed at most 2147483646 (bounded by 2147483646)
+ 1 times in loop 1.
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_25)
(get_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {0, +, 1}_1)
(res = {0, +, 1}_1))
Induction variable (int) 0 + 1 * iteration does not wrap in statement i_25 =
ASSERT_EXPR i_1, i_1 N.1_3 in loop 1.
Statement i_25 = ASSERT_EXPR i_1, i_1 N.1_3 is executed at most 2147483647
(bounded by 2147483647) + 1 times in loop 1.
(set_scalar_evolution
(scalar = i.0_4)
(scalar_evolution = {0B, +, 1B}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {0B, +, 1B}_1)
(res = {0B, +, 1B}_1))
Found new range for i.0_4: [0B, -1B]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug c/30013] Multiple flaws in decimal floating-point arithmetic conversions fixed
--- Comment #5 from janis at gcc dot gnu dot org 2007-08-17 20:44 --- Why use %.9e, %.17e, and %.36Le to write the binary float values to a string, instead of using lengths of FLT_DIG, DBL_DIG, and LDBL_DIG? For i686-linux those are 6, 15, and 18. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30013
[Bug c++/32112] [4.1/4.2/4.3 regression] #'unbound_class_template' not supported by dump_decl#
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 20:47 --- Subject: Bug 32112 Author: paolo Date: Fri Aug 17 20:46:59 2007 New Revision: 127596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127596 Log: /cp 2007-08-17 Paolo Carlini [EMAIL PROTECTED] PR c++/32112 * error.c (dump_decl): Deal with UNBOUND_CLASS_TEMPLATE. * cxx-pretty-print.c (pp_cxx_unqualified_id): Likewise. /testsuite 2007-08-17 Paolo Carlini [EMAIL PROTECTED] PR c++/32112 * g++.dg/template/error26.C: New. Added: trunk/gcc/testsuite/g++.dg/template/error26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32112
[Bug bootstrap/33100] New: on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
I now get this during bootstrap on Solaris x86 using the native linker (/usr/ccs/bin/ld): ld: fatal: unwind table: file /u01/var/tmp/gcc_trunk_svn/gcc_20070817/./gcc/amd64/crtend.o: section .eh_frame: bad cie version 0: offset 0x0 collect2: ld returned 1 exit status gmake[5]: *** [libgcc_s.so] Error 1 gmake[5]: Leaving directory `/u01/var/tmp/gcc_trunk_svn/gcc_20070817/i386-pc-solaris2.11/amd64/libgcc' Let me know if you need more information. It seems to occur when linking the 64bit libgcc. Brett Albertson -- Summary: on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #12 from paolo at gcc dot gnu dot org 2007-08-17 21:31 --- Subject: Bug 32190 Author: paolo Date: Fri Aug 17 21:31:40 2007 New Revision: 127597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127597 Log: 2007-08-17 Paolo Carlini [EMAIL PROTECTED] PR c++/32190 * g++.dg/parse/error31.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/error31.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
