Re: abs insn with QI and HI mode
Hi Jim, Thanks very much for your email. Will gcc add the optimization support in the future (method 1)? For method 2, if abs accept short/char, may I give the function names as sabs and qabs? Gcc does already have cabs as complex abs, doesn't it? Best regards Maggie Quoting Jim Wilson [EMAIL PROTECTED]: Ying Yi wrote: The generated codes do the following operations: 1) extend variable a_HI (HImode) to temp variable SImode, and do abs operation with SImode operators. I find the gimple intermedia represention as shown below: abs is a standard library function that takes an int as an argument. So if you call abs(), then gcc must convert the argument to type int before generating code for the abs. To get your special char/short abs instructions, we need one of two things 1) Optimization support to recognize a sign-extend followed by an abs, where the target has an abs instruction that operates on the pre-extended value. We can then optimize away the sign extend instruction. This optimization support apparently does not exist at the moment, perhaps because no one has needed it before. 2) Alternative abs function calls that accept short/char. We already have abs (int), labs (long), llabs(long long), fabs (double), fabsf (float) and fabsl (long double). -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: RFC: GIMPLE tuples. Design and implementation proposal
In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time, [EMAIL PROTECTED] writes: On 7/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld writes: This page http://deputy.cs.berkeley.edu/ has a link to this document http://hal.cs.berkeley.edu/cil/ which describes a means to obtain three-address code here http://hal.cs.berkeley.edu/cil/ext.html#toc24 . 2007/7/08, Diego Novillo [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) : Any specific reasons why we should? Better memory savings? Faster processing? It's not clear from your message what the advantages would be (ignoring the fact that their implementation language is completely different). You haven't explained what advantages CIL's IR has over GIMPLE. I thought it was well explained on page: _http://hal.cs.berkeley.edu/cil/cil001.html_ (http://hal.cs.berkeley.edu/cil/cil001.html) Please look at this page: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) If you choose to run CIL _locally_ (not add it to GCC, but _only_ run it on your computer) then you can program in Deputy. The Deputy language is very much like C but uses a few additional annotations which allow program checking when it is compiled. Deputy converts it's C to 'regular-C' which is processed by GCC. The result is (obviously) executable. A simple SED script can remove the annotations and leave you with 'regular-C' which can then be released as part of GCC (or you can release 'Deputy-C' with GCC and include the SED script which would process the file and produce the source for stage 1. Doing that buys you a better quality of code tested by CIL (and GCC) which is more likely to be correct since it is checked twice. It costs you having to learn a few Deputy annotations. When you have the CIL source to look at you can read the source and see if it helps you with GIMPLE that you are re-writing. You don't need to include CIL with GCC 4.3 (but you could since you don't need to learn Ocaml to compile it). The result will be better coding that looks no different and compiles without any modification to the current way of building GCC. The second link (above) may help you more. I can't tell, but you may be under the impression GIMPLE is something in the future. It is not. Our IR is already GIMPLE, and a three address code simplified form of C. We are simply talking about changing the underlying datastructures that store it. Yes, I know GCC uses GIMPLE. Hint: CIL's IR is almost exactly GIMPLE with alpha renaming over multiple units. --Dan It is your project to write the way you want. You RFC letter said Thoughts/comments on the proposal?. My reply is that this page:_http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) and this site: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html) provide a better explanation of IR issues. You might also wish to read _http://deputy.cs.berkeley.edu/_ (http://deputy.cs.berkeley.edu/) or this one _http://www.cminusminus.org/_ (http://www.cminusminus.org/) or _http://www.nabble.com/Gnu---Lightning-f1717.html_ (http://www.nabble.com/Gnu---Lightning-f1717.html) or ... Best of luck with your project, I hope it brings a _huge_ advance to GCC. Rob
Crossbuild problem x86_64-pc-mingw32 related to crtbegin crtend
Hi, I tried to build the cross-compiler for the target x86_64-pc-mingw32 and noticed some trouble about the crtbegin and crtend for this target. To the specfile this object was introduced by the patch of Danny Smith from the 14th of Jine 2007. The problem is, that those objects are not compiled and they seems to be not even build for i?86 AFAICS. May somebody can help me for this problem. Is it ok to simply remove the crt*.o from spec file for this target, or should these files be builded for it ? Thanks in advance and cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin crtend
On 10 July 2007 12:19, Kai Tietz wrote: Hi, I tried to build the cross-compiler for the target x86_64-pc-mingw32 and noticed some trouble about the crtbegin and crtend for this target. To the specfile this object was introduced by the patch of Danny Smith from the 14th of Jine 2007. The problem is, that those objects are not compiled and they seems to be not even build for i?86 AFAICS. May somebody can help me for this problem. Is it ok to simply remove the crt*.o from spec file for this target, or should these files be builded for it ? Are you trying to rebuild in an old objdir from before the patch? I found that something didn't work as I had hoped in the dependencies and I had to blow away my existing build dir and configure from fresh. cheers, DaveK -- Can't think of a witty .sigline today
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin crtend
Kai Tietz Tuesday, 10 July 2007 11:19 p.m. Hi, I tried to build the cross-compiler for the target x86_64-pc-mingw32 and noticed some trouble about the crtbegin and crtend for this target. To the specfile this object was introduced by the patch of Danny Smith from the 14th of Jine 2007. The problem is, that those objects are not compiled and they seems to be not even build for i?86 AFAICS. The builds are specified in libgcc/config.host for i?86 mingw and cygwin. What happens if you do the same for x86_64-*-mingw*? May somebody can help me for this problem. Is it ok to simply remove the crt*.o from spec file for this target, or should these files be builded for it ? How else can you initialize and clean up the Dwarf2 unwind registrations on x86_64-pc-mingw32? Danny
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin crtend
Dave Korn wrote on 10.07.2007 13:24:30: On 10 July 2007 12:19, Kai Tietz wrote: Are you trying to rebuild in an old objdir from before the patch? I found that something didn't work as I had hoped in the dependencies and I had to blow away my existing build dir and configure from fresh. Nope, I used a fresh gcc trunk repository for this. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin crtend
On 10 July 2007 12:38, Kai Tietz wrote: Dave Korn wrote on 10.07.2007 13:24:30: On 10 July 2007 12:19, Kai Tietz wrote: Are you trying to rebuild in an old objdir from before the patch? I found that something didn't work as I had hoped in the dependencies and I had to blow away my existing build dir and configure from fresh. Nope, I used a fresh gcc trunk repository for this. I would have to infer from that that you build in $srcdir Better show us your configure line then. What host type is this cross for? cheers, DaveK -- Can't think of a witty .sigline today
RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin crtend
Hi Danny, How else can you initialize and clean up the Dwarf2 unwind registrations on x86_64-pc-mingw32? Clear ;) But I meant, why those objects are not build for this target in (lib)gcc ? Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: abs insn with QI and HI mode
Will gcc add the optimization support in the future (method 1)? Since GCC is a volunteer project, the answer for any sort of question like that is if somebody writes it, it'll exist and if they don't, it won't. There's no good way to predict what projects people will find interesting.
Re: AMD64 ABI compatibility
On 09 July 2007 20:48, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Honza cheers, DaveK -- Can't think of a witty .sigline today
Re: AMD64 ABI compatibility
On 09 July 2007 20:48, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. Is this ok for you. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. For code bridging MS and GNU codebases (such as wine, or lets say, GNU runtime in windows if it ends up with non-MS calling convetions). Then you want to use the attributes to call code from foreign world. x86_64_linux is probably not very exact - we intended the ABI to be generally useful for non-linux or non-GNU system (i.e. specified as System V Application Binary Interface AMD64 Architecture Processor Supplement with GCC as reference implementation). I believe Sparc and other unixes are more or less following it too. For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... Sorry for the typo in your name! Honza Is this ok for you. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. For code bridging MS and GNU codebases (such as wine, or lets say, GNU runtime in windows if it ends up with non-MS calling convetions). Then you want to use the attributes to call code from foreign world. x86_64_linux is probably not very exact - we intended the ABI to be generally useful for non-linux or non-GNU system (i.e. specified as System V Application Binary Interface AMD64 Architecture Processor Supplement with GCC as reference implementation). I believe Sparc and other unixes are more or less following it too. For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: RFC: GIMPLE tuples. Design and implementation proposal
[EMAIL PROTECTED] writes: Please look at this page: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) That tells me about the MLRISC IR, but it doesn't tell me what significant advantages it has over GIMPLE. If you choose to run CIL _locally_ (not add it to GCC, but _only_ run it on your computer) then you can program in Deputy. The Deputy language is very much like C but uses a few additional annotations which allow program checking when it is compiled. Your e-mail messages do not make clear what you are proposing. Precisely what change do you propose should be made to GCC itself? If you just want to let us know about an alternative IR, then: thanks. Ian
Re: AMD64 ABI compatibility
For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. I would say that it is in general very desirable feature for wine programmers and similar projects (I would preffer to have confirmation that they are going to need it however ;). The implementation will be moderately tricky - you will need to keep track of functions calling foreign functions and adjust behaviour of ix86_function_arg_regno_p and friends accordingly. Also the set of call clobbered registers differs. Since MS ABI has fewer of them, calling from SYSV ABI is OK, but in the other direction I guess the call pattern will need to have variants with clobbers of SI/DI. But if you are interested to implement it, you are definitly welcome ;) Honza Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: abs insn with QI and HI mode
Richard Kenner wrote: Will gcc add the optimization support in the future (method 1)? Since GCC is a volunteer project, the answer for any sort of question like that is if somebody writes it, it'll exist and if they don't, it won't. There's no good way to predict what projects people will find interesting. Unless of course you hire someone to do the work for you, or do it yourself!
Re: AMD64 ABI compatibility
For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. I would say that it is in general very desirable feature for wine programmers and similar projects (I would preffer to have confirmation that they are going to need it however ;). The implementation will be moderately tricky - you will need to keep track of functions calling foreign functions and adjust behaviour of ix86_function_arg_regno_p and friends accordingly. Also the set of call clobbered registers differs. Since MS ABI has fewer of them, calling from SYSV ABI is OK, but in the other direction I guess the call pattern will need to have variants with clobbers of SI/DI. But if you are interested to implement it, you are definitly welcome ;) Honza I am on that tricky thing ;) I think I need in i386.c an global variable ix86_amd64_abi which helds the the current function abi. This means also that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var may initioalized by init_cumulative_args and the overriden REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX, SSE_REGPARM_MAX, STACK_BOUNDARY, etc. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
crtbegin.o crtend.o
Hi all, What files are the sources of crtbegin.o and crtend.o ? What's their purposes ? thank you sunzir
missing std::move
Hi all, I tried to compile some rvalue reference examples by (from H.Hinnant at http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_rationale.html) with one of the latest GCC 4.3 snapshots, but I'm getting error: 'move' is not a member of 'std' What can I do to get this working ? Cheers Maett Eugster
Re: missing std::move
fafa wrote:
Hi all,
I tried to compile some rvalue reference examples by (from H.Hinnant at
http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_rationale.html)
with one of the latest GCC 4.3 snapshots, but I'm getting
error: 'move' is not a member of 'std'
What can I do to get this working ?
Provide a std::move? ;) std::move is evidently a library function in
namespace std and you should provide one, because we are not delivering
yet a complete C++0x library. For example this one (directly from N1690)
should work:
template class T
inline typename remove_referenceT::type
move(T x)
{ return x; }
(of course remember to include type_traits)
Paolo.
Re: AMD64 ABI compatibility
I am on that tricky thing ;) I think I need in i386.c an global variable ix86_amd64_abi which helds the the current function abi. This means also that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var may initioalized by init_cumulative_args and the overriden REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX, SSE_REGPARM_MAX, STACK_BOUNDARY, etc. In order to get all cases right (ie switching ABIs and calling foreign function), you need more bookkeeping than this. I am just in hurry to catch bus, but I will send you little guide tonight. Honza Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Query regarding volatiles and store CCP.
Hi,
While upgrading a port of mine to trunk for a testcase I noticed the
following . Its more of a question for a language lawyer I guess.
The test looks like this.
int spinlock[2];
void foo (void)
{
volatile int * spinlock0;
while (*spinlock0 == 0)
{
/* do nothing */
}
}
Store CCP folds away the assignment in the following way :
Folded statement: *spinlock0_1 = 0;
into: spinlock[0] = 0;
Folded statement: *spinlock1_2 = 0;
into: spinlock[1] = 0;
Folded statement: D.1498_3 = *spinlock0_1;
into: D.1498_3 = spinlock[0];
main ()
{
volatile int * spinlock1;
volatile int * spinlock0;
int D.1498;
bb 2:
spinlock0_1 = spinlock[0];
spinlock1_2 = spinlock[1];
spinlock[0] = 0;
spinlock[1] = 0;
bb 3:
D.1498_3 = spinlock[0];
if (D.1498_3 != 0)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
which later results in the loop getting optimized away. However
marking spinlock as volatile let the loop remain.
I originally thought this to be a problem . However after chatting
about it on IRC I wasn't sure if this was (un)defined behaviour. I
looked through the standard but was unable to figure out from the
prose , whether it stated some place that the object pointed to also
should also have the same type qualifiers as the pointer being used to
access this.
Thanks in advance
Ramana
--
Ramana Radhakrishnan
Re: Query regarding volatiles and store CCP.
On 7/10/07, Ramana Radhakrishnan [EMAIL PROTECTED] wrote:
Hi,
While upgrading a port of mine to trunk for a testcase I noticed the
following . Its more of a question for a language lawyer I guess.
The test looks like this.
int spinlock[2];
void foo (void)
{
volatile int * spinlock0;
while (*spinlock0 == 0)
{
/* do nothing */
}
}
Store CCP folds away the assignment in the following way :
Folded statement: *spinlock0_1 = 0;
into: spinlock[0] = 0;
Folded statement: *spinlock1_2 = 0;
into: spinlock[1] = 0;
Folded statement: D.1498_3 = *spinlock0_1;
into: D.1498_3 = spinlock[0];
main ()
{
volatile int * spinlock1;
volatile int * spinlock0;
int D.1498;
bb 2:
spinlock0_1 = spinlock[0];
spinlock1_2 = spinlock[1];
spinlock[0] = 0;
spinlock[1] = 0;
bb 3:
D.1498_3 = spinlock[0];
if (D.1498_3 != 0)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
which later results in the loop getting optimized away. However
marking spinlock as volatile let the loop remain.
I originally thought this to be a problem . However after chatting
about it on IRC I wasn't sure if this was (un)defined behaviour. I
looked through the standard but was unable to figure out from the
prose , whether it stated some place that the object pointed to also
should also have the same type qualifiers as the pointer being used to
access this.
We usually try hard to keep this working (the testcase above is not complete
for sure).
Richard.
Re: missing std::move
PS: since apparently people would like that, I decided to implement immediately 20.2.2 of the working draft, thus std::identity, std::forward and std::move. Will be available in utility in one of the next snapshots of 4.3... Thanks, Paolo.
Re: Query regarding volatiles and store CCP.
Hi Richard,
On 7/10/07, Richard Guenther [EMAIL PROTECTED] wrote:
On 7/10/07, Ramana Radhakrishnan [EMAIL PROTECTED] wrote:
Hi,
While upgrading a port of mine to trunk for a testcase I noticed the
following . Its more of a question for a language lawyer I guess.
The test looks like this.
int spinlock[2];
void foo (void)
{
volatile int * spinlock0;
while (*spinlock0 == 0)
{
/* do nothing */
}
}
Store CCP folds away the assignment in the following way :
Folded statement: *spinlock0_1 = 0;
into: spinlock[0] = 0;
Folded statement: *spinlock1_2 = 0;
into: spinlock[1] = 0;
Folded statement: D.1498_3 = *spinlock0_1;
into: D.1498_3 = spinlock[0];
main ()
{
volatile int * spinlock1;
volatile int * spinlock0;
int D.1498;
bb 2:
spinlock0_1 = spinlock[0];
spinlock1_2 = spinlock[1];
spinlock[0] = 0;
spinlock[1] = 0;
bb 3:
D.1498_3 = spinlock[0];
if (D.1498_3 != 0)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
which later results in the loop getting optimized away. However
marking spinlock as volatile let the loop remain.
I originally thought this to be a problem . However after chatting
about it on IRC I wasn't sure if this was (un)defined behaviour. I
looked through the standard but was unable to figure out from the
prose , whether it stated some place that the object pointed to also
should also have the same type qualifiers as the pointer being used to
access this.
We usually try hard to keep this working (the testcase above is not complete
for sure).
Ah yes, I'd missed out an assignment . void foo (void)
{
volatile int * spinlock0;
Should be volatile int *spinlock0 = spinlock[0];
}
Filed as PR 32721.
cheers
Ramana
Richard.
--
Ramana Radhakrishnan
ODR violation for std::cout etc.
Hello, Currently libstdc++ violates ODR: iostream: extern ostream cout; global_io.cc: fake_ostream cout; It assumes that gcc will work fine with this. Apparently it does, for now. After solving a similar problem in my code using a similar technique - to find out that it does not work for MS VS-2005 - when I had to find a different fix. The question is, why does GCC has to resolve to such construction-order issue this way? Idea (which I used): don't violate ODR in global_io.cc. Instead, construct and destroy std::cout two times, in a safe way: static PreSecondCtor coutPreSecondCtor(std::cout); ostream std::cout(NULL); static PostSecondCtor coutPostSecondCtor(coutPreSecodCtor); When PreSecondCtor saves all relevant data of cout (error bits, state, rdbuf, etc.), and then calls std::cout.~ostream(); Note that before this point, std::cout has already been constructed by an std::ios::Init, and we need to avoid double construction. In PostSecondCtor, restore the state of cout out of the saved data in outPreSecondCtor. During destruction the order is reversed. I still have a vague feeling that this solution is also undefined (since we are calling the constructor of std::cout, using placement new, after it had been automatically destroyed by the C++ environment). I don't have the standard near me, so I can't check. Anyway, even if this is undefined, the situation is arguably better since it does not seem to break whole program compilation (like current implementation might). What do you think? Michael
Re: crtbegin.o crtend.o
Sunzir Deepur [EMAIL PROTECTED] writes: What files are the sources of crtbegin.o and crtend.o ? The single file gcc/crtstuff.c. What's their purposes ? To ensure that global constructors and destructors are run at the appropriate times (i.e., before main and after exit, respectively). Ian
Re: ODR violation for std::cout etc.
Michael Veksler wrote: What do you think? I think that the current solution is very, very old, and heaven knows how many others didn't work at the time on some exotic platforms. I would suggest filing a PR and CCing Benjamin. Thanks, Paolo.
Re: crtbegin.o crtend.o
On 10 Jul 2007 09:51:14 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote: Sunzir Deepur [EMAIL PROTECTED] writes: What files are the sources of crtbegin.o and crtend.o ? The single file gcc/crtstuff.c. What's their purposes ? To ensure that global constructors and destructors are run at the appropriate times (i.e., before main and after exit, respectively). Thanks !! Ian
Re: ODR violation for std::cout etc.
Michael Veksler wrote: What do you think? On Tue, Jul 10, 2007 at 06:58:50PM +0200, Paolo Carlini wrote: I think that the current solution is very, very old, and heaven knows how many others didn't work at the time on some exotic platforms. I would suggest filing a PR and CCing Benjamin. The ODR is a rule that applies to users' programs; if they violate it, we can't make any promises that their program will work. If there's a violation in the internals of the libstdc++ implementation, then this only really matters if it breaks something. Otherwise I'd suggest classifying the bug P5 (absolute lowest priority); there are any number of real bugs that are more important to fix.
RFA: upcoming testsuite disruptions
There's a testsuite patch that I submitted, but haven't yet checked in, that will break test summary comparisons from before and after that patch is applied: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00834.html http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01076.html A patch from Manuel López-Ibáñez might result in failures for dg-error/dg-warning checks on targets that haven't been tested: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00962.html Both of these changes are worthwhile and should go in, but I'm worried about the disruptions they might cause. Should we coordinate the checkins of these patches with other major changes or freezes, or just do it? Janis
ICE while bootstraping on ppc64.
Hello, The following ICE is received on r126521 while bootstraping on ppc64. Revital /home/eres/test_again/build/./gcc/xgcc -B/home/eres/test_again/build/./gcc/ -B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/bin/ -B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/lib/ -isystem /home/eres/test_again/build/powerpc64-unknown-linux-gnu/include -isystem /home/eres/test_again/build/powerpc64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -m32 -fPIC -mstrict-align -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mno-minimal-toc -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -mlong-double-128 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/../libdecnumber/dpd -I../../../../gcc/libgcc/../libdecnumber -I../../../libdecnumber -DHAVE_CC_TLS -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c ../../../../gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc/libgcc/../gcc/libgcc2.c: In function ג__floatdisfג: ../../../../gcc/libgcc/../gcc/libgcc2.c:1530: internal compiler error: in gen_reg_rtx, at emit-rtl.c:785 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [_floatdisf.o] Error 1
Re: AMD64 ABI compatibility
That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. Nicolas On Jul 10, 2007, at 5:59 , Kai Tietz wrote: Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. For code bridging MS and GNU codebases (such as wine, or lets say, GNU runtime in windows if it ends up with non-MS calling convetions). Then you want to use the attributes to call code from foreign world. x86_64_linux is probably not very exact - we intended the ABI to be generally useful for non-linux or non-GNU system (i.e. specified as System V Application Binary Interface AMD64 Architecture Processor Supplement with GCC as reference implementation). I believe Sparc and other unixes are more or less following it too. For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
On 7/10/07, Nicolas Alt [EMAIL PROTECTED] wrote: That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. mingw x86_64 support is already added for 4.3 on the trunk. Thanks, Andrew Pinski
Re: AMD64 ABI compatibility
Ok - so question is if x86_64 is completely implemented already. For our case, especially the MS ABI. Andrew, do you have any knowledge if they introduced a new calling convention and how they named it? Nicolas On Jul 10, 2007, at 13:29 , Andrew Pinski wrote: On 7/10/07, Nicolas Alt [EMAIL PROTECTED] wrote: That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. mingw x86_64 support is already added for 4.3 on the trunk. Thanks, Andrew Pinski
Re: AMD64 ABI compatibility
On 7/10/07, Nicolas Alt [EMAIL PROTECTED] wrote: Ok - so question is if x86_64 is completely implemented already. For our case, especially the MS ABI. Andrew, do you have any knowledge if they introduced a new calling convention and how they named it? It is only implemented for the x86_64-mingw32 target. Thanks, Andrew Pinski
Re: RFC: GIMPLE tuples. Design and implementation proposal
On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time, [EMAIL PROTECTED] writes: On 7/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld writes: This page http://deputy.cs.berkeley.edu/ has a link to this document http://hal.cs.berkeley.edu/cil/ which describes a means to obtain three-address code here http://hal.cs.berkeley.edu/cil/ext.html#toc24 . 2007/7/08, Diego Novillo [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) : Any specific reasons why we should? Better memory savings? Faster processing? It's not clear from your message what the advantages would be (ignoring the fact that their implementation language is completely different). You haven't explained what advantages CIL's IR has over GIMPLE. I thought it was well explained on page: _http://hal.cs.berkeley.edu/cil/cil001.html_ (http://hal.cs.berkeley.edu/cil/cil001.html) No, since as i said, their IR is the same as GIMPLE. It is your project to write the way you want. You RFC letter said Thoughts/comments on the proposal?. My reply is that this page:_http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) and this site: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html) provide a better explanation of IR issues. Okay, let me ask a different question. What makes you believe we aren't aware of these projects? MLRISC has been around for *years* as has CIL. In fact, I reported bugs against CIL. We are quite aware of what all of them do, we just do not see the advantages, and you have not given any explicit enumeration of them.
GCC 4.2.1 Status Report (2007-07-10)
Summary --- The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all changes. If you have outstanding changes that have been approved, but not committed, make the commits before that time. I plan to build GCC 4.2.1 RC2 tomorrow evening. I will probably wait until a few days after the 13th to build the final release, in order to make sure that people have had a chance to test out RC2. We still have 3 wrong-code P1s: PR 32182 -fstrict-aliasing ... PR 32327 Incorrect stack sharing... PR 32328 -fstrict-aliasing ... Priority# Change from Last Report --- - --- P1 21 -8 P2 113 0 P3 3 +1 Previous Report --- http://gcc.gnu.org/ml/gcc/2007-07/msg00062.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.1 Status Report (2007-07-10)
On 7/11/07, Mark Mitchell [EMAIL PROTECTED] wrote: Summary --- The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all changes. If you have outstanding changes that have been approved, but not committed, make the commits before that time. I plan to build GCC 4.2.1 RC2 tomorrow evening. I will probably wait until a few days after the 13th to build the final release, in order to make sure that people have had a chance to test out RC2. We still have 3 wrong-code P1s: PR 32182 -fstrict-aliasing ... This is not analyzed enough to know whether it's something i should look at, or the C++ FE people should look at. IE Nobody has pointed out what is actually going wrong here, so i don't know whether it's aliasing or what :) PR 32327 Incorrect stack sharing... PR 32328 -fstrict-aliasing ... This i have a patch for, but it really needs some performance testing. I'm happy to throw it in RC2 if you want to see how it does, with the caveat it may need to be pulled back out if it causes massive performance regressions :)
Re: ICE building libgcc2.c for MIPS, too
Sandra Loosemore [EMAIL PROTECTED] writes: The error reported here http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html is also happening when building for target mipsisa32r2-elfoabi on i686-pc-linux-gnu. This should be fixed by revision 126536. Sorry for the problems. Ian
Re: ICE while bootstraping on ppc64.
Revital1 Eres [EMAIL PROTECTED] writes: The following ICE is received on r126521 while bootstraping on ppc64. This should be fixed by revision 126536. Sorry for the problems. Ian
Re: GCC 4.2.1 Status Report (2007-07-10)
Daniel Berlin wrote: PR 32328 -fstrict-aliasing ... This i have a patch for, but it really needs some performance testing. I'm happy to throw it in RC2 if you want to see how it does, with the caveat it may need to be pulled back out if it causes massive performance regressions :) No, I don't want to do that -- but thanks for working on the PR. If you can do some performance testing up front, then I might consider it for a post-RC2 inclusion, even if it means an RC3. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
[Bug fortran/32673] Wrongly allowed: Statement function with subobject of constant
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-10 06:23 --- I think this is indeed no bug. I contacted NAG f95 and if they found something in the standard which we overlooked, I will reopen this PR. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32673
[Bug fortran/32709] Diagnose: ALLOCATABLE array used but never ALLOCATEd
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-10 06:37 --- *** This bug has been marked as a duplicate of 20520 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32709
[Bug fortran/20520] allocatable arrays used uninitialized without a warning
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-10 06:37 --- *** Bug 32709 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
[Bug middle-end/32711] Regression: ICE when using inline asm constraint X
--- Comment #3 from ubizjak at gmail dot com 2007-07-10 06:46 ---
(In reply to comment #1)
X constraint means anything matches. Now why we are ICEing is a bit weird
We hit:
/* We have patterns that allow zero sets of memory, for instance.
In 64-bit mode, we should probably support all 8-byte vectors,
since we can in fact encode that into an immediate. */
if (GET_CODE (x) == CONST_VECTOR)
{
gcc_assert (x == CONST0_RTX (GET_MODE (x)));
x = const0_rtx;
}
It is true that a message would be nice there, but it is also true that X is an
invalid constraint for most (all?) of the instructions.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32711
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #135 from jv244 at cam dot ac dot uk 2007-07-10 07:05 --- new bogus errors compiling all.f90 ... FX, how's the nightly tester setup going? cat out all.f90:23538.44: USE util,ONLY: sort 1 Error: Symbol 'sort' referenced at (1) not found in module 'util' [...] Tue Jul 10 06:45:07 UTC 2007 (revision 126510) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug java/32712] New: error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type
I am compiling a program and the Makefile wants to use Javac. I _did_ use the 1.5 option but still got an error about SuppressWarnings cannot be resolved to a type. I decided to see what GCC 4.3 had to say about the file. I have 4.3 installed in /usr/test . /usr/test/bin/gcc /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java gcc: error trying to exec 'ecj1': execvp: No such file or directory Typing locate ecj1 finds nothing. Typing locate ecj finds many hits (mostly ecj is part of a DOCs name) and I do have a /usr/bin/ecj but no /usr/test/bin/ecj. So lets try the GCC (4.1) that does have an ecj it could use. # gcc /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java:40: error: Invalid character '@' in input. @SuppressWarnings(serial) ^ /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java:20: error: Class or interface 'edu.rice.cs.hpcviewer.view.HPCViewerWindow' not found in import. import edu.rice.cs.hpcviewer.view.HPCViewerWindow; ^ 2 errors Since I need 5 for the annotation I pursue 4.1 no further, lets -v it. gcc -v /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java ... /usr/libexec/gcc/i686-pc-linux-gnu/4.2.0/jc1 /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java -quiet -dumpbase ApplicationActions.java -mtune=athlon-xp -march=athlon-xp -auxbase ApplicationActions -version -o /tmp/ccsDPdP6.s ... So that means GCC (at least 4.1 version, maybe not 4.3) wants to use jc1 and NOT ejc1. I locate that here: /usr/test/libexec/gcc/i686-pc-linux-gnu/4.3.0/jc1. The driver must look there for jc1 and not look anywhere for ejc1 (unless the GCC 4.3 build would like to create and install ejc1. If I try to run jc1 with the options from above I get: # /usr/test/libexec/gcc/i686-pc-linux-gnu/4.3.0/jc1 /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java -o ApplicationActions.s /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java:0: warning: no input file specified Execution times (seconds) parser: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (33%) wall 0 kB ( 0%) ggc TOTAL : 0.02 0.00 0.03 1230 kB So lets try help ... # /usr/test/libexec/gcc/i686-pc-linux-gnu/4.3.0/jc1 --help The following options are specific to the language Ada: -feliminate-unused-debug-types[enabled] -gnatoptions The following options are specific to the language C: No options with the desired characteristics were found The following options are specific to the language C++: No options with the desired characteristics were found The following options are specific to the language Fortran: -Jdirectory -Waliasing -Wampersand -Wcharacter-truncation -Wimplicit-interface -Wline-truncation ... It then prints all the Fortran options (how useful), the Java options, even some langtree options (and I did not specify langtree to the configure!). It continues to list every -W, -f, --param option, -W again, then -f options, target specific options, language-independent options and a whole lot more. Could it be a bit less verbose? Looking through those dozen pages of (no) help it is not very clear why jc1 says no input file specified. So the bug is that I can't use an installed copy of GCC 4.3 to compile a .java file by typing gcc file.java because the driver looks for an executable that does not exist. Trying -v with GCC 4.1 to guess what to type with 4.3 gives a suggestion that does not work with 4.3 - so I'm a bit stuck trying to help myself. I can see something is wrong with the setup. To top it off. Even through I can not compile this file I can get it pre-compiled as a .jar file off the website at: http://www.hipersoft.rice.edu/hpctoolkit/examples.html The file is http://www.hipersoft.rice.edu/hpctoolkit/examples/HPCViewer.jar.gz (and you will likely want on of the data files to examine, they are small). When I click on that Jar file with WinXP it runs fine (Sun JDK) but if I try to open it on GNU/Linux with Iceweasel it won't work (but other Java seems OK - weeks ago). If I start Iceweasel and click on the jar file I get this message: Exception in thread main java.lang.NoClassDefFoundError: /opt/HPCToolkit-OneStopShopping-TRUNK-4/9/0=810/hpcviewer/build-unix/HPCViewer/jar With GCC 4.2 gij I get this message: # gij -jar HPCViewer.jar (.:5821): Gtk-WARNING **: Unable to locate theme engine in
[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-07-10 08:11 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 17:36:22 |2007-07-10 08:11:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug fortran/32707] mismatched character lengths in array
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-10 08:16 --- See also: PR29267. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32707
[Bug tree-optimization/32713] New: [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550
Once PR tree-opt/32589 is fixed, the next hurdle on 32-bit plaforms is: /home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/-B/home/eric/install/gcc/i586-suse-linux/bin/ -B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem /home/eric/install/gcc/i586-suse-linux/include -isystem /home/eric/install/gcc/i586-suse-linux/sys-include -c -g -O2 -fPIC -W -Wall -gnatpg a-numaux.adb -o a-numaux.o +===GNAT BUG DETECTED==+ | 4.3.0 20070708 (experimental) (i586-suse-linux-gnu) GCC error: | | in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550 | | Error detected at a-numaux.adb:572:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html. -- Summary: [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org BugsThisDependsOn: 32589 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713
[Bug c++/32714] New: Wrong optimisation for -O3
Overview:
When using optimisation level -O3 the code generated from attached example is
wrong. It is accumalating the stream increment and thus the function readFloat
reads twice the same number and then it skips two in a row.
Problem seems to be in this line
const float val = *(const float *)stream;
when I change it to
const float val = *(const float *)stream;
it starts working even on -O3.
Steps to reproduce:
Compile this code with -O3.
#include stdio.h
float readFloat(const char *stream)
{
const float val = *(const float *)stream;
stream += sizeof(float);
return val;
}
int main(int argc, char **argv)
{
float stream[] = { 2.0f,
1.0f, 2.0f,
3.0f, 4.0f,
5.0f, 6.0f };
const char *stream2 = (const char *) stream;
for (float i = 0, n = readFloat(stream2); i = n; i += 1.0f) {
const float x = readFloat(stream2);
const float y = readFloat(stream2);
printf(%f,%f\n, x,y);
}
return 0;
}
Actual results:
Prints:
1.00,1.00
3.00,3.00
5.00,5.00
Expected results:
to print:
1.00,2.00
3.00,4.00
5.00,6.00
Build date platform:
gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)
Additional Builds and Platforms:
gcc (GCC) 4.0.2
gcc (GCC) 4.1.1
gcc (GCC) 4.2.0
This bug is not reproducible on gcc 3.3 series.
--
Summary: Wrong optimisation for -O3
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: honza at jikos dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32714
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #17 from spop at gcc dot gnu dot org 2007-07-10 08:30 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug tree-optimization/30730] -Wunsafe-loop-optimizations gives too many warnings
--- Comment #4 from spop at gcc dot gnu dot org 2007-07-10 08:31 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30730
[Bug tree-optimization/31343] ICE in data-refs dependence testing
--- Comment #4 from spop at gcc dot gnu dot org 2007-07-10 08:34 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 09:14 ---
Fixed testcase:
#include emmintrin.h
__m128i int2vector(int i) { return _mm_cvtsi32_si128(i); }
int vector2int(__m128i i) { return _mm_cvtsi128_si32(i); }
__m128i long2vector(long long i) { return _mm_cvtsi64x_si128(i); }
long long vector2long(__m128i i) { return _mm_cvtsi128_si64x(i); }
mainline generates:
int2vector:
.LFB525:
pxor%xmm0, %xmm0
movq%rdi, -8(%rsp)
movq-8(%rsp), %xmm1
movss %xmm1, %xmm0
ret
.LFE525:
.size int2vector, .-int2vector
.p2align 4,,15
.globl long2vector
.type long2vector, @function
long2vector:
.LFB527:
movq%rdi, -8(%rsp)
movq-8(%rsp), %mm0
movq2dq %mm0, %xmm0
ret
.LFE527:
.size long2vector, .-long2vector
.p2align 4,,15
.globl vector2long
.type vector2long, @function
vector2long:
.LFB528:
movq%xmm0, -16(%rsp)
movq-16(%rsp), %rax
ret
.LFE528:
.size vector2long, .-vector2long
.p2align 4,,15
.globl vector2int
.type vector2int, @function
vector2int:
.LFB526:
movd%xmm0, -12(%rsp)
movl-12(%rsp), %eax
ret
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2007-07-10 09:14:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #57 from manu at gcc dot gnu dot org 2007-07-10 09:17 --- Subject: Bug 25241 Author: manu Date: Tue Jul 10 09:17:01 2007 New Revision: 126511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126511 Log: 2007-07-10 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR testsuite/25241 * gcc.dg/pch/counter-2.c: Match every message with its appropriate directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pch/counter-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug c/21920] aliasing violations
--- Comment #118 from rguenth at gcc dot gnu dot org 2007-07-10 09:23 --- *** Bug 32714 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||honza at jikos dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c++/32714] Wrong optimisation for -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 09:23 --- You violate C/C++ aliasing rules by reading/storing a value of type (char *) to a memory location of type (float *). *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32714
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #2 from pluto at agmk dot net 2007-07-10 09:23 --- this looks like a dup of PR30961. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug fortran/32715] New: improve diagnostics of attempted allocation of non-array
$ cat allocate.f90 INTEGER :: i ALLOCATE(i(3)) end $ gfortran-svn -g -Wall allocate.f90 allocate.f90:2.10: ALLOCATE(i(3)) 1 Error: Syntax error in ALLOCATE statement at (1) A message as variable 'i' at (1) not a pointer or allocatable array would be preferable. -- Summary: improve diagnostics of attempted allocation of non-array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32715
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-10 09:37 --- I don't think so, the _mm_ intrinsics are expanded via target builtins. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug c++/32716] New: Wrong code generation. Inlining problem.
Generating wrong code for the following code snippet (test.C)
using namespace std;
#include iostream
class A { public:int a;};
class B: public virtual A { public: A::a;};
class C : public virtual A { public:A::a;};
class D : public C, public B {};
void h ( D x )
{
x.a++;
}
int main ()
{
int result ;
D d;
d.a = 0;
h (d);
result = !(d.a==1);
result ? coutFAILED: cout SUCCESS;
return 0;
}
$arm-none-eabi-g++ -O3 test.C
$ arm-none-eabi-run a.out
FAILED
$arm-none-eabi-g++ -O3 test.C -fno-inline-functions
$ arm-none-eabi-run a.out
SUCCESS
$arm-none-eabi-g++ --version
arm-none-eabi-g++ (GCC) 4.3.0 20070703 (experimental)
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.
--
Summary: Wrong code generation. Inlining problem.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug c++/32716] Wrong code generation. Inlining problem.
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-07-10 10:02 --- Created an attachment (id=13876) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13876action=view) Dump of the early inline pass, that highlights the problem with the inliner h() gets inlined into main but the result of the increment in h() is not used in main after inlining causing 0 to be assigned to result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #4 from ubizjak at gmail dot com 2007-07-10 10:36 ---
(In reply to comment #0)
long2vector() should use a simple MOVQ instruction the way int2vector() uses
MOVD. It appears that the reason for the stack access is that the original
code
used a reg64-mem-mm-xmm path, which the optimizer partly noticed;
gcc-4.3-20070617 leaves the full path in place.
Also, do the vector2X() functions really need to access the stack?
Stack access is the remain of partially implemented TARGET_INTER_UNIT_MOVES,
and this was fully fixed in 4.3. The fact that gcc-4.3 leaves full path in
place is due to missing pattern for vec_concat:V2DI (implemented in the patch
below) where 64bit registers can be concatenated with zero (for 64bit targets)
using movq instruction.
With attached patch, 4.3 generates:
long2vector:
.LFB4:
movq%rdi, %xmm0
ret
.LFE4:
for -march=core2 (TARGET_INTER_UNIT_MOVES allowed)
and
long2vector:
.LFB4:
movq%rdi, -8(%rsp)
movq-8(%rsp), %xmm0
ret
.LFE4:
for -march=k8 (no TARGET_INTER_UNIT_MOVES allowed).
Finally, I've noticed several places where instructions involving 64-bit
values
use the d/l suffix (e.g. long i = 0 == xorl %eax, %eax), or 32-bit
operations that use 64-bit registers (e.g. movd %xmm0, %rax above). Are
those
generally features, bugs, or a who cares?
These are who cares, produced by reload to satisfy register constraints (i.e.
certain alternatives missing as an attempt to solve INTER_UNIT_MOVES
requirements). They are harmles.
Index: sse.md
===
--- sse.md (revision 126510)
+++ sse.md (working copy)
@@ -4717,7 +4717,7 @@
(vec_concat:V2DI
(match_operand:DI 1 nonimmediate_operand m,*y ,0 ,0,0,m)
(match_operand:DI 2 vector_move_operandC, C,Yt,x,m,0)))]
- TARGET_SSE
+ !TARGET_64BIT TARGET_SSE
@
movq\t{%1, %0|%0, %1}
movq2dq\t{%1, %0|%0, %1}
@@ -4728,6 +4728,23 @@
[(set_attr type ssemov,ssemov,sselog,ssemov,ssemov,ssemov)
(set_attr mode TI,TI,TI,V4SF,V2SF,V2SF)])
+(define_insn *vec_concatv2di_rex
+ [(set (match_operand:V2DI 0 register_operand =Yt,Yi,!Yt,Yt,x,x,x)
+ (vec_concat:V2DI
+ (match_operand:DI 1 nonimmediate_operand m,r ,*y ,0 ,0,0,m)
+ (match_operand:DI 2 vector_move_operandC,C ,C ,Yt,x,m,0)))]
+ TARGET_64BIT
+ @
+ movq\t{%1, %0|%0, %1}
+ movq\t{%1, %0|%0, %1}
+ movq2dq\t{%1, %0|%0, %1}
+ punpcklqdq\t{%2, %0|%0, %2}
+ movlhps\t{%2, %0|%0, %2}
+ movhps\t{%2, %0|%0, %2}
+ movlps\t{%1, %0|%0, %1}
+ [(set_attr type ssemov,ssemov,ssemov,sselog,ssemov,ssemov,ssemov)
+ (set_attr mode TI,TI,TI,TI,V4SF,V2SF,V2SF)])
+
(define_expand vec_setv2di
[(match_operand:V2DI 0 register_operand )
(match_operand:DI 1 register_operand )
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-07-10 09:14:14 |2007-07-10 10:36:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #12 from reichelt at gcc dot gnu dot org 2007-07-10 10:44 --- If you will tell me how to remove the flag, I will take care of it. To clean the exectuable flag on file you can do svn propdel svn:executable file and then commit the change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug target/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
-- ubizjak at gmail dot com changed: What|Removed |Added Component|middle-end |target Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug preprocessor/32717] New: def value is ignored
Appeared from July 6th: For instance, if .S file has line: cmpl $FFI_TYPE_INT,%ecx and $FFI_TYPE_INT is included from ffi.h as #define FFI_TYPE_INT1 def value is ignored, and only name after dollar sign is recognized. Defines for assembler are just a string after $. As the result, linker throws undefined references: libffi_convenience.a/win32.o:../../../gcc-4.3-July7th/libffi/src/x86/win32.S:77: undefined reference to `FFI_TYPE_FLOAT' and for all other defined values. Snapshot from June 29th compiled fine. Drazen -- Summary: def value is ignored Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drazen dot zeman at kr dot htnet dot hr GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32717
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-10 11:29 --- This is an aliasing problem (or rather a C++ FE problem): # SFT.41_31 = VDEF SFT.41_30(D) d.D.2508.a = 0; x.0_10 = (struct A *) d; ... D.2747_16 = x.0_10 + D.2746_15; # VUSE SFT.44_27 D.2748_17 = D.2747_16-a; D.2749_18 = D.2748_17 + 1; # SFT.44_34 = VDEF SFT.44_27 D.2747_16-a = D.2749_18; # VUSE SFT.41_31 D.2707_1 = d.D.2508.a; D.2706_2 = D.2707_1 != 1; return D.2706_2; note how we don't identify the contrived access through the virtual base with the zero-initialization and use in main(). Instead, it seems to alias with iftmp.1_6 = (int (*__vtbl_ptr_type) (void) *) D.2735_5; # SFT.44_21 = VDEF SFT.44_20(D) d.D.2504._vptr.C = iftmp.1_6; ... # SFT.44_27 = VDEF SFT.44_21 d.D.2504._vptr.C = _ZTV1D[3]; Of course the original trees created for the virtual base access is somewhat contrieved: (void) ((struct A *) (struct D *) x + (long unsigned int) *(long int *) (((struct D *) x)-D.2504._vptr.C + 0xffe8))-a++ ; while in main() we manage to do: struct D d; cleanup_point Unknown tree: expr_stmt __comp_ctor (d) ; cleanup_point Unknown tree: expr_stmt (void) (d.D.2508.a = 0) ; cleanup_point Unknown tree: expr_stmt h ((struct D ) d) ; return retval = d.D.2508.a != 1; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|arm-none-eabi | Keywords||alias, wrong-code Known to fail||4.2.0 4.2.1 4.3.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-07-10 11:29:31 date|| Summary|Wrong code generation. |[4.2/4.3 Regression] Wrong |Inlining problem. |code generation. Alias and ||C++ virtual bases problem. Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug preprocessor/32717] def value is ignored
--- Comment #1 from schwab at suse dot de 2007-07-10 11:58 --- *** This bug has been marked as a duplicate of 32670 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32717
[Bug preprocessor/32670] [4.3 Regression] '$' is handled as a part of identifiers in asm
--- Comment #3 from schwab at suse dot de 2007-07-10 11:58 --- *** Bug 32717 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||drazen dot zeman at kr dot ||htnet dot hr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32670
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-10 12:52 --- Fixed with take3.diff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #5 from jakub at gcc dot gnu dot org 2007-07-10 13:10 ---
This got fixed by
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00206.html
on the trunk.
Even is subset of those changes fixes this on 4.2 branch:
--- gcc/tree-ssa-ccp.c.jj 2007-03-20 00:22:09.0 +0100
+++ gcc/tree-ssa-ccp.c 2007-07-10 14:49:15.0 +0200
@@ -2063,12 +2063,13 @@ fold_stmt_r (tree *expr_p, int *walk_sub
tem = fold_binary (TREE_CODE (op0), TREE_TYPE (op0),
TREE_OPERAND (op0, 0),
TREE_OPERAND (op0, 1));
- set = tem is_gimple_condexpr (tem);
+ set = tem set_rhs (expr_p, tem);
fold_undefer_overflow_warnings (set, fold_stmt_r_data-stmt, 0);
if (set)
- TREE_OPERAND (expr, 0) = tem;
- t = expr;
- break;
+ {
+ t = *expr_p;
+ break;
+ }
}
default:
--- gcc/tree-ssa-propagate.c.jj 2007-03-20 00:22:09.0 +0100
+++ gcc/tree-ssa-propagate.c2007-07-10 14:55:18.0 +0200
@@ -571,7 +571,8 @@ set_rhs (tree *stmt_p, tree expr)
ssa_op_iter iter;
/* Verify the constant folded result is valid gimple. */
- if (TREE_CODE_CLASS (code) == tcc_binary)
+ if (TREE_CODE_CLASS (code) == tcc_binary
+ || TREE_CODE_CLASS (code) == tcc_comparison)
{
if (!is_gimple_val (TREE_OPERAND (expr, 0))
|| !is_gimple_val (TREE_OPERAND (expr, 1)))
which prevents in this case generating invalid gimple.
On gcc-4_1-branch, even just the tree-ssa-propagate.c chunk cures this.
Is this something which can safely be changed on the release branches?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-07-10 13:20 --- (In reply to comment #6) Salvatore, could you please recheck this one? I can not observe any problems, neither on dt_bnd.f90 nor on the reduced testcase. Neither can I, it seems to have fixed itself. Should we put it into the test suite to make sure there's no regression? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29804
Re: [Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
Have you looked with valgrind or similar to see if there are errors occurring? Please definitely put in the testsuite. There may be something we don't see yet going on here.
[Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
--- Comment #8 from jvdelisle at verizon dot net 2007-07-10 13:43 --- Subject: Re: segfault with -fbounds-check on allocatable derived type components Have you looked with valgrind or similar to see if there are errors occurring? Please definitely put in the testsuite. There may be something we don't see yet going on here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29804
[Bug c++/32718] New: g++ looping on bad __label__ declaration
Following standalone code will make the compiler (g++) loop:
void test()
{
__label__ 0;
}
command line: g++ lbl.c. However gcc lbl.c works (with ONE error report)
!
output with g++ will be:
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
lbl.c:5: error: expected `,' before numeric constant
lbl.c:5: error: expected identifier before numeric constant
...
output with gcc:
gcc lbl.c
lbl.c: In function 'test':
lbl.c:5: error: parse error before numeric constant
--
Summary: g++ looping on bad __label__ declaration
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tony at rogvall dot se
GCC build triplet: i686-apple-darwin8
GCC host triplet: i686-apple-darwin8
GCC target triplet: i686-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32718
[Bug c++/32718] g++ looping on bad __label__ declaration
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 13:49 --- Fixed in 4.0.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32718
[Bug c/32719] New: ICE when compiling c-format.c
With this configure and make:
[descartes:gcc/objdirs/objdir-mainline] gcc-test% cat
../../mainline/build-and-check-gcc
#!/bin/tcsh
/bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../../mainline/configure
--build=powerpc64-apple-darwin8.9.0 --host=powerpc64-apple-darwin8.9.0
--target=powerpc64-apple-darwin8.9.0 --with-gmp=/pkgs/gmp-4.2.1-64/
--with-mpfr=/pkgs/gmp-4.2.1-64/ --prefix=/pkgs/gcc-4.3.0-64; make -j 4
bootstrap BOOT_LDFLAGS='-Wl,-search_paths_first' build.log (make install)
(make -k -j 8 check RUNTESTFLAGS=--target_board 'unix{-mcpu=970/-m64}'
check.log ; make mail-report.log)
and with this version of gcc:
[descartes:~/programs/gcc/mainline] gcc-test% cat LAST_UPDATED
Mon Jul 9 12:08:01 EDT 2007
Mon Jul 9 16:08:01 UTC 2007 (revision 126488M)
bootstrap fails with
/Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/xgcc
-B/Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/
-B/pkgs/gcc-4.3.0-64/powerpc64-apple-darwin8.9.0/bin/ -c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../../mainline/gcc -I../../../mainline/gcc/.
-I../../../mainline/gcc/../include -I./../intl
-I../../../mainline/gcc/../libcpp/include -I/pkgs/gmp-4.2.1-64//include
-I/pkgs/gmp-4.2.1-64//include -I../../../mainline/gcc/../libdecnumber
-I../../../mainline/gcc/../libdecnumber/dpd -I../libdecnumber
../../../mainline/gcc/c-format.c -o c-format.o
../../../mainline/gcc/c-format.c: In function 'check_format_info_main':
../../../mainline/gcc/c-format.c:2109: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [c-format.o] Error 1
make[2]: *** [all-stage3-gcc] Error 2
make[1]: *** [stage3-bubble] Error 2
make: *** [bootstrap] Error 2
--
Summary: ICE when compiling c-format.c
Product: gcc
Version: lno
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-apple-darwin8.9.0
GCC host triplet: powerpc64-apple-darwin8.9.0
GCC target triplet: powerpc64-apple-darwin8.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32719
[Bug java/32712] error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-10 15:13 --- This is not a bug, please read: http://gcc.gnu.org/gcc-4.3/changes.html Java (GCJ) gcj now uses the Eclipse Java compiler for its Java parsing needs. This enables the use of all 1.5 language features, and fixes most existing front end bugs. And also read: http://gcc.gnu.org/ml/java/2006-12/msg00070.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32712
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #4 from ramana dot radhakrishnan at celunite dot com 2007-07-10 15:14 --- (In reply to comment #3) Fixed with take3.diff. Did you forget to attach take3.diff ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #5 from rguenther at suse dot de 2007-07-10 15:32 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote: --- Comment #4 from ramana dot radhakrishnan at celunite dot com 2007-07-10 15:14 --- (In reply to comment #3) Fixed with take3.diff. Did you forget to attach take3.diff ? No, that was a hint to Danny ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug fortran/32720] New: No coalesce ssa_names
Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror --disable-libunwind-exceptions --disable-checking --disable-decimal-float --enable-shared --enable-tls --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=fortran --with-cpu=pentium3 --with-system-zlib Thread model: posix gcc version 4.3.0 20070710 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 lexlin.f90 -quiet -dumpbase lexlin.f90 -mtune=pentium3 -auxbase lexlin -O2 -version -fintrinsic-modules-path /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/finclude -o lexlin.s GNU F95 version 4.3.0 20070710 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070710 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Unable to coalesce ssa_names 1 and 86 which are marked as MUST COALESCE. ichr_1(ab) and ichr_86(ab) lexlin.f90: In function 'lexlin': lexlin.f90:1: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: No coalesce ssa_names Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rosana07a at gmail dot com GCC build triplet: i686 GCC host triplet: i686 GCC target triplet: i686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug tree-optimization/32721] New: CCP removes volatile qualifiers.
With today's trunk on a private port . consider the following testcase.
volatile int spinlock[2];
void main (void)
{
volatile int * spinlock0;
volatile int * spinlock1;
spinlock0 = spinlock[0];
spinlock1 = spinlock[1];
*spinlock0 = 0;
*spinlock1 = 0;
while (*spinlock0);
}
CCP folds this into the following form
Simulating block 4
Simulating block 3
Substituing values and folding statements
Folded statement: *spinlock0_1 = 0;
into: spinlock[0] = 0;
Folded statement: *spinlock1_2 = 0;
into: spinlock[1] = 0;
Folded statement: D.1498_3 = *spinlock0_1;
into: D.1498_3 = spinlock[0];
main ()
{
volatile int * spinlock1;
volatile int * spinlock0;
int D.1498;
bb 2:
spinlock0_1 = spinlock[0];
spinlock1_2 = spinlock[1];
spinlock[0] = 0;
spinlock[1] = 0;
bb 3:
D.1498_3 = spinlock[0]; --- This folding seems to be wrong.
if (D.1498_3 != 0)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
--
Summary: CCP removes volatile qualifiers.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at celunite dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug fortran/32720] No coalesce ssa_names
--- Comment #1 from rosana07a at gmail dot com 2007-07-10 16:07 --- Created an attachment (id=13877) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13877action=view) failing *.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #2 from rosana07a at gmail dot com 2007-07-10 16:08 --- Created an attachment (id=13878) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13878action=view) 1st req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #3 from rosana07a at gmail dot com 2007-07-10 16:09 --- Created an attachment (id=13879) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13879action=view) 2nd req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #4 from rosana07a at gmail dot com 2007-07-10 16:10 --- Created an attachment (id=13880) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13880action=view) 3rd req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #5 from rosana07a at gmail dot com 2007-07-10 16:11 --- Created an attachment (id=13881) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13881action=view) 4th req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug java/32712] error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type
--- Comment #2 from drow at gcc dot gnu dot org 2007-07-10 16:12 --- Subject: Re: error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type On Tue, Jul 10, 2007 at 03:13:42PM -, pinskia at gcc dot gnu dot org wrote: This is not a bug, please read: http://gcc.gnu.org/gcc-4.3/changes.html Java (GCJ) gcj now uses the Eclipse Java compiler for its Java parsing needs. This enables the use of all 1.5 language features, and fixes most existing front end bugs. And also read: http://gcc.gnu.org/ml/java/2006-12/msg00070.html It Would Be Nice if it were easier to figure out what you had to do, though. Non-gcj-hackers don't know to look in contrib for a magic script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32712
[Bug fortran/32720] No coalesce ssa_names
--- Comment #6 from rosana07a at gmail dot com 2007-07-10 16:14 --- Works with -O0 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror --disable-libunwind-exceptions --disable-checking --disable-decimal-float --enable-shared --enable-tls --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=fortran --with-cpu=pentium3 --with-system-zlib Thread model: posix gcc version 4.3.0 20070710 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 lexlin.f90 -quiet -dumpbase lexlin.f90 -mtune=pentium3 -auxbase lexlin -O0 -version -fintrinsic-modules-path /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/finclude -o lexlin.s GNU F95 version 4.3.0 20070710 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070710 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o lexlin.o lexlin.s GNU assembler version 2.17.50.0.16 (i686-pc-linux-gnu) using BFD version (Linux/GNU Binutils) 2.17.50.0.16.20070511 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 16:15 --- Indeed. CCP propagates the constant addresses spinlock and spinlock[1] to the deref sides which loses the volatile qualifier from the access. Disabling that leads to VRP which does the same. Then DOM which does the same. Then store-ccp which is not disabled by -fno-tree-ccp. So, finally, -O2 -fno-tree-ccp -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-store-ccp makes it work. Maybe this one is stretching what we want to support... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-10 16:15:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-10 16:19 --- As the decl is volatile as well this is clearly a bogus optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug tree-optimization/32722] New: [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop
Bootstrap fails compiling tree-ssa-structalias.c with a verify_ssa failure: ../../gcc/gcc/tree-ssa-structalias.c: In function 'build_pred_graph': ../../gcc/gcc/tree-ssa-structalias.c:940: error: definition in block 5 follows the use for SSA_NAME: D.36231_29 in statement: D.36230_26 = D.36231_29; ../../gcc/gcc/tree-ssa-structalias.c:940: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. this doesn't reduce easily but with --param ggc-min-expand=0 --param ggc-min-heapsize=0 so this is likely GC related. See also PR32636 for a similar issue that got latent again. Testcase is still reducing. -- Summary: [4.3 Regression] Bootstrap failure with -fno-tree-store- copy-prop Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, GC Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32722
[Bug tree-optimization/32722] [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 16:36 --- The verify_ssa failure is after PRE. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32722
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-10 16:59 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On 10 Jul 2007 15:32:51 -, rguenther at suse dot de [EMAIL PROTECTED] wrote: --- Comment #5 from rguenther at suse dot de 2007-07-10 15:32 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote: --- Comment #4 from ramana dot radhakrishnan at celunite dot com 2007-07-10 15:14 --- (In reply to comment #3) Fixed with take3.diff. Did you forget to attach take3.diff ? No, that was a hint to Danny ;) You never told me whether omnetpp/xalanbmc were still failing with it or not :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug libgcj/32651] [4.2/4.3 regression] libjava fails to build on IRIX 6.5
--- Comment #2 from ro at gcc dot gnu dot org 2007-07-10 17:00 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-10 17:00:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32651
[Bug libgcj/32651] [4.2/4.3 regression] libjava fails to build on IRIX 6.5
--- Comment #3 from ro at gcc dot gnu dot org 2007-07-10 17:01 --- Subject: Bug 32651 Author: ro Date: Tue Jul 10 17:01:47 2007 New Revision: 126515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126515 Log: PR libgcj/32651 * configure.host (mips-sgi-irix6*): Set sysdeps_dir. Disable interpreter. Modified: trunk/libjava/ChangeLog trunk/libjava/configure.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32651
[Bug libgcj/32651] [4.2/4.3 regression] libjava fails to build on IRIX 6.5
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-10 17:03 --- Subject: Bug 32651 Author: ro Date: Tue Jul 10 17:02:57 2007 New Revision: 126516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126516 Log: PR libgcj/32651 * configure.host (mips-sgi-irix6*): Set sysdeps_dir. Disable interpreter. Modified: branches/gcc-4_2-branch/libjava/ChangeLog branches/gcc-4_2-branch/libjava/configure.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32651
[Bug tree-optimization/32720] No coalesce ssa_names
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-07-10 17:03 --- Even though this is a tree-opt bug, the Fortran front-end implementation of select of a string could be improved not to use indirect gotos. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
